AWS::DocDB::DBCluster - MasterUsername and MasterUserPassword

[kastork]

1. AWS::DocDB::DBCluster-MasterUsername and MasterUserPassword validation fails if dynamic reference expression is too long
2. Dynamic References for AWS::DocDB::DBCluster-MasterUsername and MasterUserPassword are supported, but validation appears to be applied before the dynamic reference is resolved, instead of after.
3. Expected behavior -> dynamic references longer than 41 characters (for username) and 63 characters (for password) should be resolved before validation is applied.
4. Also brought up in this forum post: https://forums.aws.amazon.com/thread.jspa?messageID=891456#891456
5. Category: DB (RDS, DynamoDB...)

[AkifRafique]

Hi, I had accidentally marked internally ticket cut as resolved which resulted in status changing to shipped. Changing the coverage-roadmap status back.

Sorry for the confusion.

[garretwilson]

If I understand this ticket, it is not an "enhancement", but a bug that is preventing almost every reasonable usage in CloudFormation of creating a secret and using that with DocumentDB.

Retrieve an AWS Secrets Manager secret in an AWS CloudFormation resource explains that I reference secrets dynamically in this form:

{{resolve:secretsmanager:secret-id:SecretString:json-key:version-stage:version-id}}

The secret-id part is how I identify the secret:

To access a secret in your AWS account, you can use the secret name. To access a secret in a different AWS account, use the ARN of the secret.

So to reference a secret in a different account, I use something like this:

{{resolve:arn:aws:secretsmanager:us-east-:xxxxxxxxxxxx:secret:this-is-my-secret-name-xxxxxx:SecretString:password}}

Note that this is over 100 characters long with the ARN embedded. This bug will validate the length of the reference, not the resolved secret, so this will prevent a stack from being created no matter how long the actual password.

Even referencing secrets locally is almost impossible. Remember that secrets are global, so even in my template I have to use some sort of identifiers to make them unique. Look at this very short reference using the name of a secret:

MasterUsername: !Sub "{{resolve:foobar-${example}-credentials:SecretString:username}}"

My template uses the parameter example to make the secret unique across different instances of the stack. But even !Sub "{{resolve:foobar-${example}-credentials:SecretString:username}}" is longer than the maximum allowed length of the username (even though the actual resolved username may only be admin).

So this bug is preventing virtually all useful references to secrets defined in a template!

This bug makes it virtually impossible to reference secrets using reasonable constructions for best practices.

[garretwilson]

My examples had a typo; it should have been: e.g.

{{resolve:secretsmanager:arn:aws:secretsmanager:us-east-:xxxxxxxxxxxx:secret:this-is-my-secret-name-xxxxxx:SecretString:password}}

Notice that it started with only resolve: and not resolve:secretsmanager:. Once I fixed the typo, then CloudFormation correctly validated the dereferenced value.

So it appears that if the dynamic reference doesn't a valid reference, then this bug appears and validates the length of the reference. But if the dynamic reference does have a valid reference, then the dereferenced value is correctly used for validation.

So what is the status of this bug? It would seem that it is fixed for valid references. (Although it's very confusing when it appears for invalid references, even though the entire string is still enclosed by {{…}}.)

[garretwilson]

See my question on Stack Overflow when I ran into this because of a typo. Fixing the typo made the validation work correctly, but it's still odd that a typo in the reference can make this bug appear.