How can I build a CloudFormation secret out of another secret?

Question

I have an image I deploy to ECS that expects an environment variable called `DATABASE_URL` which contains the username and password as the userinfo part of the url (e.g. `postgres://myusername:mypassword@mydb.foo.us-east-1.rds.amazonaws.com:5432/mydbname`). I cannot change the image.

Using `DatabaseInstance.Builder.credentials(fromGeneratedSecret("myusername"))`, CDK creates a secret in Secrets Manager for me that has all of this information, but not as a single value:
```json
{
  "username":"myusername",
  "password":"mypassword",
  "engine":"postgres",
  "host":"mydb.foo.us-east-1.rds.amazonaws.com",
  "port":5432,
  "dbInstanceIdentifier":"live-myproduct-db"
}
```

Somehow I need to synthesise that `DATABASE_URL` environment variable.

I don't think I can do it in the ECS Task Definition - as far as I can tell the secret can only reference a single key in a secret.

I thought I might be able to add an extra `url` key to the existing secret using references in cloud formation - but I can't see how. Something like:

```java
secret.newBuilder()
  .addTemplatedKey(
    "url",
    "postgres://#{username}:#{password}@#{host}:#{port}/#{db}"
  )
  .build()
```
except that I just made that up...

Alternatively I could use CDK to generate a new secret in either Secrets Manager or Systems Manager - but again I want to specify it as a template so that the real secret values don't get materialised in the CloudFormation template.

Any thoughts? I'm hoping I'm just missing some way to use the API to build compound secrets...

Accepted Answer

With the **major** proviso that as @JohnPreston points out it *will not pick up changes to the value of the original secret*, it is possible to generate a new secret from an existing one as so:

```java
DatabaseInstance dbInstance = makeDbInstance();
ISecret dbCredentials = dbInstance.getSecret();
Secret.Builder.create(stack, "name")
  .secretName("db-url")
  .secretStringValue(
    SecretValue.unsafePlainText(
      "{\"url\": \"postgres://" + dbCredentials.secretValueFromJson("username") + ":" + dbCredentials.secretValueFromJson("password") + "@" + dbCredentials.secretValueFromJson("host") + ":" + dbCredentials.secretValueFromJson("port") + "/mydbname\"}"
    )
  )
  .build();
```

It seems to be safe - the generated CloudFormation yaml is this:
```yaml
  dburl5B3B78EC:
    Type: AWS::SecretsManager::Secret
    Properties:
      Name: db-url
      SecretString:
        Fn::Join:
          - ""
          - - |-
              {
                "url": "postgres://{{resolve:secretsmanager:
            - Ref: dbSecretAttachmentCCB3B2FC
            - ":SecretString:username::}}:{{resolve:secretsmanager:"
            - Ref: dbSecretAttachmentCCB3B2FC
            - ":SecretString:password::}}@{{resolve:secretsmanager:"
            - Ref: dbSecretAttachmentCCB3B2FC
            - ":SecretString:host::}}:{{resolve:secretsmanager:"
            - Ref: dbSecretAttachmentCCB3B2FC
            - |-
              :SecretString:port::}}/mydbname"
              }
```
so no exposed secrets there and they seem to resolve correctly in the new secret.

Answer

I had this same issue with [ECS Compose-X](https://docs.compose-x.io) where I didn't really know where to change it.
Originally thought of having a secret that would use {{resolve:secrets-manager:}} from the main RDS secret but that is going down the rabbit hole of potentially having the main secret rotate, and changes not reflect in the "fork" secret etc, which is a pain.

I much rather recommend in your docker image entrypoint to have a

```
if [ -z ${VAR_EXISTS} ] ; then DATABASE_URL=${VAR_EXISTS}; fi

```
That way, if you expose all the elements to build your connection string (DATABASE_URL) env var, you expose it, if not you don't.
Then in your application do the same logic (if you can) -> is DATABASE_URL set ? if not, try to import all the bits; if not ; fail.

Another alternative is to have a sidecar container which will pull the info from the secrets and dump it into a volume shared between the two containers of your task definition. Have the first one put together an env file, and then again, add in your other container entrypoint to do `source ._secret_env_file` (or alike) and off you go.
Have a look at [Files Composer](https://docs.files-composer.compose-x.io/) if you want a sidecar "ready to go" that will do what I just mentioned.

Hope this helps.

Answer

I much prefer `!Sub` in general, but !Join is a great one too.
```
SecretString: !Sub
 - "postgres://${USERNAME}:${PASSWORD}@${HOSTNAME}:${PORT}"
 - USERNAME: !Sub ${{resolve:resolve:secretsmanager:${SECRET}:SecretString:username::}} #1
   PASSWORD: !Sub ${{resolve:resolve:secretsmanager:${SECRET}:SecretString:password::}}
   HOST: !Sub ${{resolve:resolve:secretsmanager:${SECRET}:SecretString:host::}} #2
   PORT: !Sub ${{resolve:resolve:secretsmanager:${SECRET}:SecretString:port::}} #2
```
#1 -> This will put the Arn of the secret in the resolve **before resolve occurs**

#2 -> alternatively, just use `!GetAtt` on the cluster return values

Personally find this more readable than the `!Join` CDK generated, but they are totally equivalent.

How can I build a CloudFormation secret out of another secret?

Relevant content