Proposed way to use iam access and secretKey in cdk

❓ General Issue

There are a lot of application out there that still require an access/secretKey pair and do not work with roles. What’s the ideal/secure way to use those in cdk without creating resources manually beforehand.

The Question

There is the parameter store (SSM) and the secrets manager (SM) available. In SSM I can only create “normal” strings from cdk/cloudformation - not secure strings. In SM I can only get a new secret but not store my own one.

So the only option currently seems to be this:

const user = new iam.User(this, 'User', {
    userName: this.getConfig('bucketName'),
})

const accessKey = new iam.CfnAccessKey(this, 'AccessKey', {
    userName: user.userName,
})

const ssmSecretKey = new ssm.StringParameter(this, 'SsmSecretKey', {
    parameterName: '/' + [this.account, this.stackName, 'secretKey'].join('/'),
    stringValue: accessKey.attrSecretAccessKey,
})

const bucket = new s3.Bucket(this, 'Bucket', {
    bucketName: this.getConfig('bucketName'),
    versioned: false,
    removalPolicy: RemovalPolicy.RETAIN,
    publicReadAccess: false,
    blockPublicAccess: BlockPublicAccess.BLOCK_ALL,
})

bucket.grantReadWrite(user)

and then of course using it later in my case in ecs:

const loadBalancedEcsService = new ecsPatterns.ApplicationLoadBalancedEc2Service(this, 'Service', {
    cluster: cluster,
    memoryLimitMiB: 1024,
    taskImageOptions: {
        image: ecs.ContainerImage.fromEcrRepository(asset.repository),
        environment: {
            AWS_ACCESS_KEY_ID: accessKey.ref,
            AWS_DEFAULT_REGION: this.region,
        },
        secrets: {
            AWS_SECRET_ACCESS_KEY: ecs.Secret.fromSsmParameter(ssmSecretKey),
        },
        containerPort: 4873,
    },
    desiredCount: 1,
    domainName: this.getConfig('domainName'),
    protocol: ApplicationProtocol.HTTPS,
    domainZone: domainZone,
    healthCheckGracePeriod: cdk.Duration.seconds(60),
})

Other information

#1857 #3520

[flochaz]

Unfortunately we are a little bound by what CloudFormation supports in this area. I think a Custom Resource that creates the keypair and stores it in SecretsManager is going to be your best bet.

Here is an example using awsCustomResource to store accessKeyId and secretAccessKey in

const adminPassword = new secretsmanager.Secret(this, "AdminUserPassword");

    const mainAdminUser = new iam.User(this, "admin", {
      userName: "admin",
      password: adminPassword.secretValue,
    });

    const accessKey = new iam.CfnAccessKey(this, "AdminUserAccessKey", {
      userName: mainAdminUser.userName,
    });

    new cr.AwsCustomResource(this, 
      "AdminAccessKeyIdSecret", 
      {
        onCreate: {
          service: 'SecretsManager',
          action: 'createSecret',
          physicalResourceId: cr.PhysicalResourceId.fromResponse('Name'),
          parameters:
            {
              Name: "AdminAccessKeyId", 
              SecretString: accessKey.ref
            }
        },
        installLatestAwsSdk: false, 
        policy: cr.AwsCustomResourcePolicy.fromSdkCalls(
          {
            resources: cr.AwsCustomResourcePolicy.ANY_RESOURCE
          }
        ),
        logRetention: RetentionDays.ONE_DAY
      }
    );

    new cr.AwsCustomResource(this, 
      "AdminSecretAccessKeySecret", 
      {
        onCreate: {
          service: 'SecretsManager',
          action: 'createSecret',
          physicalResourceId: cr.PhysicalResourceId.fromResponse('Name'),
          parameters:
            {
              Name: "AdminSecretAccessKey", 
              SecretString: accessKey.attrSecretAccessKey
            }
        },
        installLatestAwsSdk: false, 
        policy: cr.AwsCustomResourcePolicy.fromSdkCalls(
          {
            resources: cr.AwsCustomResourcePolicy.ANY_RESOURCE
          }
        ),
        logRetention: RetentionDays.ONE_DAY
      }
    );

But custom resource lambda logs will contains your secret for 24h (might have a way to force delete the logStream though)

[sblackstone]

Ideally when creating a user, you would be able to just specify a key and it would populate that key in your secrets manager on your behalf… Then you’d never need to actually see the key in the first place and it would programatically be available to your app.