-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[custom-resources] Allow passing a Secret value as a parameter to AwsCustomResource
#9815
Comments
Indeed this is currently not supported in custom resources. This would require additional logic in the Lambda function implementing the https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html
|
That is disappointing. One would have hoped that CloudFormation did this automatically |
if you see this in the context of eks, i think this would be a nice feature. Creating rds outside the ecs cluster with secrets from the secretsmanager and passing them to a helm chart ... it would be great if this would be supported! |
Is there any timeline for this being implemented? |
I have a similar use case where I want to pass a SecretValue not to a CustomResource, but to a Lambda as an Environment Variable. I guess the principle is pretty much the same. Pseudo-code to demonstrate:
Right now this is not supported since |
This feature allows users to manage Redshift database resources, such as users, tables, and grants, within their CDK application. Because these resources do not have CloudFormation handlers, this feature leverages custom resources and the Amazon Redshift Data API for creation and modification. The generic construct for this type of resource is `DatabaseQuery`. This construct provides the base functionality required for interacting with Redshift database resources, including configuring administrator credentials, creating a custom resource handler, and granting necessary IAM permissions. The custom resource handler code contains utility functions for executing query statements against the Redshift database. Specific resources that use the `DatabaseQuery` construct, such as `User` and `Table` are responsible for providing the following to `DatabaseQuery`: generic database configuration properties, specific configuration properties that will get passed to the custom resource handler (eg., `username` for `User`). Specific resources are also responsible for writing the lifecycle-management code within the handler. In general, this consists of: configuration extraction (eg., pulling `username` from the `AWSLambda.CloudFormationCustomResourceEvent` passed to the handler) and one method for each lifecycle event (create, update, delete) that queries the database using calls to the generic utility function. Users have a fairly simple lifecycle that allows them to be created, deleted, and updated when a secret containing a password is updated (secret rotation has not been implemented yet). Because of #9815, the custom resource provider queries Secrets Manager in order to access the password. Tables have a more complicated lifecycle because we want to allow columns to be added to the table without resource replacement, as well as ensuring that dropped columns do not lose data. For these reasons, we generate a unique name per-deployment when the table name is requested to be generated by the end user. We also notify create a new table (using a new generated name) if a column is to be dropped and let CFN lifecycle rules dictate whether the old table should be removed or kept. User privileges on tables are implemented via the `UserTablePrivileges` construct. This construct is located in the `private` directory to ensure that it is not exported for direct public use. This means that user privileges must be managed through the `Table.grant` method or the `User.addTablePrivileges` method. Thus, each `User` will have at most one `UserTablePrivileges` construct to manage its privileges. This is to avoid a situation where privileges could be erroneously removed when the same privilege is managed from two different CDK applications. For more details, see the README, under "Granting Privileges". ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Related issue: aws-cloudformation/cloudformation-coverage-roadmap#341 |
It would be convenient to be able to pass a secret
{{resolve}}
token as a parameter to theAwsCustomResource
class and have it resolved at runtime to the actual secret value.Use Case
I created a custom resource that looked like this:
This almost works, but it does not actually resolve the password to its value in Secrets Manager. In my case, it set the actual password to the literal string
{{resolve:secretsmanager:arn:aws:secretsmanager:us-west-2:123456789:secret:auth/internal/MySystemUser-ABCDEF:SecretString:Password::}}
.Proposed Solution
It would be great if the custom resource code looked for
{{resolve:secretsmanager}}
-style references in theparameters
passed toAwsCustomResource
and resolved them to their underlying value.Other
This is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: