You are developing a microservice-based application that will be deployed on a Google Kubernetes Engine cluster. The application needs to read and write to a
Spanner database. You want to follow security best practices while minimizing code changes. How should you configure your application to retrieve Spanner credentials?
To securely retrieve Spanner credentials while minimizing code changes, the best practice is to use Workload Identity. This approach involves configuring service accounts with the necessary permissions and associating them with Kubernetes Engine pods. This allows the pods to authenticate to Google Cloud services, including Spanner, without the need to store credentials directly within the code or as Kubernetes Secrets. This method enhances security by eliminating the risks associated with managing and rotating secrets manually.
https://cloud.google.com/blog/products/containers-kubernetes/introducing-workload-identity-better-authentication-for-your-gke-applications A Cloud IAM service account is an identity that an application can use to make requests to Google APIs. As an application developer, you could generate individual IAM service accounts for each application, and then download and store the keys as a Kubernetes secret that you manually rotate. Not only is this process burdensome, but service account keys only expire every 10 years (or until you manually rotate them). In the case of a breach or compromise, an unaccounted-for key could mean prolonged access for an attacker. This potential blind spot, plus the management overhead of key inventory and rotation, makes using service account keys as secrets a less than ideal method for authenticating GKE workloads.
Exact... and it's a recent alternative to secrets ... why would google want you to ignore it? :)
I assume that nobody read through the official docs and GCP Best practices for K8s and Cloud SQL. https://cloud.google.com/sql/docs/mysql/connect-kubernetes-engine#secrets "A database credentials Secret includes the name of the database user you are connecting as, and the user's database password." The best answer here is B, having K8s Secrets is the go-to method to configure and store sensitive information within a cluster such as Spanner credentials
I think A is correct
I vote A https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity
Yes could be Option A , also Option B could work, not sure if Option B is not right considering the question states minimum code changes?
yes is better b
B. The question is not about how to connect/access Cloud Spanner, but is how to "retrieve Spanner *credentials*".
I think B is more suitable in this situation
This approach involves configuring service accounts with the necessary permissions to access the Spanner database. By using Workload Identity, you can associate these service accounts with your Kubernetes Engine pods, allowing them to authenticate and retrieve Spanner credentials automatically.
Google recommends using service accounts and work load identity whenever possible
Exactly!
Answer is A Store the application credentials as Kubernetes Secrets, and expose them as environment variables
Sorry i dwant to paste the link to A, not answer B. B is wrong. https://kubernetes.io/docs/concepts/configuration/secret/#alternatives-to-secrets Answer A
It cant be B because Because Secrets can be created independently of the Pods that use them, there is less risk of the Secret (and its data) being exposed during the workflow of creating, viewing, and editing Pods. Kubernetes, and applications that run in your cluster, can also take additional precautions with Secrets, such as avoiding writing secret data to nonvolatile storage. Secrets are similar to ConfigMaps but are specifically intended to hold confidential data. Caution: Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any Secret in that namespace; this includes indirect access such as the ability to create a Deployment.
Yes A is the option
The best answer here is A. Configure the appropriate service accounts, and use Workload Identity to run the pods. Here's why: Workload Identity: Workload Identity is a Google Cloud feature that allows Kubernetes service accounts to act as Google Cloud IAM service accounts. This means your pods can authenticate to Spanner without needing to store credentials directly within the pod.
Let's break down why the other options are less ideal: B. Store credentials as Kubernetes Secrets: While this approach works, it's less secure than Workload Identity. Storing credentials in Secrets exposes them to potential security risks within the cluster. C. VPC-native cluster and routing rules: This approach focuses on network connectivity but doesn't address the core issue of secure credential management. D. Cloud Key Management Service (KMS): KMS is excellent for managing encryption keys, but it's not the primary solution for retrieving Spanner credentials. KMS is more suited for encrypting data at rest.
Why Workload Identity is the Best Practice: Security: Workload Identity eliminates the need to store sensitive credentials within your pods, making your application more secure. Simplified Management: You can manage access control and permissions through Google Cloud IAM, which is easier than managing credentials within your Kubernetes cluster. Integration with Google Cloud: Workload Identity seamlessly integrates with Google Cloud services, making it a natural choice for applications running on GKE.
Option A is the recommended approach for securely configuring your microservice-based application to retrieve Spanner credentials on Google Kubernetes Engine (GKE)
i go for B question is about how to RETRIEVE db creds https://cloud.google.com/sql/docs/mysql/connect-kubernetes-engine#secrets A is about how to connect to spanner
A. Configure the appropriate service accounts, and use Workload Identity to run the pods. Workload Identity is a way to associate Kubernetes service accounts with Google Cloud IAM service accounts, allowing your pods to authenticate to Google Cloud services using their IAM identity. This means that you don't have to store application credentials in your code or in Kubernetes Secrets, and you can manage the permissions of your application in Google Cloud IAM. You would need to create service account in cloud IAM and a Kubernetes service account and then map them to use Workload Identity. You can also use gcloud command line to map the Kubernetes service account to the desired IAM service account. Then in your application, you can use the Kubernetes service account to authenticate to Spanner, which will authenticate as the mapped IAM service account. This way you don't have to hardcode credentials in your code, and you can easily manage the permissions of your application using Google Cloud IAM.
A is the answer. https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity#what_is Applications running on GKE might need access to Google Cloud APIs such as Compute Engine API, BigQuery Storage API, or Machine Learning APIs. Workload Identity allows a Kubernetes service account in your GKE cluster to act as an IAM service account. Pods that use the configured Kubernetes service account automatically authenticate as the IAM service account when accessing Google Cloud APIs. Using Workload Identity allows you to assign distinct, fine-grained identities and authorization for each application in your cluster.
A and B ,both are correct. Curently in my project we are using A for allowing pods to query Bigquery. So A and B both seems to be correct.
A service account will only allow you to establish your workload identity(basically authenticate the identity of your cluster pods). But, in order to establish a database connection, you would need to connect it using the DB credentials( like host, user id, password, and database name to connect to). To securely store such credentials, Google recommends using a Secret Manager. So the answer would be B!
A and B -> It should be select 2 best options question.