-
Notifications
You must be signed in to change notification settings - Fork 66
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
TokenCredentialRequestAPI related errors when ImpersonationProxy is being used instead #1920
Comments
Hi @KihyeokK, thanks for creating an issue. When the impersonation proxy is enabled, clients still use the TokenCredentialRequest API during authentication. The TokenCredentialRequest returns an mTLS client certificate. When you are not using the impersonation proxy, that client cert is signed by the Kubernetes API server. When you are using the impersonation proxy, then that client cert is signed by the impersonation proxy itself. Either way, the client may then submit that mTLS client cert as proof of identity when making calls to Kubernetes APIs (either directly or through the impersonation proxy). Aside from some potentially confusing log messages, are you having any trouble authenticating or making API calls? |
Hi @cfryanr , thank you for the fast response! Aside from the logs, there seems to be no issue at all with interacting with the Kubernetes API server. Also just a note, this error log |
That error is part of how Sorry that the log messages errors can be confusing. They are valuable for debugging when something goes wrong, but unfortunately they can also be confusing when everything is working exactly as expected. Shall we close this issue, or did you have any other concerns here? |
@cfryanr Thank you for the clarification! I would like to ask just two more questions:
|
For question 1: Yes, this could also be normal if it only happens briefly after installation and then those errors stop happening. That certificate Secret initially does not exist, and very quickly after installation Pinniped should auto-create and auto-populate that certificate Secret. For question 2: That's a little complicated because of the way that our controller library works (controllers need to return errors when they want to schedule a retry) but perhaps we could find a way to improve it. If we can't find a way to downgrade the error, then we could at least change the text of the error message to make it say that this is normal behavior on cloud provider clusters. I will take a look. |
Closing this for now because the original purpose of this issue is resolved, but please keep asking questions and making suggestions. Thanks for the discussion! |
@cfryanr Thank you for the help! |
What happened?
I am running pinniped-concierge v0.28.0 image, using the helm chart https://github.com/vmware-tanzu/pinniped/releases/download/v0.20.0/install-pinniped-concierge.yaml on GKE 1.28. If I understand things correctly,
ImpersonationProxy
should be being used instead ofTokenCredentialRequestAPI
, as I can't run any custom pod on the same control plane node runningkube-controller-manager
, and the helm chart setsspec.impersonationProxy.mode
asauto
by default, as mentioned in the docs here. However, I am getting error logs from concierge that seem to be related to the use ofTokenCredentialRequestAPI
like the followingThere was also an error log about: "tls: failed to verify certificate: x509: certificate signed by unknown authority"
Are these error logs supposed to be there when Impersonation Proxy is being used instead of TokenCredentialRequestAPI? Is there a way to disable these logs when Impersonation Proxy is being used?
Thank you!
What did you expect to happen?
Errors mentioned above are not shown when Impersonation Proxy is being used instead of TokenCredentialRequestAPI.
What is the simplest way to reproduce this behavior?
Running helm chart https://github.com/vmware-tanzu/pinniped/releases/download/v0.20.0/install-pinniped-concierge.yaml on GKE 1.28.
In what environment did you see this bug?
kubectl version
): 1.28.3kubeadm version
):cat /etc/os-release
):uname -a
):What else is there to know about this bug?
The text was updated successfully, but these errors were encountered: