Close|CloudStack Canvas · How-To Guide
How-To Fix

Grant a Compute Service Access to a Secrets Manager Secret

Your compute service (Lambda, EC2, or ECS) is connected to a Secrets Manager secret, but its IAM role has no secretsmanager:* permissions. The template deploys, but GetSecretValue fails at runtime with AccessDeniedException. Reading a secret needs secretsmanager:GetSecretValue scoped to the secret ARN. On the canvas: connecting a Lambda, EC2, or ECS Service/Task Definition to a Secrets Manager secret always generates this automatically — either edge direction, with or without a custom IAM Role node, whether you drew the connection yourself, loaded it from a saved project or starter template, or imported it from CloudFormation/Terraform/draw.io. For ECS specifically, both the Task Definition's own connected secret (reaches the container's injected environment variables via the execution role, AND the task role for an SDK GetSecretValue call) and the Service's own connected secret (reaches the task role too) are covered — connect it wherever makes sense for your diagram. If you still see this warning, it means neither the generator's own mechanism NOR anything on the connected Role node's own managed/inline policies covers it — the manual policy below is a genuine gap, not advisory.

Paste into this field

IAM Role → permissions policy (or connect the secret on the canvas)

Output looks like

Canvas connection: Lambda/EC2/ECS ↔ Secrets Manager (auto-generates a secretsmanager:GetSecretValue policy)

1Option A (recommended) — let CloudStack Canvas generate it

Connect the compute service and the secret (either direction, Task Definition or Service for ECS) — the exporter always attaches a GetSecretValue policy scoped to that secret, whether or not you have a custom IAM Role node connected, and whether the connection was drawn on canvas, loaded from a saved project/starter template, or imported. Re-export to pick up the grant.

3Option B — this warning fired anyway (a genuine gap)

This means the automatic coverage above genuinely does not apply to your topology. Add the policy below directly to the role in the AWS console.

5Paste a scoped policy

Secret ARNs end in a random 6-character suffix (e.g. -AbCdEf). Use the full ARN, or append -?????? as a wildcard for the suffix as shown. Replace REGION, ACCOUNT, and the secret name.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "secretsmanager:GetSecretValue",
      "secretsmanager:DescribeSecret"
    ],
    "Resource": "arn:aws:secretsmanager:REGION:ACCOUNT:secret:my-secret-??????"
  }]
}

8Save the policy

Name it AllowSecretsAccess and click "Create policy". If the secret uses a customer-managed KMS key, also grant kms:Decrypt on that key.

Once you have the value, go back to CloudStack Canvas and paste it into the highlighted field.

CloudStack Canvas · Validation Guide

Grant a Compute Service Access to a Secrets Manager Secret — CloudStack Canvas