Skip to content
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

User agent header not correct #3267

Closed
ringods opened this issue Oct 16, 2024 · 2 comments · Fixed by #3294
Closed

User agent header not correct #3267

ringods opened this issue Oct 16, 2024 · 2 comments · Fixed by #3294
Assignees
Labels
kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed
Milestone

Comments

@ringods
Copy link
Member

ringods commented Oct 16, 2024

What happened?

A customer reports that the HTTP header used for the user agent is not sent correctly. See the example below.

  • the header name should not be userAgent but User-Agent
  • the actual provider binary version is missing. It reports v0.0.0
  • there is a possible interpolation not working correctly, leading to an explicit $Format string being rendered

Example

Taken from the Kubernetes audit logs:

"userAgent": "pulumi-resource-kubernetes/v0.0.0 (darwin/arm64) kubernetes/$Format",

Output of pulumi about

CLI
Version      3.134.1
Go Version   go1.23.1
Go Compiler  gc

Plugins
KIND      NAME        VERSION
resource  aws         6.53.0
resource  cloudinit   1.4.7
resource  kubernetes  4.18.1
language  python      unknown
resource  random      4.16.5

Host
OS       darwin
Version  14.5
Arch     arm64

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@ringods ringods added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team labels Oct 16, 2024
@blampe
Copy link
Contributor

blampe commented Oct 21, 2024

@ringods can you share how the user is setting this header? Is this part of an Automation API program?

@blampe blampe added awaiting-feedback Blocked on input from the author and removed needs-triage Needs attention from the triage team labels Oct 21, 2024
@rquitales
Copy link
Member

The user-agent is likely coming from client-go's default:
https://github.com/kubernetes/client-go/blob/23900f492969db045e8a36396852381fd189569b/rest/config.go#L495-L508

Without digging too deep, the fix for this probably requires us to accurately set the user-agent here:

var config *rest.Config
if !k.clusterUnreachable {
contract.Assertf(kubeconfig != nil, "expected kubeconfig to be initialized")
var err error
config, err = kubeconfig.ClientConfig()
if err != nil {
k.clusterUnreachable = true
k.clusterUnreachableReason = fmt.Sprintf("unable to load Kubernetes client configuration from kubeconfig file. Make sure you have: \n\n"+
" \t • set up the provider as per https://www.pulumi.com/registry/packages/kubernetes/installation-configuration/ \n\n %v", err)
config = nil
} else {
if kubeClientSettings.Burst != nil {
config.Burst = *kubeClientSettings.Burst
helmSettings.BurstLimit = *kubeClientSettings.Burst
logger.V(9).Infof("kube client burst set to %v", config.Burst)
}
if kubeClientSettings.QPS != nil {
config.QPS = float32(*kubeClientSettings.QPS)
helmSettings.QPS = float32(*kubeClientSettings.QPS)
logger.V(9).Infof("kube client QPS set to %v", config.QPS)
}
if kubeClientSettings.Timeout != nil {
config.Timeout = time.Duration(*kubeClientSettings.Timeout) * time.Second
helmFlags.Timeout = ptr.To(strconv.Itoa(*kubeClientSettings.Timeout))
logger.V(9).Infof("kube client timeout set to %v", config.Timeout)
}
config.WarningHandler = rest.NoWarnings{}
}
}
var err error
k.clientSet, k.logClient, err = k.makeClient(k.canceler.context, config)

@rquitales rquitales removed the awaiting-feedback Blocked on input from the author label Oct 22, 2024
@mjeffryes mjeffryes assigned EronWright and blampe and unassigned EronWright Oct 28, 2024
@mjeffryes mjeffryes added this to the 0.112 milestone Oct 30, 2024
@blampe blampe closed this as completed in e49daf0 Oct 31, 2024
@pulumi-bot pulumi-bot added the resolution/fixed This issue was fixed label Oct 31, 2024
blampe added a commit that referenced this issue Oct 31, 2024
- Objects created on clusters older than 1.18 will no longer see a
  `before-first-apply` conflict when Pulumi performs a server-side apply for
  the first time. (#3275)

- The provider's user agent is now set correctly when communicating with
  the Kubernetes API server.
  (#3267)
blampe added a commit that referenced this issue Oct 31, 2024
- Objects created on clusters older than 1.18 will no longer see a
  `before-first-apply` conflict when Pulumi performs a server-side apply for
  the first time. (#3275)

- The provider's user agent is now set correctly when communicating with
  the Kubernetes API server.
  (#3267)
rquitales pushed a commit that referenced this issue Oct 31, 2024
### Fixed

- Objects created on clusters older than 1.18 will no longer see a
`before-first-apply` conflict when Pulumi performs a server-side apply
for the first time.
(#3275)

- The provider's user agent is now set correctly when communicating with
the Kubernetes API server.
(#3267)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants