Your application is running as a container in a Google Kubernetes Engine cluster. You need to add a secret to your application using a secure approach. What should you do?
A.
Create a Kubernetes Secret, and pass the Secret as an environment variable to the container.
B.
Enable Application-layer Secret Encryption on the cluster using a Cloud Key Management Service (KMS) key.
C.
Store the credential in Cloud KMS. Create a Google service account (GSA) to read the credential from Cloud KMS. Export the GSA as a .json file, and pass the .json file to the container as a volume which can read the credential from Cloud KMS.
D.
Store the credential in Secret Manager. Create a Google service account (GSA) to read the credential from Secret Manager. Create a Kubernetes service account (KSA) to run the container. Use Workload Identity to configure your KSA to act as a GSA.
Alternative D is correct.
Problem I see with alternative A is that storing secrets in Kubernetes Secrets in plain text format is not aligned with best practices, as such secrets are base64 encoded but not encrypted at rest. If a malicious agent gains access to the cluster, secrets can be easily decodes and captured.
What I have seen till now and done till now is option A. So I go with option A. What is the best secure approach between A and D, I am not sure. So, very doubtfully I go with A.
D is best answer: You should not store secrets in k8s secrets:
https://kubernetes.io/docs/concepts/configuration/secret/
They are for environment variables.
Using D would also be a secure approach. Option D uses a combination of Google Secret Manager, Google Service Account, and Workload Identity to store and retrieve secrets securely. The Workload Identity enables the Kubernetes Service Account to act as the Google Service Account, which has the required permissions to read the secrets from Secret Manager.
Both options A and D are secure ways to store and retrieve secrets in a Kubernetes cluster, but option A is simpler and requires fewer steps. It may be more appropriate for smaller or less complex environments, while option D provides more advanced security and management features and is more suitable for larger and more complex environments.
Secrets can be mounted as data volumes or exposed as environment variables to be used by a container in a Pod. Secrets can also be used by ...
https://cloud.google.com/secret-manager/docs/best-practices
https://kubernetes.io/docs/concepts/security/secrets-good-practices/
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.
hongminhcbg
1 week, 1 day agoexamprof
4 months, 3 weeks ago__rajan__
7 months, 1 week agopurushi
8 months, 3 weeks agoPime13
1 year, 2 months agomrvergara
1 year, 2 months agorich_maverick
1 year, 2 months agomrvergara
1 year, 2 months agomrvergara
1 year, 2 months agomrvergara
1 year, 2 months agoTNT87
1 year, 2 months ago