You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unlike common k8s deployments, the AKS deployment does not generate kubelet’s self-signed certificate from the CA that issues the kube-apiserver certificate, so the Service Account CA /var/run/secrets/kubernetes.io/serviceaccount/ca.crt which is added to the receiver’s client rootCA will still fail to verify the kubelet’s cert.
To address this issue, we need to use a kubelet client with the correct CA that AKS used to generate the cert /etc/kubernetes/certs/kubeletserver.crt
At first I thought that the configtls options ca_file , which is exposed to the receiver, would do the trick, but after going through the code, I have noticed this option is not used when the auth type is serviceaccount.
We should check if ca_file is set and use it instead of the default /var/run/secrets/kubernetes.io/serviceaccount/ca.crt for service account
The text was updated successfully, but these errors were encountered:
Pinging code owners for receiver/kubeletstatsreceiver: @dmitryax@TylerHelmuth@ChrsMark. See Adding Labels via Comments if you do not have permissions to add labels yourself. For example, comment '/label priority:p2 -needs-triaged' to set the priority and remove the needs-triaged label.
…configtls option (open-telemetry#39297)
#### Description
This PR allows user to define a custom CA for service account .
If ca_file is set, we load the user defined CA Path and skip the service
account CA Path
#### Link to tracking issue
Fixesopen-telemetry#39291
<!--Describe what testing was performed and which tests were added.-->
Added an extra unit test and manually validated that it addressed the
issue on
[AKS](open-telemetry#39291)
#### Documentation
Update the kubeletstats receiver README with info on when to use custom
CA
Signed-off-by: Dani Louca <[email protected]>
Fiery-Fenix
pushed a commit
to Fiery-Fenix/opentelemetry-collector-contrib
that referenced
this issue
Apr 24, 2025
…configtls option (open-telemetry#39297)
#### Description
This PR allows user to define a custom CA for service account .
If ca_file is set, we load the user defined CA Path and skip the service
account CA Path
#### Link to tracking issue
Fixesopen-telemetry#39291
<!--Describe what testing was performed and which tests were added.-->
Added an extra unit test and manually validated that it addressed the
issue on
[AKS](open-telemetry#39291)
#### Documentation
Update the kubeletstats receiver README with info on when to use custom
CA
Signed-off-by: Dani Louca <[email protected]>
Component(s)
No response
Describe the issue you're reporting
Unlike common k8s deployments, the
AKS
deployment does not generate kubelet’s self-signed certificate from the CA that issues the kube-apiserver certificate, so the Service Account CA/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
which is added to the receiver’s client rootCA will still fail to verify the kubelet’s cert.To address this issue, we need to use a kubelet client with the correct CA that AKS used to generate the cert
/etc/kubernetes/certs/kubeletserver.crt
At first I thought that the configtls options
ca_file
, which is exposed to the receiver, would do the trick, but after going through the code, I have noticed this option is not used when the auth type is serviceaccount.We should check if
ca_file
is set and use it instead of the default/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
for service accountThe text was updated successfully, but these errors were encountered: