DEV Community: Steven Smiley

Deploying and Tagging ECR Container Images in AWS CodePipeline

Steven Smiley — Fri, 14 Feb 2025 21:57:22 +0000

AWS CodePipeline is not the most popular or robust pipeline tool out there, but it's conveniently available in AWS and works decently well for most scenarios. I have, however, often had to create custom steps where I would have expected there to be pre-built integrations. Fortunately, CodePipeline is flexible enough to support building your own steps through both AWS CodeBuild and AWS Lambda, and I have two examples that I expect would be useful to many others I'd like to share.

Pipeline overview

For this scenario, let's imagine we have container images that are already built and pushed to Amazon ECR. We want to (1) deploy them to Amazon ECS and then (2) tag the image to denote the environment the image is running in.

Deploying from ECR to ECS

The CodePipeline action to deploy a container to ECS requires an input FileName of a JSON file with the target service's container name and the image to be deployed. Unfortunately, the ECR source action does not output this file in the correct format.

In this case, we need to add a CodeBuild step between the Source action and the Deploy action to output the required file in the correct format. The BuildSpec for the CodeBuild project includes a single command:

version: 0.2
phases:
  build:
    commands:
      - printf '[{"name":"%s","imageUri":"%s:latest"}]' "$TASK_FAMILY" "$REPOSITORY_URI" > imagedefinitions.json
artifacts:
  files: imagedefinitions.json

This will write the required JSON file and output it as an artifact that can be referenced during the Deploy action.

Tagging ECR Images in CodePipeline

It can be valuable to indicate which images are actually deployed in your environment, particularly which have been promoted to production. This allows vulnerability management tooling and personnel to assess the risk of vulnerabilities identified in an image -- if the image is deployed to production that's a real risk compared to an old image that just stale in ECR.

We can build an AWS Lambda function to tag images when triggered by CodePipeline. First, the CodePipeline action configuration needs to pass the function the required parameters in the UserParameters field.

- Name: TagImageWithProd
              RunOrder: 3
              ActionTypeId:
                Category: Invoke
                Owner: AWS
                Provider: Lambda
                Version: "1"
              Configuration:
                FunctionName: 
                  Fn::ImportValue: !Sub ${PipelineTagStack}-FunctionName
                UserParameters: "{\"RepositoryName\": \"#{ImageVariables.RepositoryName}\", \"ImageTag\": \"#{ImageVariables.ImageTag}\" , \"NewImageTag\": \"prod\", \"ImageDigest\": \"#{ImageVariables.ImageDigest}\", \"ImageURI\": \"#{ImageVariables.ImageURI}\"}"

In the Lambda function, we can parse the required parameters from the CodePipeline event.

codepipeline_job_id = event["CodePipeline.job"]["id"]
    user_parameters = json.loads(
        event["CodePipeline.job"]["data"]["actionConfiguration"]["configuration"][
            "UserParameters"
        ]
    )

image_uri = user_parameters["ImageURI"]
repository_name = user_parameters["RepositoryName"]
image_tag = user_parameters["ImageTag"]
new_image_tag = user_parameters["NewImageTag"]

To tag the image using the ECR PutImage API, however, we will also need the image's manifest. So first we retrieve that using ECR Batch Get Image.

image_manifest = ecr_client.batch_get_image(
            repositoryName=repository_name,
            imageIds=[
                {
                    "imageTag": image_tag,
                }
            ],
        )["images"][0]["imageManifest"]

Now we have everything we need, and can tag the image in ECR.

ecr_client.put_image(
            repositoryName=repository_name,
            imageTag=new_image_tag,
            imageManifest=image_manifest,
        )

And finally, don't forget to tell CodePipeline that your action has succeeded (or failed), or the pipeline will wait around for about 15 minutes.

codepipeline_client.put_job_success_result(jobId=codepipeline_job_id)
codepipeline_client.put_job_failure_result(
            jobId=codepipeline_job_id,
            failureDetails={
                "type": "JobFailed",
                "message": "Error tagging image",
            },
        )

Although I would have preferred these actions to be available without extra work, the AWS's flexibility again makes it work without too much trouble.

CTF Walkthrough: pentesting.cloud "Aurora Borealis"

Steven Smiley — Sun, 22 Jan 2023 01:16:14 +0000

The pentesting.cloud challenge Aurora Borealis asks us to understand the permissions and processes to connect to Aurora databases with AWS IAM authentication. It creates an Amazon Aurora DB based on a snapshot with unknown contents and configuration, an EC2 instance, and limited user permissions.

Finding a starting point

We examine the IAM roles and policies in the environment, and see that there's an EC2 instance role that can rds-db:* on arn:aws:rds-db:us-west-2:*:dbuser:*/us-west-2. The rds-db:* includes all RDS IAM actions, including connecting to the database. It's important to read that ARN carefully because it reveals the database username we'll need. The ARN format of a db-user is arn:${Partition}:rds-db:${Region}:${Account}:dbuser:${DbiResourceId}/${DbUserName}. That's right, the username is us-west-2, it's not referring to the region.

Since the permissions belong to the EC2 instance, we need to connect from there. Conveniently, pentesting-user can ssm:StartSession on that instance.

Connecting to the DB

We start an SSM session on the EC2 instance so we can use its permissions to connect to the RDS database using IAM authentication. We'll first need to install the mysql client, download the SSL certificate, and generate an authentication token for the user.

sh-4.2$ sudo yum install mysql
sh-4.2$ wget https://truststore.pki.rds.amazonaws.com/us-west-2/us-west-2-bundle.pem
sh-4.2$ RDSHOST="aurora-dbcluster-yjt22bb5xqez.cluster-cmugjtcpbuo6.us-west-2.rds.amazonaws.com"
sh-4.2$ TOKEN="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 1337 --region us-west-2 --username us-west-2)"
sh-4.2$ mysql --host=$RDSHOST --port=1337 --ssl-ca=us-west-2-bundle.pem --user=us-west-2 --password=$TOKEN

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 24
Server version: 5.7.12 MySQL Community Server (GPL)
MySQL [(none)]>

With the MySQL connection, let's explore the database to find the flag.

MySQL [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| flags              |
+--------------------+

MySQL [(none)]> use flags;
Database changed

MySQL [flags]> show tables;
+-----------------+
| Tables_in_flags |
+-----------------+
| flag            |
+-----------------+

MySQL [flags]> describe flag;
+-------+--------------+------+-----+---------+-------+
| Field | Type         | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| flag  | varchar(100) | YES  |     | NULL    |       |
+-------+--------------+------+-----+---------+-------+

MySQL [flags]> select * from flag;
+----------------------------------+
| flag                             |
+----------------------------------+
| xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
+----------------------------------+

Improving AWS data protection

This challenge didn't involve many steps, but required understanding AWS IAM authentication to RDS. To improve data protection with RDS:

Be cognizant of the enabled authentication mechanisms
Grant users the minimum permissions to perform their duties
As much as possible, keep people away from data, limiting potential access vectors

AWS Step Functions: Handling Paginated API Responses

Steven Smiley — Fri, 18 Mar 2022 19:27:17 +0000

Since AWS Step Functions added support for AWS SDK integration, it has become very powerful for serverless integration of AWS services. Previously, the go-to approach would be a simple Lambda function, but Step Functions involves even less maintenance. However, Step Functions has (mostly deliberate) limitations that we need to work with/around.

Some AWS API actions return paginated responses, meaning you get a chunk of the total response and you have to ask for the next chunk if you want it. So if there are 150 items, you may need to pull them 25 at a time. How do we handle this in Step Functions, where each state only gets to make one call?

The key to handling pagination is to loop based on the presence of a continuation token item, usually named NextToken. When a paginated response is returned, the JSON includes this token, which (1) indicates there additional items to be retrieved and (2) needs to be provided in the subsequent API calls to indicate you want the next page. Unfortunately the token name isn’t consistent, see Ian McKay’s complete list of rules for AWS SDK pagination.

Here's a concrete example. Let's say we want to perform an action on every instance of the Amazon WorkSpaces service, each representing a virtual desktop, like updating it to use the latest image. workspaces:DescribeWorkspaces returns 25 at a time, but we have several hundred.

We call DescribeWorkspaces to get the first set of items and map each one to our desired action, in this case RebuildWorkspaces. Then a Choice state checks if NextToken is present in the task result. If so, call DescribeWorkspaces again, this time using the NextToken parameter. Critically, this overwrites the task result from the first call, so the next time we reach the Choice state, it can check if there are even more items to retrieve (NextToken is still present). If we've reached the end (NextToken isn't present), we can move on with the workflow.

Here's the full definition of this Step Functions state machine in AWS CDK with Python.



import aws_cdk.aws_stepfunctions as sfn
import aws_cdk.aws_stepfunctions_tasks as sfn_tasks

describe_workspaces = sfn_tasks.CallAwsService(
            self,
            id="DescribeWorkspaces",
            comment="Get workspaces",
            service="workspaces",
            action="describeWorkspaces",
            result_path="$.DescribeWorkspacesResult",
            iam_resources=["*"],
        )

        describe_more_workspaces = sfn_tasks.CallAwsService(
            self,
            id="DescribeMoreWorkspaces",
            comment="Get workspaces with NextToken",
            service="workspaces",
            action="describeWorkspaces",
            parameters={
                "NextToken": sfn.JsonPath.string_at(
                    "$.DescribeWorkspacesResult.NextToken"
                )
            },
            result_path="$.DescribeWorkspacesResult",
            iam_resources=["*"],
        )

        rebuild_workspaces = sfn_tasks.CallAwsService(
            self,
            id="RebuildWorkspaces",
            comment="Rebuild workspaces",
            service="workspaces",
            action="rebuildWorkspaces",
            parameters={
                "RebuildWorkspaceRequests": [
                    {"WorkspaceId": sfn.JsonPath.string_at("$.WorkspaceId")}
                ]
            },
            result_path="$.RebuildWorkspacesResult",
            iam_resources=["*"],
        )

        rebuild_each_workspace = sfn.Map(
            self,
            id="RebuildEachWorkspace",
            comment="Rebuild each workspace",
            items_path="$.DescribeWorkspacesResult.Workspaces",
            output_path=sfn.JsonPath.DISCARD,
        )
        rebuild_each_workspace.iterator(sfn.Pass(self, "Map State"))

        definition = describe_workspaces.next(rebuild_each_workspace).next(
            sfn.Choice(self, "ChoiceMoreWorkspaces")
            .when(
                sfn.Condition.is_present("$.DescribeWorkspacesResult.NextToken"),
                describe_more_workspaces.next(rebuild_each_workspace),
            )
            .otherwise(sfn.Succeed(self, "Done"))
        )

        state_machine = sfn.StateMachine(
            self,
            id="WorkSpacesRebuilderStateMachine",
            state_machine_type=sfn.StateMachineType.STANDARD,
            definition=definition,
        )

Thanks to Karsten Lang for fixing an error in a previous version

12-Factor AWS CDK Apps

Steven Smiley — Thu, 03 Mar 2022 22:23:16 +0000

The twelve-factor app methodology outlines best practices for building web apps to enable scalability and reliability on cloud platforms. AWS CDK focuses on deploying cloud infrastructure, but enables you to put infrastructure, application code, and configuration all in one place. What can we learn if we apply the twelve-factor app methodology apply to AWS CDK? Is it still relevant in an increasingly serverless world?

I won't bury the lede: CDK makes it easy to adhere to the 12-factor model, and embracing serverless on AWS makes many of the factors so easy that you won't have to worry about them. Let's examine each factor and uncover practices we can apply.

The Twelve Factors

I. Codebase

One codebase tracked in revision control, many deploys

CDK enables you to have one codebase by grouping an app's infrastructure and application code into the same repository. Without this, an app's source code isn't really complete -- how is this app deployed?

CDK enables multiple apps to share the same code via constructs, which are then imported as libraries. Without CDK, infrastructure code is often copied and pasted multiple times across apps or even within the same app -- violating this factor and the Don't Repeat Yourself (DRY) principle.

CDK makes many deploys easy as well, by introducing the concept of environments, especially in conjunction with CDK Pipelines. By defining pipeline stages, logical groupings of stacks, you can deploy to as many environments as you want using the same codebase.

II. Dependencies

Explicitly declare and isolate dependencies

Each CDK-supported language has a mechanism for both declaring dependencies (for example Python's requirements.txt) and isolating dependencies (for example Python's Virtualenv). This greatly simplifies environment setup and ensure reliability when deploying, especially through a pipeline.

Be sure to avoid installing or updating packages outside of this mechanism. If you pip install xxxxx into your virtualenv but forget to add it to your requirements.txt, your app will cdk synth locally but fail on deployment.

III. Config

Store config in the environment

Separating config from app code is much easier with CDK than with purely declarative formats like CloudFormation. It can be tempting to hard-code values in templates rather than declare dozens or hundreds of variables, but this would prevent them from being portable.

The line between app and environment can be difficult to discern with CDK, however, as CDK is deploying the infrastructure which makes up the environment. For specific application components, you should use CDK to provision infrastructure with the appropriate environment variables. For example, using Lambda environment variables, SSM parameters, or Secrets Manager secrets. But how do we handle configuration of the CDK app itself?

Each CDK app has an App construct which defines the entry point and takes an environment parameter, binding the app to the environment. With CDK Pipelines, the App contains a pipeline stack, which then defines the rest of the deployment environments. In each pipeline stage, you'll need to provide the configuration parameters for that stage.

We can store this config as context variables in the cdk.json, but this doesn't scale well and it doesn't support types. Since CDK gives us the power of a general purpose programming language, let's use it! For example, in Python we can create a config.py file and define variables, or even objects with types, which we then import into the pipeline.

You may be tempted to avoid declaring the environment in the CDK application altogether, to strictly separate the two. This is possible, but not recommended for production -- during CDK's synth phase, it will resolve environment-specific details that you want to ensure are deterministic. For example, you might look up an existing VPC or distribute resources across availability zones. This information will be stored in cdk.context.json and won't need to be looked up again, preventing unexpected behavior.

IV. Backing services

Treat backing services as attached resources

CDK apps do not use backing services in the way this factor is traditionally viewed, but we can still learn from the principle. At its core, this factor advocates for strong encapsulation and loose coupling between app components. This allows us to separate concerns across clear boundaries, iterate on independent components without affecting interfacing components, and potentially swap them out completely if needed.

To achieve this with CDK apps, encapsulate logical components into constructs and compose them into stacks and stages for deployment. This may increase the verbosity of an app since it requires passing parameters across construct boundaries but the resulting constructs are portable, testable, and maintainable.

V. Build, release, run

Strictly separate build and run stages

This is straightforward: build occurs during cdk synth, release occurs during cdk deploy, and run is the resulting resources managed by AWS.

To go a step further, CDK Pipelines automatically defines separate stages to build the CDK app and then perform CloudFormation deployments, each with separate prepare and deploy steps.

This factor is built into CDK -- awesome!

VI. Processes

Execute the app as one or more stateless processes

This factor does not directly translate to CDK apps but there is a principle we can extract from it -- strong delineation between stateful and stateless resources.

In CDK, this is best performed at the stack level, separating stateful and stateless stacks. When defining a database, for instance, place it in a separate stack and use cross-stack references to connect other resources to it. You can also enable termination protection on stateful stacks.

At the resource level, set RemovalPolicy to RETAIN or SNAPSHOT to avoid deleting data.

VII. Port binding

Export services via port binding

Again, this factor does not apply to the CDK-portion of an app, but there's still an underlying principle: create self-contained apps that can interface with other apps through web services.

We accomplish this with CDK by grouping all related resources into a single CDK app, which may provide backing services for other apps using deliberately-exposed interfaces. This also encourages us to prevent other apps from modifying our apps underlying resources.

In AWS, the strictest boundary is at the account level. By deploying CDK apps into separate AWS accounts, we prevent direct access to underlying resources, allowing access only across deliberately exposed interfaces, such as web APIs or cross-account shared resources.

VIII. Concurrency

Scale out via the process model

One of the primary benefits of using AWS in the first place is that most services are designed from the ground up with this principle built-in. The more we build apps by connecting those services together instead of running our own processes, the less we have to think about concurrency.

We do have to consider AWS service limits, however. CDK doesn't check to see if we have a sufficiently-high limit during the build phase, and will fail during deployment if these limits are reached. For example, currently CloudFormation limits each stack to 500 resources. I don't know of any tool that can check templates against service limits, but this could be an opportunity for the future.

IX. Disposability

Maximize robustness with fast startup and graceful shutdown

In the context of a CDK app, this factor encourages us to minimize deployment time and design stateless stacks that can be deleted without side effects.

CloudFormation deployments can feel slow compared to competing tools like Terraform because they perform many built-in checks to improve deployment safety. But that doesn't mean they have to be slow. One easy way to improve deployment speed is using CDK Pipelines waves, which deploy stacks and stages in parallel. This achieves a healthy balance between speed and safety.

X. Dev/prod parity

Keep development, staging, and production as similar as possible

Without Infrastructure as Code, this factor is essentially impossible. But even with other approaches to IaC, this can be difficult to achieve and often requires significant effort in developing parameterized templates and a deployment pipeline. CDK Pipelines makes this so easy!

Define each stage and stack to take configuration parameters for anything that needs to be different across environments, then use those same constructs to deploy to each environment with their respective parameters. This one pipeline can deploy across AWS accounts, so each is isolated. You can even set a ManualApprovalStep between environments if desired, to gate deployment to production.

XI. Logs

Treat logs as event streams

This is already the model for CloudWatch Logs, so there isn't much for us to consider here. One CDK tip, however, is to always set log retention policies. The default log retention is infinite, and you don't want to pay for accumulating a bunch of logs you don't need.

XII. Admin processes

Run admin/management tasks as one-off processes

If there are admin tasks that you want to be prepared to execute on-demand, consider creating them with Systems Manager Automation documents or Step Functions, which can now perform any AWS API action directly. You can invoke them on-demand with input parameters from the AWS Console. By bundling maintenance operations with the app, whoever needs them later will be able to find them easily and will be very happy, that might even be future you!

Conclusion

We've seen that CDK is not only compatible with the 12 factor model, but much of it is built into the CDK model. And the more we leverage 'serverless' AWS services, the less we have to worry about these altogether.

Below I have summarized the key practices for building 12-factor CDK apps. Unsurprisingly, this list is compatible with the CDK developer guide's best practices, but through this exercise we've learned some specific techniques and the reasoning behind them.

Key Practices for 12-Factor CDK Apps

Model apps using constructs, composed into stacks and stages for deployment.
- When constructs need to be used in multiple apps, move them to their own repository so they can be maintained independently of the application's lifecycle.
- Separate stateful and stateless stacks. When defining a database, for instance, place it in a separate stack and use cross-stack references to connect other resources to it.
  - Enable termination protection on stateful stacks and resources so they aren't accidentally deleted.
  - Set RemovalPolicy to RETAIN or SNAPSHOT to avoid deleting data.
- Use CDK Pipelines for painless Continuous Delivery
  - Group stacks and stages into waves for parallel deployment
  - Deploy CDK apps into separate AWS accounts to prevent direct access to underlying resources, allowing access only across deliberately exposed interfaces, such as web APIs or cross-account shared resources.
Ensure you are using the dependency isolation mechanism expected by your CDK app's language. In Python, source .venv/bin/activate.
- Declare and install dependencies using only the mechanism supported by your CDK app's language. In Python, add it to requirements.txt and run pip install -r requirements.txt.
Define separate files for constants and config
- Import config only to your main app and pipeline. If you find yourself importing config directly into a stage, stack, or construct -- stop. If it varies across environments it needs to be a parameter, and if it doesn't then it needs to be defined as a constant.
- Constants can be used across the app, as long as their values would not change across environments. For example, it can be useful to define tag keys and values that will apply globally.
- Explicitly specify production environments and commit cdk.context.json to avoid non-deterministic behavior.
Set LogRetention policies
Create admin processes in your app to support operations

AWS CDK: 6 Things You Need To Know

Steven Smiley — Thu, 27 Jan 2022 21:00:38 +0000

The AWS Cloud Development Kit (CDK) has quickly become my preferred tool for defining AWS infrastructure. I built a project recently that would have been significantly more difficult with any other tool because it needed to span multiple AWS accounts, multiple AWS regions, and deploy several stacks of resources across them.

While the CDK docs are pretty good, and the CDK Book is a great way to learn the basics, here are some important features I have learned along the way.

Direct CloudFormation, a.k.a. Escape Hatches

CDK includes several 'level 2' constructs which are excellent: they provide sane defaults, improved autocompletion, boilerplate, and glue logic built-in. However, most AWS services off-the-beaten path don't have them yet, so you need to be prepared to effectively use 'level 1' constructs. These translate directly to CloudFormation resources, and include the full capability that CloudFormation does. This is huge, as you can confidently start a CDK project knowing that, at minimum, you'll have level 1 constructs for everything supported by CloudFormation.

Level 1 constructs will begin with Cfn, and you should refer to the CloudFormation resource reference when providing parameters, as there is no meaningful autocomplete support.

To pass references between these resources, use .ref to pass the ARN that will be generated at deploy-time.

Here's an example, creating a Systems Manager Maintenance Window to run a Command Document on a schedule:

with open('example/example_ssm_document.json', 'r') as document_content:
    document_content = json.load(document_content)

document = ssm.CfnDocument(self, "ExampleCommandDocument",
                            content=document_content,
                            document_format="JSON",
                            document_type="Command",
                            )

window = ssm.CfnMaintenanceWindow(self, "ExampleWindow",
                                    allow_unassociated_targets=True,
                                    cutoff=0,
                                    name="ExampleWindow",
                                    duration=1,
                                    schedule='rate(1 hour)'
                                    )

task = ssm.CfnMaintenanceWindowTask(self, "ExampleTask",
                                    window_id=window.ref,
                                    max_concurrency='1',
                                    max_errors='1',
                                    priority=1,
                                    targets=[{
                                        'key': 'InstanceIds',
                                        'values': ['i-xxxxxxxxxxxxxx']
                                    }],
                                    task_arn=document.ref,
                                    task_type='RUN_COMMAND',
                                    )

Custom Resources

In the rare case you need to define a resource that isn't supported by CloudFormation, you can still automate it using Custom Resources. Most of the time, these will just be single AWS API calls, and CDK has an awesome construct just for that: AwsCustomResource. You provide the service, API action, and parameters, and CDK will create and invoke a Lambda function accordingly. But here are some tricks that aren't immediately obvious:

AwsCustomResource uses the JavaScript SDK, so you have to provide the services, actions, and parameters using that specification for spelling/casing/etc. Refer to the JavaScript SDK for those.
The physical_resource_id parameter needs a verification token from the API response, which is easy to retrieve but wasn't intuitive: PhysicalResourceId.from_response("VerificationToken")
You can pass parameters directly, but you can't dynamically retrieve them, for example a secret from Secrets Manager. This can be a complete killer! I tried to create an AD Connector, and of course don't want to embed a password into the code, but attempting to retrieve it as below does not work.

AwsCustomResource(self, id='ADConnector',
            policy=AwsCustomResourcePolicy.from_sdk_calls(
                resources=AwsCustomResourcePolicy.ANY_RESOURCE),
            on_create=AwsSdkCall(
                service="DirectoryService",
                action="connectDirectory",
                parameters={
                    "Name": ad_fqdn,
                    "Password": cdk.SecretValue.secrets_manager(secret_id=ad_service_account_secret_arn, json_field="password").to_string(),
                    "ConnectSettings": {
                        "VpcId": vpc_id,
                        "SubnetIds": subnet_ids,
                        "CustomerDnsIps": customer_dns_ips,
                        "CustomerUserName": cdk.SecretValue.secrets_manager(secret_id=ad_service_account_secret_arn, json_field="username").to_string(),
                    },
                    "Size": "Small",
                },
                physical_resource_id=PhysicalResourceId.from_response(
                    "VerificationToken")
            ))

Something on my #awswishlist would be custom resources backed by the new Step Functions SDK support, instead of a Lambda function. This could include a series of API calls that pass values between them.

Import Existing Resources

In many cases, you'll need to get information about resources defined outside your application, and you can import them quite easily. A common one is where networks have been created by some other mechanism, but you need to deploy into them. Importing a VPC is straightforward using ec2.Vpc.from_lookup, but importing subnets by id wasn't immediately obvious. The answer is to use ec2.SubnetSelection as easy as below:

SubnetSelection(subnet_filters=[SubnetFilter.by_ids(subnet_ids)])

Create and Use a Secrets from Secrets Manager

When handling secrets, you have to be extra careful to avoid printing them into the template where they could be inadvertently accessed. To generate a secret securely, use SecretStringGenerator from Secrets Manager, and to pass that into a resource, refer to the secret using SecretValue.secrets_manager. For example, the below sample creates a Directory Service Microsoft AD with a generated admin password:

ad_admin_password = secretsmanager.Secret(
    self, "ADAdminPassword",
    secret_name="ad-admin-password",
    generate_secret_string=secretsmanager.SecretStringGenerator(),
    removal_policy=cdk.RemovalPolicy.RETAIN)

managed_ad = directoryservice.CfnMicrosoftAD(self, "ManagedAD",
    name=name,
    password=cdk.SecretValue.secrets_manager(
        ad_admin_password.secret_arn).to_string(),
    vpc_settings=directoryservice.CfnMicrosoftAD.VpcSettingsProperty(
        subnet_ids=subnet_ids,
        vpc_id=vpc_id
    ),
    create_alias=False,
    edition=edition,
    enable_sso=False,
    )

Pass Values Between Stacks

One of the biggest reasons to use CDK is the ability to handle multiple CloudFormation stacks in one application and pass values between them.

To do this, define a CfnOutput with an export name that you will reference in another Stack. CDK is smart enough to identify this dependency and order stack deployment accordingly, awesome!

For example, let's say we want to be able to access the alias or DNS addresses generated by the above Managed AD:

cdk.CfnOutput(self, "ManagedADId",
                value=managed_ad.attr_alias,
                export_name="ManagedADId")
cdk.CfnOutput(self, "ManagedADDnsIpAddresses",
                value=cdk.Fn.join(',', managed_ad.attr_dns_ip_addresses),
                export_name="ManagedADDnsIpAddresses")

Notice that we use cdk.Fn.join to combine multiple DNS addresses into a single value.

Create Multiple Similar Resources with Unique IDs

This is a dangerous one, but powerful if used carefully. You always want infrastructure definition to be declarative, and using loops risks breaking that if the inputs are dynamic.

That said, let's say you want a pipeline to deploy a set of stacks into multiple regions. You can define a stage with those stacks, and put multiple stages into a single wave to be deployed in parallel:

for region in constants.REGIONS:
        pipeline_wave.add_stage(
            ExampleStage(self,
                id="ExampleStage-{}".format(
                    region.region),
                env=cdk.Environment(
                    account=constants.EXAMPLE_ACCOUNT_ID,
                    region=region.region),
        )

We've defined a python dataclass with values needed in each region, and we can loop through it during the CDK Pipeline definition. Notice that the id must be unique, so it includes the region name.

Conclusion

I am optimistic about the future of AWS CDK, and I'll be using it for new projects until someone convinces me otherwise. At minimum, it's a better way to write CloudFormation. But it also empowers you well beyond that, and is just a pleasure to use.