Workload Identity in GKE to fetch data from Google Cloud Storage.

[@liamray2010]

Thank you for the explanation! I was a bit scared of your hand in the end haha :)

[@navinkumar6388]

Thanks with Love from India 🇮🇳

[@OutOfDevOps]

Thank you for the kind comment

[@navinkumar6388]

@@OutOfDevOps I am shifting from Java Spring Microsercice to DevOps About to face interviews and Just came across your GCP, Kubernetes and Docker. Hope with the help of your videos 📷 I can win a match

[@alexanderpopov9801]

Thank you, Anto, that was useful to me! ❤

[@OutOfDevOps]

Glad it was helpful!

[@lifewinsful]

nice explanation

[@OutOfDevOps]

Thanks and welcome

[@kavindudananjaya3290]

Thanks

[@maalamhrez7361]

neat and clean, thank!

[@OutOfDevOps]

Thank you

[@scratchbin]

Very clear. Thanks

[@OutOfDevOps]

You are very welcome 😎

[@AndrewLee-k2m]

great tutorial

[@ggdio1]

Whats the advantage of using Workload Identity istead of traditional KMS and service accouts?

[@OutOfDevOps]

Hi @ggdio1, what do you mean with “traditional KMS and service accounts”? Workload Identity allows you to seamlessly map K8S services accounts with GCP service accounts. It will use temporary credentials instead of (the discouraged) service account keys mounted as secrets (or even worse, over privileged sa assigned to nodes).

[@ggdio1]

@@OutOfDevOps most of time when deploying apps we need service accounts for like accessing databases, services, etc. We shouldn't at all put the service account keys into docker images because it isn't secure at all, so the best practice is to encrypt it using KMS and inject the pod with the keys. What I'm asking is what's the advantages and security improvements of doing that process with workload identities instead of the process I just described. BTW lmk if I'm completely wrong about the KMS method lol

[@OutOfDevOps]

@ggdio1 baking sa keys in container images hasn’t crossed my mind not even for a second. Even with kms encryption and pod injection, how do you make sure only that workload can decrypt and how do you proceed with the injection? The best practice is workload identity… With workload identity all that is done for you, in addition combined with RBAC in K8S you have full solution. You can map a K8S sa to a GCP sa, without creating custom solutions for injection and sharing access to the same KMS keys.

[@ggdio1]

@@OutOfDevOps sounds great, now I get the concept, thanks a lot. I will consider using it on next projects!

[@QuangPham-bc7lc]

i have create firewall but still can't access. And if we use workload identity, which SA will GKE use (SA of nodepool or SA of workload identity) to pull container image from image registry like GAR or GCR?

[@rohitthakur1628]

If you haven't explicitly provided the workload identity SA name in the pod manifest then Default GKE node pool/machine's SA is used to the pull the images from GCR. That's my understanding. And if you provide the workload identity SA name then its permission is used for required interaction with other gcp resources.

[@prajeetkumbhare8437]

I have followed the same but I am unable to put to delete files from bucket

[@rohitthakur1628]

For deleting objects in a bucket, you need a role with bucket write permission. Video showed the object viewer role only which can only fetch/read the bucket objects

[@harkiratsingh5253]

Hey thanks for the video.. I am doing the same thing where i need to fetch images for GCP artifact registry, however i am getting issue -> failed to pull and unpack image "us-central1-docker.pkg.dev/xxxxxxxxxxx/jenkins/jenkins-slave:v2": failed to resolve reference "us-central1-docker.pkg.dev/xxxxxxxx/jenkins/jenkins-slave:v2": failed to authorize: failed to fetch oauth token: unexpected status from GET request to ....403 Forbidden, what to do here

[@luizhpriotto]

You should set the role (roles/artifactregistry.writer) to the service account of computers node, not in the deployment..