Passing custom redirect-uri

[dayakarr]

What happened?

I have configured Pinniped with an external OIDC provider with the following steps:

• Configured the external OIDC provider and created a client

• Created the JWT Authenticator with details like issuer, clientid and claims.

• Invoked Pinniped to get config pinniped get kubeconfig --oidc-scopes openid,email --oidc-client-id 0008d366-399c-1660-bc4c-00030a240000 > baremetal-externalidp.yaml

• Invoked the command kubectl get pods --kubeconfig baremetal-externalidp.yaml

This command has generated the HTTP link referring to the authorization code flow using an external OIDC provider.

When I referred to the HTTP link it has redirect-uri that got generated. Can we pass on this redirect-uri to the pinniped get kubeconfig command or through other means so that customized redirect-uri can be passed to the authorization code flow as defined in OIDC provider end?

The reason for this is that the external OIDC provider expects redirect-uri to be in https mode but Pinniped wants the hardcoded redirect-uri ( HTTP://127.0.0.1/callback).

Pinniped is generate

What did you expect to happen?

Please be specific and include proposed behavior!

What is the simplest way to reproduce this behavior?

In what environment did you see this bug?

• Pinniped server version: 0.30.0
• Pinniped client version: 0.30.0
• Pinniped container image (if using a public container image): ghcr.io/vmware-tanzu/pinniped/pinniped-server:v0.30.0
• Pinniped configuration (what IDP(s) are you using? what downstream credential minting mechanisms are you using?):
• Kubernetes version (use kubectl version): 1.28.10
• Kubernetes installer & version (e.g., kubeadm version):
• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release): CentOS Stream release 8
• Kernel (e.g. uname -a): Linux g7ac8cec4531 4.18.0-383.el8.x86_64
• Others:

What else is there to know about this bug?

[cfryanr]

Hi @dayakarr, thanks for submitting an issue.

That callback listener is running inside the Pinniped CLI on your local computer. It does not use HTTPS because then the CLI would need to have TLS certificates that your browser trusts, which would be difficult to configure for each separate CLI user. It does not need HTTPS for security because the redirect is handled by your browser and CLI both running on the same computer using only loopback networking, so there is little to no threat of MITM, network snooping, or other attacks happening. This is implementing the specification described in https://datatracker.ietf.org/doc/html/rfc8252#section-7.3.

Your OIDC provider should support this specification. Which provider are you using? Note that you might need to tell your provider that you are using a "native app" when you create the client in the OIDC provider.

Related but separate issue: Some OIDC providers do not allow port number wildcards when allowing a localhost redirect URI, although they should according to the spec. In that case, you can work around it by telling the Pinniped CLI on which port you would like it to listen, and then use that same port number in your allowed redirect URI when you create the client in your OIDC provider.

Have you considered using the Pinniped Supervisor? One Pinniped Supervisor can be used to provide authentication for many clusters and many users, so you only need to install it once and it only needs one client to be created in your OIDC provider. It will take care of this for you (it uses HTTPS for the callback endpoint), and will also give you lots of other great user experience and security features too.

[joshuatcasey]

I'm really curious what the OIDC IDP is - maybe it has some other way to specify a loopback redirect.

[dayakarr]

Thanks, @cfryanr and @joshuatcasey for your quick response.

I have tried using Pinniped Supervisor and went forward with the integration. Integration seems to be successful but runtime flow seems to be not working.

When I run the below commands, I get an error

• pinniped get kubeconfig --oidc-scopes openid,email --oidc-client-id 00065d39-cb6f-1666-981c-00020a2c0000 --oidc-listen-port 12345 > supervisor-sm.yaml

• "kubectl get pods -n test --kubeconfig supervisor-sm.yaml This command generated the OIDC authorization code URL and when I invoked this URL it redirected to the external OIDC provider for authentication. Then copied the authorization code from the browser and pasted in the terminal.

  Then pinniped performed back channel communication to token endpoint of external OIDC provider for user information.

Later, I see the below-mentioned error in the terminal Error: could not complete Concierge credential exchange: login failed: authentication failed Unable to connect to the server: getting credentials: exec: executable /usr/local/bin/pinniped failed with exit code 1

I see no error occurred from the external OIDC provider. Can you please guide me what is the reason for the failure?

[cfryanr]

Hi @dayakarr, when you are using the Pinniped Supervisor, you do not need to use of those arguments to pinniped get kubeconfig that you show above.

[cfryanr]

I'm going to close this for now because the original enhancement requested should not be needed, but please feel free to keep asking questions about using the Supervisor.