cloudscheduler: fix headers drift when oidc_token/oauth_token is set#17074
Conversation
…auth tokens are set
Cloud Scheduler injects an `Authorization` header server-side whenever
`http_target.oidc_token` or `http_target.oauth_token` is configured. The
existing `http_headers` flattener did not strip it, so the value showed up
in state and produced a perpetual diff against the user-supplied `headers`
map.
The strip is gated on the presence of one of the token blocks under
`http_target`, so:
* Pubsub-only jobs (no `http_target` block) are unaffected — the
`d.Get("http_target.0.oidc_token.#")` lookups return zero.
* App Engine HTTP targets (which have no token blocks) are unaffected
for the same reason.
* Users who legitimately set a literal `Authorization` header without
token auth keep the existing behaviour.
Also surface a validation warning (not an error) when both `Authorization`
and one of the token blocks would otherwise collide, so users get a hint
before they hit the drift.
Adds unit-test coverage for: oidc-set strip, oauth-set strip, no-token
preservation, and the existing app-engine flattener path.
modular-magician
added
the
awaiting-approval
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
Googlers: For automatic test runs see go/terraform-auto-test-runs. @c2thorn, a repository maintainer, has been assigned to review your changes. If you have not received review feedback within 2 business days, please leave a comment on this PR asking them to take a look. You can help make sure that review is quick by doing a self-review and by running impacted tests locally. |
|
@c2thorn This PR has been waiting for review for 3 weekdays. Please take a look! Use the label |
2 participants
Fixes a perpetual diff on
google_cloud_scheduler_job.http_target.headerswhenoidc_tokenoroauth_tokenis configured. The Cloud Scheduler API injects anAuthorizationheader server-side in that case, which the existing flattener was not stripping — so the API-injected value landed in state and Terraform repeatedly tried to remove it.The fix is gated on the presence of one of the token blocks under
http_target, so:http_targetblock at all) are unaffected.app_engine_http_target.headers(which has nooidc_token/oauth_tokensiblings) is unaffected.Authorizationheader without token auth keep the existing preservation behaviour.A validation warning (not an error) is also surfaced when both
Authorizationand a token block are configured, so users see a hint before hitting the drift.Tests
TestCloudScheduler_FlattenHttpHeaders_AuthorizationStrippedWithOidccovers the oidc-set, oauth-set, and no-token cases against the http_target flattener using a populated*schema.ResourceData.TestCloudScheduler_FlattenHttpHeaderswith a regression case asserting the App Engine flattener still preserves a literalAuthorizationheader (pubsub/app-engine safety guard).No related upstream issue found in
hashicorp/terraform-provider-google, so noFixeslink.