You are creating and running containers across different projects in Google Cloud. The application you are developing needs to access Google Cloud services from within Google Kubernetes Engine (GKE). What should you do?
A.
Assign a Google service account to the GKE nodes.
B.
Use a Google service account to run the Pod with Workload Identity.
C.
Store the Google service account credentials as a Kubernetes Secret.
D.
Use a Google service account with GKE role-based access control (RBAC).
The best way to access Google Cloud services from within Google Kubernetes Engine (GKE) is to use a Google service account to run the Pod with Workload Identity.
Workload Identity allows your pods to authenticate to Google Cloud services using their Kubernetes service account credentials, without you having to expose any sensitive credentials in your code.
Application images runs as a container within a POD as a process. So Pod should be identified as a principle here and it should have a service account to access other services within GKE cluster.
In summary, using Workload Identity allows you to authenticate your application to Google Cloud services using the same identity that runs the application, this makes it simple to manage the access and permissions to resources, and also ensures that your application only has the necessary permissions to access the services.
The correct answer is B: Use a Google service account to run the Pod with Workload Identity.
Workload Identity allows you to authenticate to Google Cloud services using the same identity that runs your application, instead of creating and managing a separate service account. This simplifies the process of granting permissions to your application, and ensures that it only has the necessary access to resources.
When you assign a Google service account to GKE nodes (Option A), it can be difficult to manage the permissions needed by the application and also could be a security issue since it grants access to all the services that the service account has permissions to.
Use a Google service account with GKE role-based access control (RBAC) (Option D) is not the recommended approach, while RBAC is good to restrict and manage access to resources, it's not the best fit for authenticating the workloads to access the Google Cloud services.
Storing the Google service account credentials as a Kubernetes Secret (Option C) can be a security concern, since the credentials may be easily accessed by unauthorized parties.
When you assign a Google service account to GKE nodes (Option A), it can be difficult to manage the permissions needed by the application and also could be a security issue since it grants access to all the services that the service account has permissions to.
B 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 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.
Blueocean
Highly Voted 2 years, 9 months agoalpha_canary
Most Recent 6 months, 1 week ago__rajan__
1 year, 1 month agopurushi
1 year, 2 months agoomermahgoub
1 year, 9 months agoomermahgoub
1 year, 9 months agoomermahgoub
1 year, 9 months agoomermahgoub
1 year, 9 months agoomermahgoub
1 year, 9 months agozellck
1 year, 10 months agotomato123
2 years, 2 months agoakshaychavan7
2 years, 2 months agonqthien041292
2 years, 6 months agojitu028
2 years, 6 months agoassuf
2 years, 9 months ago