- Newest
- Most votes
- Most comments
Hi there! It seems like this is a perfect use case for Secrets manager and Key management store (KMS)! If I am understanding correctly, this should help you. If you find this useful, please accept my answer as this will help me answer more questions about aws!
AWS Secrets Manager is a service that makes it easy to store and retrieve your secrets via API or the AWS CLI and rotate your credentials with built-in or custom AWS Lambda functions. You can use Secrets Manager to store customer information that you shouldn’t have access to, such as passwords, API keys, or personal data. Secrets Manager encrypts your secrets with the AWS KMS key of your choice, and you can control who has access to your secrets with granular IAM policies. You can also enable automatic rotation of your secrets with built-in or custom Lambda functions that can call external APIs or services. For more info, checkout this blog! https://aws.amazon.com/blogs/aws/aws-secrets-manager-store-distribute-and-rotate-credentials-securely/
I tried to create a step by step for you, give it a go and please feel free to reply with any questions!
1.Create a KMS key that you want to use to encrypt your secrets. You can use the AWS KMS console or the AWS CLI to create a customer managed key (CMK) and configure its key policy and key rotation settings.
2.Create a secret in Secrets Manager and choose the KMS key that you created in step 1. You can use the Secrets Manager console or the AWS CLI to store a new secret and provide a name, description, and value for your secret. You can also choose whether to enable automatic rotation of your secret and select a built-in or custom Lambda function for rotation.
3.Configure access to your secret with IAM policies. You can use the IAM console or the AWS CLI to create IAM roles or users and attach policies that allow or deny access to your secret based on conditions such as source IP address, time of day, or MFA authentication. You can also use resource-based policies on your secret to grant cross-account access or delegate permissions to other AWS services.
4.Retrieve your secret with the Secrets Manager API or the AWS CLI. You can use the GetSecretValue API or the get-secret-value command to retrieve the plaintext value of your secret or its metadata. You can also use the Secrets Manager SDKs or libraries to integrate Secrets Manager with your applications.
Good luck! Again if you found this useful, it would be much appreciated if you could accept my answer :) For more info about secrets manager: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
Relevant content
- asked a year ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 4 months ago
Hello, thank you for your input, that is super helpful! I am wondering though, technically a high enough privelege user with access to AWS can change the policies as they like, or access the keys they like, right? I assume there's no way around that?
Hi! No problem - you are right with that, technically someone with enough privileges (e.g. root or admin) will be able to change policies as they like. However, applying the principle of least privilege should help avoid this. Best practice is to lock the root account down and not use it for anything after creation of IAM roles/users to make changes. If you use AWS Organizations, service control policies (SCPs) allows you to allow/block actions that users can perform (e.g. block users accessing secrets manager) - this lets you apply the rule across all accounts in your organisation.
you can and should lock down the root account with MFA auth to prevent anyone unauthorised from accessing your secrets - finally, services like cloudtrail and cloudwatch will allow you to track all user API calls and actions and alert you in the case that someone has managed to edit something they shouldn't be able to. This combined with the use of IAM users/ roles with limited permissions (to get their job done, i.e. dev view items in s3 bucket only) will help you use AWS best practices when it comes to permissions. Let me know if you have any further comments!
I see, I take it I would have to check with legal advice to see if this implementation would satisfy GDPR?
hi there! Yeah I would probably double check if you are unsure :)