Skip to content

LOG-9171: Add support for GCP workload identity federation v0.54#263

Open
vparfonov wants to merge 5 commits intoViaQ:v0.54.0-rhfrom
vparfonov:fix-gcp-wif
Open

LOG-9171: Add support for GCP workload identity federation v0.54#263
vparfonov wants to merge 5 commits intoViaQ:v0.54.0-rhfrom
vparfonov:fix-gcp-wif

Conversation

@vparfonov
Copy link
Copy Markdown

@vparfonov vparfonov commented Apr 22, 2026

Following PR: #249

Core changes (src/gcp.rs)

  • Replace goauth + smpl_jwt libraries with official google-cloud-auth v1.6
  • Implement scopes for External Account credentials (Workload Identity Federation)
  • Add token refresh logic with 1-hour expiry
  • Maintain backward compatibility with all existing authentication methods

New changes:

  • Compilation fix:
    • PUBSUB_ADDRESS static was accidentally removed from src/gcp.rs but is still referenced in 4 integration test files (src/sinks/gcp/pubsub.rs, src/sources/gcp_pubsub.rs). This was causing the unit: FAILED CI status.
    • Restored the LazyLock static and its import.
  • Security (least-privilege):
    • Chronicle sink was changed from Scope::MalachiteIngestion to scopes::CLOUD_PLATFORM, which grants access to all GCP APIs. Restored the original narrow scope by adding MALACHITE_INGESTION (https://www.googleapis.com/auth/malachite-ingestion) as a scope constant.
  • Test coverage:
    • The fails_missing_creds test was removed from gcp::tests without replacement.
    • Added a falls_back_to_adc test that verifies the ADC fallback path doesn't panic.
  • Code cleanup:
    • Applied cargo fmt
    • Fix the cargo-fmt-check

/assign @jcantrill
/cc @cahartma @Clee2691

https://redhat.atlassian.net/browse/LOG-9171

cahartma and others added 2 commits April 8, 2026 17:48
- Restore PUBSUB_ADDRESS static removed by accident (fixes compilation)
- Add MALACHITE_INGESTION scope for Chronicle sink (least-privilege)
- Add falls_back_to_adc test to gcp::tests
- Document ScopedEnv rationale (no with_credentials_file() API)
- Remove dev comment from spawn_regenerate_token
- Trim verbose test comments in pubsub and stackdriver tests
- Apply cargo fmt

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@vparfonov
Copy link
Copy Markdown
Author

/hold

@vparfonov vparfonov changed the title Fix gcp wif WIP:Fix gcp wif Apr 22, 2026
@openshift-ci openshift-ci Bot requested review from cahartma and jcantrill April 22, 2026 16:45
@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented Apr 22, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: vparfonov
Once this PR has been reviewed and has the lgtm label, please assign jcantrill for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Comment thread src/gcp.rs Outdated
// The google-cloud-auth Builder has no with_credentials_file() method.
// The GOOGLE_APPLICATION_CREDENTIALS env var is the only way to pass
// a credentials path. ScopedEnv restores the original value on drop.
let _guard = ScopedEnv::set("GOOGLE_APPLICATION_CREDENTIALS", path);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this correct in there is no way for us to support isolating credentials for multiple GCP outputs?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is a limitation of the google-cloud-auth library — its Builder has no with_credentials_file() method, so the GOOGLE_APPLICATION_CREDENTIALS env var is the only way to pass a credentials path.
The env var is only set temporarily during build_access_token_credentials() call. After that the ScopedEnv guard drops, restores the original value, and each GCP output holds its own independent AccessTokenCredentials instance with its own credentials. So at runtime, multiple GCP outputs with different credentials work fine.
The only theoretical risk is during initialization: if two GCP outputs with different credentials_path values call build() concurrently, they could race on the env var. In practice Vector builds sink configs sequentially during startup, so this doesn't happen.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this mean in practice? Do we need to set this var? Do these credentials need to be a parent or some set of credentials that delegates to the individual outputs? Maybe these questions are not relevant for the collector but more so for the operator

@vparfonov vparfonov changed the title WIP:Fix gcp wif LOG-9171: Add support for GCP workload identity federation v0.54 Apr 22, 2026
@openshift-ci-robot
Copy link
Copy Markdown

openshift-ci-robot commented Apr 22, 2026

@vparfonov: This pull request references LOG-9171 which is a valid jira issue.

Details

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@vparfonov
Copy link
Copy Markdown
Author

/test unit

2 similar comments
@vparfonov
Copy link
Copy Markdown
Author

/test unit

@vparfonov
Copy link
Copy Markdown
Author

/test unit

@jcantrill
Copy link
Copy Markdown
Member

This should merge after #249? Replace #249?

- make_token(): replace .ok() with proper error logging and rate
  limiting so token fetch failures are visible instead of causing
  opaque 403 responses
- from_file(): add mutex around ScopedEnv to prevent concurrent
  sink initializations from racing on GOOGLE_APPLICATION_CREDENTIALS

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@vparfonov
Copy link
Copy Markdown
Author

/test unit

google-cloud-auth 1.8.0 requires serde_json >= 1.0.148, which changed
float exponent formatting from e308 to e+308. Update fixtures to match.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@vparfonov
Copy link
Copy Markdown
Author

This should merge after #249? Replace #249?

Replace #249

@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented Apr 28, 2026

@vparfonov: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/unit 3cd574e link true /test unit
ci/prow/cluster-logging-operator-e2e 090cf73 link true /test cluster-logging-operator-e2e
ci/prow/clo-functional 090cf73 link true /test clo-functional

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

…json 1.0.149+

serde_json 1.0.149 replaced ryu with zmij for float serialization, which
uses scientific notation for very large floats. This caused a mismatch
between ryu::Buffer::format_finite() and actual JSON output, breaking
the estimate_f32 and serialize_f64 quickcheck tests.

Use serde_json::to_string() directly so the estimation always matches
the actual serialized output regardless of future serde_json changes.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants