Error in Deploying Supervisor with CLI using helm on Single Node cluster

[DevendraJohari24]

Hey Everyone,
I am using pinniped supervisor with pinniped CLI for OIDC Authentication in my single node k3s cluster. I am using helm chart to deploy supervisor. But I am getting the following error.

Error 1: "key failed with : not loading an empty serving certificate from "supervisor-serving-cert"

Questions:

• In helm chart where is the configuration of this certificate. And What it's role in the Pinniped Supervisor.

Error 2: TLS handshake error from 10.42.0.1:51380: EOF

How to stop this TLS handshake with different ports. What does it mean and How to stop it as it generates a lot of logs.

[cfryanr]

Hi @DevendraJohari24,

What Helm Chart did you use? We don't have an official chart from the maintainers, but several other teams and community members have created them.

Where are you seeing those log messages shown in the first screenshot?

Error 2: TLS handshake error from 10.42.0.1:51380: EOF

Sorry about that. It is most likely the incoming Kubernetes liveness and readiness probes causing those log statements. You can verify that by looking at the IPs. At the moment, there is no way to disable them, but they are safe to ignore. However, I'm not sure what the client sent an HTTP request to an HTTPS server is coming from because we configure the liveness and readiness probes to use HTTPS (at least in the official releases, not sure about your Helm Chart).

[DevendraJohari24]

Hey I was using bitnami Repository helm chart. They included pinniped chart to deploy it on cluster.
One of my problem which is related to TLS Handshake is now solved when I deploy it without helm as per the instructions given on your website. But the problem related to dynamiccertificate is still there.

What I am trying to do

I am using k3s single node on-prem cluster. As it is single node, I have to deploy it as minimal as it can. So, I choose Supervisor without Concierge approach. Which works fine if I use kube-api-server args with Supervisor configuration. But I can't use pinniped whoami Feature receiving following error :

What I tried

I then deploy concierge as well. But I have few doubts with this approach:

There are two approaches used by Credential Issuer in pinniped if I am right.

1. KubeClusterSigningCertificate (Preffered) -: what settings I have to do to use this approach in case of on-prem proxied environment k3s cluster. Could you provide sample Config.yaml and CredentialIssuer.yaml in case of that.

2. ImpersonateProxy -: In this case what should be the endpoint domain for ImpersonateProxy is it k3s cluster url (localhost:6443) or concierge endpoint. (Do I need to create a Ingress for Concierge as well in this case).

In below screenshot:

What are these fields discovery url, servingCertificateSecret , impersonationTLSCertificateSecret, impersonationCACertificateSecret, impersonationSignerSecret.

What I didn't understand

1. Is there any way I can use pinniped whoami feature without installing concierge? (It will be much more efficient in our case).
2. What these dynamiccertificate do Is it needed cert-manager or other dependencies as it failed in case of supervisor as well as concierge too?

Pardon me as I asked a lot of things, There are lot more confusions I have related to certificates, configurations as I am using k3 and also on-prem and in a proxied environment. It will be much more helpful If you guys have any slack channel where I can ask our doubts.

Thank you so much for your previous response and helping me out @cfryanr

[cfryanr]

Hi @DevendraJohari24,

Glad you were able to get past the original error.

You can only use pinniped whoami with a cluster which has the Pinniped Concierge installed. However, kubectl now includes a very similar command called kubectl auth whoami, so if you are using a new enough version of Kubernetes then you can use that instead.

What are these fields discovery url, servingCertificateSecret , impersonationTLSCertificateSecret, impersonationCACertificateSecret, impersonationSignerSecret.

You do not need to change any of those values. They are the default names for resources that will be automatically created by Pinniped after installation.

We have a Slack channel on the Kubernetes Slack. You can sign up for free. Our channel is called #pinniped.