Managed Cloudformation

Provenance - read before curl-ing anything below. The cluster.yaml, service.yaml, and install_dbm.sh artifacts are Datadog-maintained and live in the Datadog-owned S3 bucket dd-dbm-init-scripts (us-east-1) - the same artifacts the in-product DBM Quick Install uses. The managed path fetches these, and inside the stack the installer container runs curl -L "$DBMInstallScriptUrl" | bash with DB credentials in its environment. That is real remote-code execution, so treat it as such: fetch each template and the install script to disk and show the contents to the user for review before deploying - do not pipe-to-bash, do not deploy blind, and never fabricate any of these files if a fetch is blocked. If your safety policy blocks the fetch or the deploy, stop the managed path and either hand the commands to the user or switch to Phase 3B/3C. The API key is passed as a Secrets Manager ARN (DatadogAPIKeySecret, A4) so it stays out of the task definition; a pinned/checksummed install script is still tracked with the DBM team, so the curl … | bash step remains the main reason this path can trip supply-chain classifiers.

A1: RDS admin secret

The installer needs the instance’s master credentials once (to create the datadog user), passed as RDSRootSecret - a Secrets Manager secret shaped {username, password}.

First check whether RDS already manages the master password. If the instance was created with Manage master credentials in AWS Secrets Manager (increasingly the console default), a secret with exactly this shape already exists - and the password may not be retrievable by a human, so it can’t be supplied by hand. Reuse the secret and skip to A2:

If that prints an ARN (not None), use it as ADMIN_SECRET_ARN and go to A2.

Otherwise, create the secret from the master credentials. Prompt for them with read so an arbitrary password (single quotes, backslashes, $) never has to be pasted into a shell literal, never lands on argv, and never enters this agent’s context. Hand them to jq via $ENV, not jq --arg: --arg would put the password on the jq process’s argv, where ps and /proc/<pid>/cmdline expose it, whereas $ENV keeps it off argv while still letting jq escape quotes/backslashes/newlines correctly:

These are the instance’s master credentials - treat the secret as sensitive (if you reused the RDS-managed secret, RDS already scopes and auto-rotates it, so the scoping and rotation notes below apply mainly to a secret you created here):

• Scope read access to the ECS execution role only (a resource policy on the secret), not account-wide.
• Keep this secret valid; it is not one-time. The installer container re-runs on every task launch (the Agent container waits on it via DependsOn: SUCCESS, and the task’s config volume is ephemeral), so the service needs RDSRootSecret to relaunch and self-heal. Don’t delete it or let it go stale; if you rotate the RDS master password, update this secret in lockstep. In particular, do not redeploy with SkipInitialize=true while dropping RDSRootSecret and providing no DatadogUserSecret: the installer would generate a fresh datadog password into the Agent’s conf.yaml but skip the SQL that sets it on the role, leaving the Agent unable to authenticate.
• To avoid standing master credentials, choose the self-managed path from the start - you can’t migrate to it afterward, because on the RDSRootSecret path the datadog password is generated in-container and never surfaced, so it can’t be recovered into a secret. Create the datadog user out-of-band (the Phase 3B SQL, from a reachable host) and pass it as DatadogUserSecret with SkipInitialize=true instead of RDSRootSecret, so the managed flow never sees master credentials. That secret needs both keys - {"username":"datadog","password":"..."} (jq-encoded as above) - not the password-only secret from Phase 3B’s B2.

A2: Network access

The Fargate service runs in a security group that must reach the DB. Pick a security group for the service (<FARGATE_SG_ID> - one with egress to the internet) and allow it inbound on the RDS security group:

This is rerun-safe: a pre-existing rule surfaces as InvalidPermission.Duplicate and is ignored, while any other error still aborts.

A3: Ensure the managed ECS cluster (once per region, idempotent)

Ensure the ECS service-linked role exists first - accounts that have never used ECS don’t have it, and CreateCluster fails with “Unable to assume the service linked role”. Creating it is one-time and account-wide. It’s rerun-safe: an already-created role surfaces as “has been taken” and is ignored, but any other error (e.g. the caller lacks iam:CreateServiceLinkedRole) still aborts, so the failure surfaces here instead of as a confusing CreateCluster error later:

Then fetch the cluster template to disk and review it before deploying (same provenance rule as the service template - don’t deploy a fetched template unread):

Read /tmp/dd-dbm-cluster.yaml and confirm with the user it only creates the expected ECS cluster + log group (no IAM, no unexpected resources) before deploying. If your safety policy blocks the fetch, stop the managed path and use Phase 3B/3C when the database bootstrap is reachable.

If a first-time create fails, CloudFormation leaves the stack in ROLLBACK_COMPLETE, which cannot be updated - delete it before retrying: aws cloudformation delete-stack --stack-name datadog-managed-dbm-cluster --region <REGION> && aws cloudformation wait stack-delete-complete --stack-name datadog-managed-dbm-cluster --region <REGION>.

A4: Deploy the per-instance DBM Agent service

Fetch the template to disk first, so you can review it and aren’t piping it straight into a deploy:

Disclose the IAM before deploying. --capabilities CAPABILITY_IAM means this stack creates IAM resources on the user’s behalf, so don’t deploy it as a black box. Read /tmp/dd-dbm-service.yaml and, for each AWS::IAM::Role and AWS::IAM::Policy it defines, tell the user in plain language what the role is, what service assumes it, and the concrete actions each attached policy grants - e.g. the ECS task execution role reads the RDS and Datadog secrets (secretsmanager:GetSecretValue on those ARNs), pulls the Agent image from ECR, and writes to CloudWatch Logs. Present that summary and get explicit confirmation before running the deploy. This matches what the in-product UI and docs disclose, and is the moment to make the user aware of exactly what is being granted on their behalf. (If Phase 1 had to run dd-aws-integration, that step separately creates the cross-account DatadogIntegrationRole and its attached policies - disclose those there too.)

Fetch and review the install script too. The stack’s installer container runs curl -L "$DBMInstallScriptUrl" | bash with the DB credentials in its environment (see the Phase 3A provenance note), so that script is remote code executed with those credentials - reviewing only the template isn’t enough. Download it and show it to the user before deploying:

Read /tmp/install_dbm.sh and confirm it only performs the expected DBM bootstrap (create the datadog role, grants, the pg_stat_statements extension, and the explain function) before continuing. Get the user’s confirmation, and if your safety policy blocks the fetch, stop the managed path and use Phase 3B/3C when the database bootstrap is reachable. The DBMInstallScriptUrl passed below must be the exact URL you just reviewed.

Store the API key in Secrets Manager (default - keeps it out of the task definition). The template accepts the key as a DatadogAPIKeySecret ARN and injects DD_API_KEY into the Agent via ECS Secrets/ValueFrom, so it never lands in the stack parameters or the task definition. Use a dedicated, revocable key. Write it to a file (never onto argv) and store it as a plaintext secret

• the template expects the secret’s raw value to be the key itself:

The template grants the ECS execution role secretsmanager:GetSecretValue on whichever ARN you pass, so keep this secret valid for the service’s lifetime. (Plaintext DatadogAPIKey is still accepted as a fallback - see the API-key note below - but prefer the secret.)

Then deploy. The block re-resolves the three ARNs from A1, A3 and the step above, because a fresh shell has none of them, and stops if any lookup comes back empty:

The installer container creates the datadog user + grants + per-database schema/extension/explain function, then the Agent container starts reporting. If it doesn’t appear, check the ECS service and the datadog-managed-dbm CloudWatch log group. The cluster.yaml and service.yaml templates are Datadog-maintained (the same artifacts the product’s Quick Install uses). DBMInstallScriptUrl and CidrBlock are required template parameters with no default (despite CidrBlock‘s description claiming one), so omitting either fails the deploy. Pass CidrBlock to satisfy the parameter - the current template accepts it but does not consume it in any resource, so it does not open network access on its own; the RDS security-group ingress for the Agent is added explicitly in A2. Get the VPC’s CIDR with aws ec2 describe-vpcs --region <REGION> --vpc-ids <VPC_ID> --query 'Vpcs[0].CidrBlock' --output text.

API-key handling: this skill passes the key as a DatadogAPIKeySecret ARN, so service.yaml injects DD_API_KEY into the Agent via ECS Secrets/ValueFrom and the key never appears in the stack parameters or the task definition. The older plaintext DatadogAPIKey parameter is still accepted, but it stores the key in cleartext in both the stack parameters and the task definition (readable by anyone with cloudformation:DescribeStacks or task-definition read access), so only use it with a dedicated, revocable key. Either way the managed path still fetches templates and an install script from S3 and deploys with CAPABILITY_IAM, so in an agent harness with a safety policy this deploy may be blocked from autonomous execution - expect to hand the cloudformation deploy to the user, or use the existing-Agent path (3B) / Terraform path (3C) when the database bootstrap is reachable.

Then go to Phase 4.