ecs.Secret.fromSecretsManager generates secret name instead of secret ARN

[kastork]

import * as secretsMgr from "@aws-cdk/aws-secretsmanager";

const mySecret = secretsMgr.Secret.fromSecretName(this,"mysecret",`${appSecretBase}/MySecret`);
const mySecretEnv = ecs.Secret.fromSecretsManager(mySecret)
mySecret.grantRead(fargateTaskExecutionRole);
mySecretEnv.grantRead(fargateTaskExecutionRole);

// ...

const container = fargateTaskDefinition.addContainer("appserver", {

// ...

      secrets: {
        MY_SECRET: mySecretEnv,

// ...


 

What did you expect to happen?

Expect the fargate task to launch

What actually happened?

Fargate task failed to launch with the following error:

Fetching secret data from SSM Parameter Store in us-west-2: AccessDeniedException: User: arn:aws:sts::---:assumed-
role/...taskDefExecutionRole9295-1N6FDVCBGB6RK/67766c7d-d908-4b49-b196--:parameter/my path/MySecret 
status code: 400, request id: 2ed367bc-35a9-42ad-b807-e1b2a70ea8f1

Notice, the error is complaining about SSM (parameter store), not Secrets Manager.

Environment

• CLI Version : 1.64.0
• Framework Version: 1.64.0
• Node.js Version: 12.18.3
• OS : macos 10.15.6
• Language (Version): typescript 3.9.7

Other

Looking at the generated secrets configuration, I see

# ...
            "Secrets": [
              {
                "Name": "MY_SECRET",
                "ValueFrom": "/my path/MySecret"
              },

This is a simple parameter name, NOT an ARN to a secret in secret manager, which is what the CloudFormation docs indicate should be here.

---

This is 🐛 Bug Report

[iwt-janbrauer]

I have the exact same problem. I (falsely) understood that providing Secret.fromSecretName would do an actual look up of the secret by name and cache it's ARN within the CDK's context. This isn't the case. Can somebody clarify this? @njlynch maybe.

As a workaround we use:

const secret = new custom.AwsCustomResource(this, "GetSecret", {
            onUpdate: {
                service: "SecretsManager",
                action: "listSecrets",
                parameters: {
                    Filters: [
                        {
                            Key: "name",
                            Values: "/my/cool/secret"
                        }],
                    SortOrder: "asc"
                },
                physicalResourceId: custom.PhysicalResourceId.of('MyCoolSecret')
            },
            policy: custom.AwsCustomResourcePolicy.fromSdkCalls({resources: custom.AwsCustomResourcePolicy.ANY_RESOURCE}),
        });

const secretARN = secret.getResponseField("SecretList.0.ARN")

But that is cumbersome. Especially when the secret has been encrypted with customer managed KMS key. You then need to make sure to give the proper permissions to the task execution role:

taskDefinition.addToExecutionRolePolicy(new iam.PolicyStatement({actions: ['kms:Decrypt', 'kms:GenerateDataKey'], resources: ['*']}));

ecs.Secret.fromSecretsManager(
      secretsManager.Secret.fromSecretArn(
                            this,
                            'ECSSecret',
                            secretARN
                        )

[YuryShchanouskiTR]

CDK v1.67.0
Next code did not return ARN from secret name:

const secret = secrets.Secret.fromSecretName(this, "GitHubSecret", "some-github-secret");
const branch = "master";
const codeRepo = new sagemaker.CfnCodeRepository(this, "MedscrnInfraGitHub", {
    gitConfig: {
        repositoryUrl: `https://github.com/somerepo.git`,
        branch: branch,
        secretArn: secret.secretArn
    },
    codeRepositoryName: `some-code-repository`,
});

Error message during cdk deploy process:

1/7 | 1:30:40 PM | CREATE_FAILED | AWS::SageMaker::CodeRepository | SomeGitHub 1 validation error detected: Value 'some-github-secret' at 'gitConfig.secretArn' failed to satisfy constraint: Member must satisfy regular expression pattern: arn:aws[a-z-]:secretsmanager:[a-z0-9-]:[0-9]{12}:secret:.* (Service: AmazonSageMaker; Status Code: 400; Error Code: ValidationException; Request ID: 768cfe92-503f-45f7-a115-0292f267f041)

[njlynch]

Darn, most CloudFormation usages of secrets are perfectly happy to take either the secret name or the full ARN; this appears to be one of the exceptions where only the ARN is acceptable.

I wonder if it must be the full ARN, or if the ARN without the suffix is sufficient. If the latter, this might be a workaround:

// Old way
// const mySecret = secretsMgr.Secret.fromSecretName(this,"mysecret",`${appSecretBase}/MySecret`);
// const mySecretEnv = ecs.Secret.fromSecretsManager(mySecret)

// New way
const mySecretArn = Stack.of(this).formatArn({
  service: 'secretsmanager',
  resource: 'secret',
  resourceName: `${appSecretBase}/MySecret`,
  sep: ':',
});
const mySecret = secretsMgr.Secret.fromSecretArn(this, 'mysecret', mySecretArn);
const mySecretEnv = ecs.Secret.fromSecretsManager(mySecret);

The interesting bit is that for many other service integrations, the above absolutely won't work; if you don't have the full ARN with the Secrets Manager-generated suffix, you must just provide the secret name, and not the incomplete ARN. That's why Secret.fromSecretName(...).secretArn returns what it does today.

If that works, then the real solution here is probably going to have to be some way for the Secret to indicate that the secetArn is the secretName, and offering a convenience method to return the incomplete ARN like above.

Can someone confirm if the above work-around works for them?

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.