You are designing a large distributed application with 30 microservices. Each of your distributed microservices needs to connect to a database back-end. You want to store the credentials securely. Where should you store the credentials?
A.
In the source code
B.
In an environment variable
C.
In a secret management system
D.
In a config file that has restricted access through ACLs
C is the answer, since key management systems generate, use, rotate, encrypt, and destroy cryptographic keys and manage permissions to those keys.
A is incorrect because storing credentials in source code and source control is discoverable, in plain text, by anyone with access to the source code. This also introduces the requirement to update code and do a deployment each time the credentials are rotated. B is not correct because consistently populating environment variables would require the credentials to be available, in plain text, when the session is started. D is incorrect because instead of managing access to the config file and updating manually as keys are rotated, it would be better to leverage a key management system. Additionally, there is increased risk if the config file contains the credentials in plain text.
1. Centralized and Secure Storage: Secret management systems like HashiCorp Vault, AWS Secrets Manager, or Google Cloud Secret Manager provide a centralized and secure location to store sensitive credentials. This ensures that database credentials are not scattered across multiple microservices or configuration files.
2. Access Control: Secret management systems offer fine-grained access control, allowing you to restrict access to secrets based on roles and permissions. This ensures that only authorized microservices and users can access the database credentials.
3. Rotation and Auditing: These systems often provide features for automatic secret rotation and auditing, which helps improve security and compliance.
4. Integration: Secret management systems can integrate with your deployment pipelines and orchestration tools, making it easier to manage secrets throughout the application lifecycle.
C. In a secret management system
It is important to store the credentials for your database back-end securely in order to protect them from unauthorized access. One way to do this is by using a secret management system, such as Google Cloud's Secret Manager. Secret Manager is a secure and convenient storage system for API keys, passwords, and other sensitive data that is designed to protect against unauthorized access. By storing the credentials in Secret Manager, you can ensure that they are kept secure and can be easily accessed by your microservices as needed.
Storing the credentials in the source code, an environment variable, or a config file that has restricted access through ACLs may not provide the same level of security as a dedicated secret management system. It is important to ensure that your credentials are stored in a secure and controlled manner to protect against unauthorized access.
Google Practice exam question with option C : In a key management system
C is correct because key management systems generate, use, rotate, encrypt, and destroy cryptographic keys and manage permissions to those keys.
https://cloud.google.com/kms/
For this question, refer to the Mountkirk Games case study.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Eroc
Highly Voted 5 years agotartar
4 years, 3 months agonitinz
3 years, 8 months agoshandy
Highly Voted 4 years, 12 months agoEkramy_Elnaggar
Most Recent 1 week, 4 days agoashishdwi007
10 months agoTeckexam
10 months, 1 week agohiromi
1 year, 7 months agoomermahgoub
1 year, 11 months agoAniketD
2 years agomegumin
2 years agozr79
2 years, 1 month agoAzureDP900
2 years, 1 month agoKubernetes
2 years, 2 months ago[Removed]
2 years, 8 months agorogerlovato
2 years, 10 months agoharoldbenites
2 years, 11 months agovincy2202
2 years, 12 months agounnikrisb
3 years, 1 month ago