Friday, December 14, 2018

AWS Secrets Manager Cross account for SES credentials

If you have external systems sending emails, it might only know of stmp with username and password.

When you want to get CIS compliance in AWS having an access keys last longer than 90 days takes you out of compliance, as such you need to change this access key every 3 months. This seems to be a bit of pain.

Luckily AWS released Secrets Manager to allow as you guessed it secrets, to be rotated.

This is an extension on https://aws.amazon.com/blogs/security/how-to-access-secrets-across-aws-accounts-by-attaching-resource-based-policies/ since blog post is a bit too cryptic for actual implementation with least privileges.

To do that you firstly need to create a KMS key to use since the defaults don't allow addition policies to be added.

For extra security, the SES email sending service is centralised but the application needing to use the credentials are in another part of your AWS Organisation accounts. This is good security practice as you can then remove access to a kms key if a downstream account was compromised.


Here is an example policy which would allow any account in your Organisation to access the key as well as the role which the lambda function will use to rotate the secret

Please note: going with  "aws:PrincipalOrgID": "${YOUR-ORG-ID from organisations}" means that any account in your Org will have access to encrypt or decrypt with this key if they also have privileges to see this key (this means * * Administrators would by default have this, could could be changed to Principals with role names but then that next gotcha is that if the role is deleted and recreated, the connection to this kms policy would be disconnected)

Zip up this script and call it aws-key-rotation-lambda.zip

upload this to s3 inside your cloudformation bucket since we need to reference it for the next cloudformation script.

key-rotation-lambda.yml will generate the rotation service which Secrets Manager will use.



Now that all the building blocks are in place your ready to have a user and new secret created.

Use this next script to generate the iam user and Secrets Manager. Once initialised, it will rotate the secret straight away.



All it needs now is to have the correct groups/policies added for SES raw email sending.

To this test, get on the cli and change into another account which is not what this is installed into and user the ARN of the secret to call it

aws secretsmanager get-secret-value --secret-id arn:aws:secretsmanager:ap-southeast-2:111222333444:secret:smtp-trial-X4Q0Sp --version-stage AWSCURRENT

With the SNS queue, you can now hook up a lambda function to trigger in the other accounts to go update where ever the stmp credentials are set.

This script will give 60 days per access key and generate a new key every 30 days. So if the system fails to update the first time there is a grace period to change over.