AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations.
What does this mean in practice? I'll tell you about my recent case.
One of my clients uses the AWS Secrets Manager service to store OAuth keys and API tokens. There are a lot of keys and tokens (several hundred).
Secrets rotation (update) is carried out using various AWS Lambda functions. It was difficult for the administrators to manually monitor whether everything in the system works correctly and if there are any keys that, for some reason, have not been updated for a given period of time.
So I faced the task of creating 2 custom AWS Config rules:
1) The last update date for any AWS Secrets Manager key must be no older than 90 days.
2) There must not be Secrets for which the rotation function is not set, and the rotation period must be less than 90 days.
To create and verify these rules in the system, first I need to create 2 AWS Lambda functions with access to AWS Config, AWS Secrets Manager, and CloudWatch (for logging).
We can go into the details and see for which specific Secret the rule is not compliant:
This saves the working time of system administrators - they don’t need to re-check all secret keys and tokens in Secrets Manager manually - it’s enough to log into the dashboard from time to time.
What does this mean in practice? I'll tell you about my recent case.
One of my clients uses the AWS Secrets Manager service to store OAuth keys and API tokens. There are a lot of keys and tokens (several hundred).
Secrets rotation (update) is carried out using various AWS Lambda functions. It was difficult for the administrators to manually monitor whether everything in the system works correctly and if there are any keys that, for some reason, have not been updated for a given period of time.
So I faced the task of creating 2 custom AWS Config rules:
1) The last update date for any AWS Secrets Manager key must be no older than 90 days.
2) There must not be Secrets for which the rotation function is not set, and the rotation period must be less than 90 days.
Next, I create the AWS Config rules themselves, set up in each of them the Lambda function for verification, and set up the frequency of verification:
To program the rule validation logic in the AWS Lambda function, there are a few things to work out:
1) We expect that only the AWS Config service will access the function, and this should be checked when the function starts. The call source is passed to the function in the event variable. For testing during the writing of the Lambda-handler, we can use the following template:
2) After checking the source of the request (the verification code, as well as other boring points I don't give in this post), we need to get the necessary data - in this case, these are Secrets settings. Python boto3 library helps us to access AWS resources. Getting the necessary data is very simple:
3) We analyze the received data for compliance with the given rules and prepare the answer:
4) After the response has been prepared, it must be sent back to the AWS Config rule requesting it:
If any of the rules are not compliant, this is immediately visible in the AWS Config dashboard:
We can go into the details and see for which specific Secret the rule is not compliant:
This saves the working time of system administrators - they don’t need to re-check all secret keys and tokens in Secrets Manager manually - it’s enough to log into the dashboard from time to time.
Comments
Post a Comment