Closed joaopenteado closed 6 months ago
Hi there @joaopenteado :wave:!
Thank you for opening an issue. Our team will triage this as soon as we can. Please take a moment to review the troubleshooting steps which lists common error messages and their resolution steps.
Hi @joaopenteado thanks for opening an issue. This is interesting. Which API call(s) do you think would benefit from having this header? I'm also not sure if that header applies to the sts endpoint (which is inherently unauthenticated).
Hi @sethvargo! Thanks for getting back to me.
I haven't had the time to test this specifically with the STS or IAM Credentials API yet, but it should work according to the documentation.
These parameters are available across all Google REST APIs and gRPC APIs. A system parameter can be specified either using an HTTP query parameter or an HTTP header.
It's worth noting that this feature is available on the Google Terraform provider through the similarly named request_reason
configuration parameter or the CLOUDSDK_CORE_REQUEST_REASON
environment variable.
TL;DR
It would be very useful for auditing and tracking if we were able to specify a
request_reason
input paramater that is included with every API request in theX-Goog-Request-Reason
.Users would also be able to dynamically generate this parameter based on the context of the workflow run or outputs from previous steps.
Detailed design
Additional information
Additional discussion points
Should a default
request_reason
be provided if none is supplied by the user?I often like to include the GitHub actions run/job URL and I think it's a reasonable default, but other might differ.