feat(ecs): add function for adding secrets to containers after instantiating them

[FlorinAsavoaie]

Description

Similar to addEnvironment(), an addSecret() method is useful to add secrets to ECS Containers after instantiating them via the constructor.

Use Case

The most important use-case is when writing Task Definition Extensions or Aspects to augment ECS services. For example, setting environment variables and secrets for a logging or monitoring solution.

Right now, this can be done only using Escape Hatches and there is no higher level functionality to obtain this behaviour.

Proposed Solution

const container = taskDefinition.addContainer('nginx', {
  image: ecs.ContainerImage.fromRegistry('nginx'),
});

container.addSecret('SECRET_1', ecs.Secret.fromSecretsManager(secret));
container.addSecret('SECRET_2', ecs.Secret.fromSecretsManager(secretField, 'password'));

closes #18959

---

All Submissions:

• Have you followed the guidelines in our Contributing guide?

Adding new Unconventional Dependencies:

• This PR adds new unconventional dependencies following the process described here

New Features

• Have you added the new feature to an integration test?
  • Did you use yarn integ to deploy the infrastructure and generate the snapshot (i.e. yarn integ without --dry-run)?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[FlorinAsavoaie]

Well, the problem with the tests failing seems to be that I added more secrets to the same Integration tests that were already testing using secrets. Can we let it go like this or shall I create new integration tests for this use-case? Kind of seems like a waste...

Ping @madeline-k . Sorry for the ping, I just noticed you reviewed an initial PR that was made a while ago for the same feature but never got merged. I made sure I looked into the issues that were raised in that PR and followed the advice you gave there.

[TheRealAmazonKendra]

Please make sure that your PR title confirms to the conventional commit standard (fix, feat, chore) and that it is written in a style that will reflect correctly in the change log (See Contributing Guide, Pull Requests).

Additionally, please make sure that your PR body describes the problem the PR is solving, and the design approach and alternatives considered. Explain why the PR solves the problem. A link to an issue is helpful, but does not replace an explanation of your thought process.

Pull request has been modified.

[Naumel]

@Mergifyio update

[mergify]

update

☑️ Nothing to do

• #commits-behind>0 [:pushpin: update requirement]
• -closed [:pushpin: update requirement]

[FlorinAsavoaie]

Hey Kendra,

Since my PR was created, the integration tests suffered some changes because of some chore so there were conflicts with the integration tests I changed. I rebased but apparently the tests are now failing. I'm working on it.

Thanks for the feedback and I apologise for doing it wrong.

I updated the PR description. I think the title corresponds with the documentation, as far as I can tell. I checked a few other PRs that were recently merged and it seems quite similar, not sure if I'm missing anything. Is everything ok now from this perspective?

[FlorinAsavoaie]

I don't get how the tests are now passed but earlier they weren't. I guess we're good?

[TheRealAmazonKendra]

Hey Kendra,

Since my PR was created, the integration tests suffered some changes because of some chore so there were conflicts with the integration tests I changed. I rebased but apparently the tests are now failing. I'm working on it.

Thanks for the feedback and I apologise for doing it wrong.

I updated the PR description. I think the title corresponds with the documentation, as far as I can tell. I checked a few other PRs that were recently merged and it seems quite similar, not sure if I'm missing anything. Is everything ok now from this perspective?

For the title, we basically want PR titles that are descriptive in a way that would be useful in the changelog. In this case, I'll edit to provide an example. But, instead of just listing the function name, I would describe the functionality you're adding.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: b5380de
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).