Security Checklist: Limit Scope on Secrets

The late, great Adam Schlesinger wrote about a quarterback who "all kinds of time." Sadly, the only ones these days who really have all kinds of time are hackers.

That means that those who write anything that can be accessed through the internet need to be hyper-vigilant. What do hackers know best? Secrets. Who has secrets? AWS.

That's why it makes me cringe when I see examples of giving a Lambda function read access to all secrets.

Dude, you just gave the function the ability to get all the secrets in your system, change the values, create new ones. Hackers are going to get YOUR PASSWORDS and steal your data.

Don't do this. Use the ARN to uniquely assign a secret to a given Lambda function. Put the secret in the build environment and compile it in when you deploy using cloudformation. Always use a minimal access such as get and specific ARNs when giving an application access to a secret it needs.

PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "secretsmanager:GetSecretValue" Resource: !Ref MySecretArn

Compile time:

aws cloudformation --profile ${AWS_PROFILE} deploy --template-file lambda/packaged-template.yaml \

--stack-name ${STACK_NAME} \

--parameter-overrides SECRETSARN="${MY_SITE_SECRET}" \

--capabilities CAPABILITY_NAMED_IAM