- 最新
- 投票最多
- 评论最多
Hi,
If you're using CloudFormation to deploy your lambda functions, you can use dynamic references as per this section of the documentation.
Example using AWS SAM (with some properties omitted for brevity):
Resources: MyFunction: Type: AWS::Serverless::Function Properties: [...] Environment: Variables: SECRET_STRING: '{{resolve:secretsmanager:my/secret:SecretString:secretkey}}'
A different option for both, Lambda and ECS can be dynamically read from SecretsManager in the code of your application instead of using Environment Variables.
You need to add a policy to IAM Role for Lambda and TaskRole to access SecretsManager. Then you can get the value using AWS SDK.
An advantage of this solution is that even if the secret change, you can refresh it in the app, so you don't need to redeploy the app. It is also more secure because the secret is not visible anywhere in plain text.
A disadvantage is that it can cost more because you will pull the value more often but it can be cached. Example in .net.
Or a more cost-efficient solution with SSM Parameter Store.
sorry MG, but that's exactly what we don't want to do
sure, if it's a better option for you. Then follow advice from Niklas and Jerome :)
I faced the same issue on my lambdas and I chose to use SSM Parameter store Secure Strings instead of Secrets Manager for the following reasons.
- Cost. Each secret costs .50 per month whereas secure strings are essentially free (each 10000 decrypts costs .05)
- Consolidated storage. I have all my other lambda parameters in the parameter store so everything is in one place.
Now the only env variable I pass to my lambda is the region where the parameters are stored. When the lambda starts, it calls the store and gets everything it needs.
The main advantage of secrets manager is auto rotation of passwords. When the password rotates AWS takes care of updating secrets manager. Using Parameter Store you would need to change the password manually or create a lambda function to update it. This is not a major concern for my use case.
Just one point worth noting. Put your API calls to the Parameter Store or Secrets manager into some type of init function instead of the handler so the API is only called once when the lambda starts instead of every time the handler is called.
If you want to pass sensitive information to lambda, you can't pass this directly as plain text to lambda. This is because your sensitive data will be visible in environment variables section of aws lambda service in aws console.
Instead, you can use either Parameter store or Secret Manager to store the secrets and pass the ARN of the secret as environment variable to AWS Lambda and your lambda can fetch the secret by communicating with respective service.
Please note that your lambda should have necessary role to communicate and fetch the secret. I've written detailed step-by-step guide to do the same here - https://www.cloudtechsimplified.com/environment-variables-secrets-database-password-aws-lambda/
You can use either Parameter Store or Secret manager for storing the secret and within your lambda function - you can retrieve the secret dynamically and use that secret accordingly.
I've written detailed step by step guide on how to use this here -https://www.cloudtechsimplified.com/environment-variables-secrets-database-password-aws-lambda/
相关内容
- AWS 官方已更新 1 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 3 年前
sounds like a great option, as we are using CloudFormation... now it's time to test that solution
If you use this one, don't forget to use a kms key to encrypt the environment variable, so that no one can read the value (except the function). With SAM or cloudformation, specify "KmsKeyArn".
Unless you have a good reason, you should retrieve the secret from secret manager inside your function, like MG said (or using the solution provided by James in the blog post). If the secret changes (for example after a rotation), your Lambda function won't be updated and you won't retrieve the latest value...
I consider the secrets as part of the contract in a sense. If you want to retreive inside the function, then SSM Parameter Store is a more cost-effective solution. A solution to changing secrets is to version your secrets by adding a version suffix, as suggested by the docs, but it's good that you highlighted that!