Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow use of k8s service accounts and workload identity for auth #127

Open
elibixby opened this issue Sep 19, 2022 · 8 comments
Open

Allow use of k8s service accounts and workload identity for auth #127

elibixby opened this issue Sep 19, 2022 · 8 comments

Comments

@elibixby
Copy link

elibixby commented Sep 19, 2022

The driver should likely be configured with a k8s service account (either in PVC config or storage class config) that has permissions to the bucket via Workload Identity rather than using a key.

Details here: https://kubernetes.io/blog/2020/12/18/kubernetes-1.20-pod-impersonation-short-lived-volumes-in-csi/#using-gcp-apis

@sshcherbakov
Copy link

+1
The Cloud SDK libraries support using Workload Identity for authentication by either contacting local metadata server when running on GCE or GKE or by accepting fleet workload identity configuration in the GOOGLE_APPLICATION_CREDENTIALS environment variable instead of the json file with service account key as described here (please see step 6 for example).

Similar Google Secret Manager CSI driver supports workload identity when running on GKE (and in Anthos clusters outside of GCP hopefully soon), not relying on the Cloud SDK client libraries though.

@ofek
Copy link
Owner

ofek commented Nov 1, 2022

We'd happily accept a PR 🙂

@lancehudson
Copy link

lancehudson commented Nov 8, 2022

This doesnt work with hostNetwork. I can however confirm that if you disable hostNetworking in the DaemonSet that workload identity starts working.

@lemaral
Copy link

lemaral commented Nov 29, 2022

Is hostNetwork necessary then? It seems to work without

@sshcherbakov
Copy link

I am not sure how hostNetwork is related to WIF. WIF introduces additional credential type "external_account" for the client authentication libraries to be supported. The implementation would need to make a couple of calls to the endpoints defined in the config file. I don't think that setting hostNetwork to any value would remove the need in the WIF authentication flow calls.

@sshcherbakov
Copy link

When it "works", are you sure that you are authenticating as "workload" (serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]) rather than a single GSA, that the underlying GCE VM is running with?

@lancehudson
Copy link

Ill dig through the audit logs but the nodes dont have access (it was failing before i disabled hostnetworking)

Doesnt the library you are using for gcs automatically use the metadata service if no credentials are specified?

@sshcherbakov
Copy link

It does, but 1) it depends on the environment where you are, e.g. GCE, GKE, non-GCP 2) the point of WIF is to work seamlessly (similarly) in environments outside of GCP (on-prem, VMware, AWS, Azure, etc) where metadata server (neither GCE nor GKE one) is not available and simultaneously not to require GSA keys for authentication.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants