fix: missing auth header in impersonated service account credentials#556
Open
BSick7 wants to merge 1 commit into
Open
fix: missing auth header in impersonated service account credentials#556BSick7 wants to merge 1 commit into
BSick7 wants to merge 1 commit into
Conversation
| auth_header = {} | ||
| @source_credentials.updater_proc.call auth_header | ||
| auth_header | ||
| @source_credentials.updater_proc.call {} |
There was a problem hiding this comment.
For us we needed to keep defining the auth_header here. The fix seems to be removing auth_header from the return
def prepare_auth_header
auth_header = {}
@source_credentials.updater_proc.call auth_header
end
This was referenced Jul 14, 2026
iamKunalGupta
added a commit
to iamKunalGupta/ubicloud
that referenced
this pull request
Jul 14, 2026
Allow GCP to run without long-lived JSON service account keys (control-plane key per location, per-timeline key on the VM for WAL-G), mirroring the AWS provider's IAM-role path. The VM and postgres layers are gated behind the new `gcp_postgres_iam_access` config (default off); both key-based modes keep working unchanged. With location_credential_gcp.credentials_json now nullable, the control plane impersonates the location's service_account_email via Application Default Credentials (requires roles/iam.serviceAccountTokenCreator on the location service account). With `gcp_postgres_iam_access` on, each VM gets its own service account vm-<ubid> attached with cloud-platform scope, and postgres servers grant it roles/storage.objectAdmin on their timeline bucket instead of minting per-timeline keys; WAL-G authenticates through the metadata server. Timelines with an existing access_key keep using it. IAM propagation of a fresh account is retried at both the insert rejection and the create operation failing with EXTERNAL_RESOURCE_NOT_FOUND. On destroy, grants are detached from the current and parent timeline buckets before the service account is deleted, since a deleted account's policy member becomes a deleted:...?uid= entry the detach can no longer match. The resource row is gone before server strands finish tearing down, so provider dispatch on PostgresServer falls back to the VM's location. lib/gcp_impersonated_credentials_patch.rb backports googleapis/google-auth-library-ruby#556, required for impersonation under GKE Workload Identity; remove it once a googleauth release includes the fix.
iamKunalGupta
added a commit
to iamKunalGupta/ubicloud
that referenced
this pull request
Jul 14, 2026
Allow GCP to run without long-lived JSON service account keys (control-plane key per location, per-timeline key on the VM for WAL-G), mirroring the AWS provider's IAM-role path. The VM and postgres layers are gated behind the new `gcp_postgres_iam_access` config (default off); both key-based modes keep working unchanged. With location_credential_gcp.credentials_json now nullable, the control plane impersonates the location's service_account_email via Application Default Credentials (requires roles/iam.serviceAccountTokenCreator on the location service account). With `gcp_postgres_iam_access` on, each VM gets its own service account vm-<ubid> attached with cloud-platform scope, and postgres servers grant it roles/storage.objectAdmin on their timeline bucket instead of minting per-timeline keys; WAL-G authenticates through the metadata server. Timelines with an existing access_key keep using it. IAM propagation of a fresh account is retried at both the insert rejection and the create operation failing with EXTERNAL_RESOURCE_NOT_FOUND. On destroy, grants are detached from the current and parent timeline buckets before the service account is deleted, since a deleted account's policy member becomes a deleted:...?uid= entry the detach can no longer match. The resource row is gone before server strands finish tearing down, so provider dispatch on PostgresServer falls back to the VM's location. lib/gcp_impersonated_credentials_patch.rb backports googleapis/google-auth-library-ruby#556, required for impersonation under GKE Workload Identity; remove it once a googleauth release includes the fix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes an issue reporting that service account impersonation isn't working: #353.
The fixed code changes how ImpersonatedServiceAccountCredentials adds the auth header to its client. The primary issue was that the hash passed into the
applyfunction is not mutated. Instead, the underlying implementations copies the hash, performs authentication, then returns the copy. Theprepare_auth_headermethod was changed to align with the underlying implementation.