You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey Devs! Great project, thanks for your hard work and continued maintenance.
Following the sidecar pattern, we aim to forward logs to Google StackDriver through the zipkin docker container. The issue is, we're not mounting our service account key directly, instead we use (workload identity federation)[https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity] to inject a short lived service account token directly into the docker image. Using identity federation, your workload can impersonate a service account. This lets the external workload access Google Cloud resources directly, eliminating the maintenance and security burden associated with service account keys. This is the recommended solution for authenticating with google services from GKE.
The token is mounted at /var/run/secrets/kubernetes.io/serviceaccount/token and if we specify point the GOOGLE_APPLICATION_CREDENTIALS to this path, we encounter a decoding error because the token is a base64 encoded Json Web Token.
A work around would be to run some PostStart script to decode the token and remount it somewhere else for Zipkin to use or zipkin-gcp should support workload identity. This is a messy, and unstable solution because there is no guarantee that script will execute before the entry point to zipkin.
It would be great if zipkin-gcp would support workload identity out of the box (i.e. if no GOOGLE_APPLICATION_CREDENTIALS is provided or if a specific flag/environment variable was set).
Rationale
Handling and mounting additional key material is dangerous. As workload identity is the recommended authentication mechanism for GKE (Kubernetes), this would likely be helpful to many others. Using workload identity federation, applications can access Google Cloud resources from Amazon Web Services (AWS), Microsoft Azure, or any identity provider that supports OpenID Connect (OIDC).
Example Scenario
Zero configuration startup, the google cloud project and token could be extracted by default.
A flag could be set like GKE_WORKLOAD_IDENTITY=true to enable automatic configuration.
Feature
Hey Devs! Great project, thanks for your hard work and continued maintenance.
Following the sidecar pattern, we aim to forward logs to Google StackDriver through the zipkin docker container. The issue is, we're not mounting our service account key directly, instead we use (workload identity federation)[https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity] to inject a short lived service account token directly into the docker image. Using identity federation, your workload can impersonate a service account. This lets the external workload access Google Cloud resources directly, eliminating the maintenance and security burden associated with service account keys. This is the recommended solution for authenticating with google services from GKE.
The token is mounted at
/var/run/secrets/kubernetes.io/serviceaccount/token
and if we specify point theGOOGLE_APPLICATION_CREDENTIALS
to this path, we encounter a decoding error because the token is a base64 encoded Json Web Token.A work around would be to run some PostStart script to decode the token and remount it somewhere else for Zipkin to use or zipkin-gcp should support workload identity. This is a messy, and unstable solution because there is no guarantee that script will execute before the entry point to zipkin.
It would be great if zipkin-gcp would support workload identity out of the box (i.e. if no
GOOGLE_APPLICATION_CREDENTIALS
is provided or if a specific flag/environment variable was set).Rationale
Handling and mounting additional key material is dangerous. As workload identity is the recommended authentication mechanism for GKE (Kubernetes), this would likely be helpful to many others. Using workload identity federation, applications can access Google Cloud resources from Amazon Web Services (AWS), Microsoft Azure, or any identity provider that supports OpenID Connect (OIDC).
Example Scenario
Zero configuration startup, the google cloud project and token could be extracted by default.
A flag could be set like
GKE_WORKLOAD_IDENTITY=true
to enable automatic configuration.Prior Art
https://github.com/googleapis/google-auth-library-java
https://googleapis.dev/python/google-auth/latest/user-guide.html
The text was updated successfully, but these errors were encountered: