Deploy ECS ApplicationLoadBalancedFargateService isn't loading Secrets

When inejcting secrets to the Secrets object of the ApplicationLoadBalancedFargateService’s taskImageOptions imported from sm.Secret.fromSecretCompleteArn (including 6 digit hypen), the deploy gets stuck and does not work.

I have also tried importing the secrets by:

sm.Secret.fromSecretNameV2 and the behaviour is the same.

Expected Behavior

ECS to deploy with custom secrets

Current Behavior

CDK deploy freezed stuck at ECS apiService deploy

Reproduction Steps

const importedSecrets = SECRET_NAMES.reduce((acc, key) => {
    const secret = sm.Secret.fromSecretCompleteArn(
      scope,
      `${config.ENVIRONMENT}/${key}`,
      secretFullArns[key], // full ARN of the secret identical as AWS
    );
    return {...acc, [key]: secret};
  }, {} as {[key: string]: sm.ISecret});

Where SECRET_NAMES is an array of secret names Then,

  const secretsJson = SECRET_NAMES.reduce(
    (acc, key) => ({
      ...acc,
      [key]: ecs.Secret.fromSecretsManager(importedSecrets[key]),
    }),
    {},
  );

and then in the fargate service creator:

// Fargate service
this.backendService = new ecsPatterns.ApplicationLoadBalancedFargateService(
  scope,
  'apiService',
  {
    serviceName: 'apiService',
    cluster: this.ecsCluster,
    taskSubnets: {
      subnetType: ec2.SubnetType.PRIVATE_WITH_NAT,
    },
    memoryLimitMiB: 2048,
    cpu: 1024,
    desiredCount: 1,
    taskImageOptions: {
      containerName: 'apiContainer',
      image: ecs.ContainerImage.fromAsset('../api-backend/', {
        followSymlinks: SymlinkFollowMode.ALWAYS,
      }),
      containerPort: config.PORT,
      environment: {
        NODE_ENV: 'development',
        AWS_DEFAULT_REGION: config.AWS_DEFAULT_REGION,
      },
      logDriver: ecs.LogDrivers.awsLogs({
        streamPrefix: `${config.PROJECT_NAME}-logStream`,
        logGroup: fargateLog,
      }),
      secrets: {
        DB_BUSINESS_PASSWORD: ecs.Secret.fromSecretsManager(
          dbBusinessPasswordSecret,
          'password',
        ),
        DB_BUSINESS_HOST: ecs.Secret.fromSecretsManager(
          dbBusinessPasswordSecret,
          'host',
        ),


        ...secretsJson. 
        // ===========>>> If i comment this line here, the deploy is successfull, but without the secrets i want.
        


      },
    },
  },
);

In the CDK template i see the correct secret name BUT WITHOUT THE HYPHEN

CDK TEMPLATE Secrets from ECS:

....
{
  "Name": "X_API_KEY",
  "ValueFrom": {
    "Fn::Join": [
      "",
      [
        "arn:",
        {
          "Ref": "AWS::Partition"
        },
        "secret-arn-as-it-is-in-aws-console/co****/staging/X_API_KEY"
// The secret arn is exactly equal as it is in aws but without the 6 char hyphen auto-generated when the secret was uploaded.
      ]
    ]
  }
},
...

Parameter name is: /co****/staging/X_API_KEY But in the aws console the arn of the secret is exactly the same as the one in the cdk template but without the hyphen. Im pretty sure that’s the cause of the deploy stuck freeze.

Also, IAM Permissions from the image task are fine, for example for the secret who’s name is: /co***/staging/CIPHER_SECRET-?????? where the ? represent the auto hyphen 6 digit

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

“aws-cdk-lib”: “^2.27.0”,

Node.js Version

14.19

OS

Macos Monterey

Language

Typescript

Language Version

“typescript”: “^4.7.2”

Other information

CDK JSON

{
  "app": "npx ts-node --prefer-ts-exts bin/CdkStarter.ts",
  "context": {
    "@aws-cdk/aws-apigateway:usagePlanKeyOrderInsensitiveId": true,
    "@aws-cdk/aws-rds:lowercaseDbIdentifier": true,
    "@aws-cdk/aws-efs:defaultEncryptionAtRest": true,
    "@aws-cdk/aws-cloudfront:defaultSecurityPolicyTLSv1.2_2021": false,
    "@aws-cdk/core:stackRelativeExports": false
  }
}

[josechifflet]

@madeline-k Any thoughts ?

[mrgrain]

@bryan-queryai Thanks for your detailed report. This helps clearing things up! I also agree that most of it could be solved by improving the docs. We very much welcome contributions in this area.

# using .from_secret_complete_arn works # .from_secret_complete_arn creates a policy with the logical id

Works as expected. Nice!

### these methods of importing a secret for use with ECS result in an IAM policy that lacks the logical id in the arn # this method fails; I think this one should work and the resulting foo_secret.secret_full_arn should have the logical id, # this method fails; I think this one is expected to fail as importing from name is known to lack the logical id

I think this is also expected. Specifically from_secret_partial_arn is referencing the secret without the suffix (hyphen and six character). Unfortunately CDK and CFN have no means of finding the correct suffix here.

# .from_secret_partial_arn and .from_secret_name_v2 result in a IAM policy attached to the Task Execution Role like this "Resource": "arn:aws:secretsmanager:us-east-1:1234567890:secret:dev-foo-secret-??????" # <--- missing logical id

This also works as expected. We don’t know the suffix, so the policy is created with a wildcard matching any suffix.

# .from_secret_partial_arn and .from_secret_name_v2 result in the ECS Task def ValueFrom that doesn’t have the ????? but is still invalid "ValueFrom": "arn:aws:secretsmanager:us-east-1:1234567890:secret:dev-foo-secret:BAR::" # <--- missing logical id

This seems to be the core of the issue here. Although I’m not entirely sure yet if leaving the :: would actually help much.

Bottom line really is that from_secret_complete_arn is the only method that should be used in 99.9% of the use cases.