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
Workload Identity Federation only working with uniform bucket level access? #3556
Comments
Thanks for the report. I honestly don't know the details of Uniform Bucket Access to comment directly, but let's dig in a bit. Let's focus on the second of the two errors. It's logged here: tempo/tempodb/blocklist/poller.go Line 242 in 0dd31db
Which is passed through here: Line 108 in 0dd31db
And ultimately lands on this call: tempo/tempodb/backend/gcs/gcs.go Line 107 in 0dd31db
I'm not sure what underlying GCS call that maps to, but I believe we're using the standard SDK in an appropriate manner. What's interesting is Tempo writes data all the time using this call for the blocks. Are you seeing any issues with your ingesters or compactors flushing/creating blocks? The main difference I can think of is where in the object hierarchy the objects are written: is broken:
seemingly works:
|
Google have updated their docs and now explain why this is happening. Apparently setting 'Uniform Bucket Level Access' to true is a requirement when using IAM principals for Workload Identity Federation. The solution they suggest is as I described in the issue - using the 'old' method of linking a k8s account to an IAM account. See here: https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#kubernetes-sa-to-iam @joe-elliott Thanks for your assistance and time! |
We are running Tempo on GKE and using a GCS bucket with uniform bucket level access set to 'false' as a storage backend. We have had this setup for quite some time and it's been running without problems. Recently we switched from using the "old" Workload Identity Federation (creating both a Kubernetes and a IAM Service account, linking them using an annotation on the Kubernetes account, and granting the necessary roles to the IAM account) to using the updated form of Workload Identity Federation (see here) - Basically, giving Kubernetes Principals permissions on GCP resources directly without the need of also linking to IAM service accounts.
To allow Tempo to access the bucket we have given the following principal the
storage.objectAdmin
role on the bucket and also permissions to list all buckets in the project:We are now seeing errors such as the following every few minutes in the logs:
And also:
We had no issues whatsoever when using the previous form of Workload Identity and it's not documented anywhere that in order to use this type of authorization you need to enable uniform bucket level access. Is this an issue with Tempo? Or a general issue with how the updated Workload Identity Federation works?
Steps to reproduce the behavior:
Expected Behaviour:
Tempo reports no errors regarding the GCS bucket.
Environment:
Additional Context:
tempo.yaml:
The text was updated successfully, but these errors were encountered: