Enable Headlamp to use Public OIDC Client

[ErikThorsell]

Current implementation enforces a oidc client secret

As part of our user authentication strategy, we want to setup a public Dex static Client and use this client with Headlamp.

However, as Headlamp is currently implemented, not providing an oidcClientSecret will result in a failed login attempt:

if oidcClientID != "" && oidcClientSecret != "" && oidcIssuerURL != "" && oidcScopes != "" {
	oidcConf = &OidcConfig{
		ClientID:     oidcClientID,
		ClientSecret: oidcClientSecret,
		IdpIssuerURL: oidcIssuerURL,
		Scopes:       strings.Split(oidcScopes, ","),
	}
}

headlamp/backend/pkg/kubeconfig/kubeconfig.go

Line 871 in 4598276

func GetInClusterContext(oidcIssuerURL string,

Describe the solution you'd like

My proposal is to add a configuration option, which can be provided during the startup of Headlamp, allowing the use of an OIDC Client without a secret.

What users will benefit from this feature?

Everyone who wants to use public clients in Dex together with Headlamp.

Are you able to implement this feature?

I think so. We have already started discussing this here: https://kubernetes.slack.com/archives/C01FXB5E8ER/p1744348416232779
and I will reach out in the thread for more advice.

[BenasB]

I'm using Keycloak with a public client (where you don't get a secret). I pass in a random value to clientSecret, such as none and it seems to work fine. Not entirely sure if that's applicable to other idPs such as Dex, but worth a shot!

[ErikThorsell]

I'm using Keycloak with a public client (where you don't get a secret). I pass in a random value to clientSecret, such as none and it seems to work fine. Not entirely sure if that's applicable to other idPs such as Dex, but worth a shot!

Thanks for the input. This was actually brought up in the Slack thread I referenced, but it does not work for Dex.

[J4nsen]

Hi, we use Authelia, and using a random secret does not work either. Support for public clients would be greatly appreciated.

[thatMacAdmin]

I use Authentik and using a random secret does not work either. I would also like to see support for this standard OIDC flow.

[BinaryMan32]

I'm new to OIDC so I'm not really sure of the security impact, so I'm curious what others think.

Suppose that I want to use OIDC both directly with kubectl and also with headlamp. Both headlamp and kubectl need to use the same client ID set in the kubernetes api server arg --oidc-client-id. This means the IDP (identity provider) must have the same settings for both headlamp and kubectl, since it has no way to distinguish them. Because headlamp doesn't support public clients/PKCE, a client secret is required. However, anyone using kubectl with OIDC also needs the secret. That means we should assume the secret is public knowledge.

One approach I've found would be to configure kubernetes OIDC using structured authentication configuration in order to configure multiple audiences or client IDs. There's also a kubernetes blog post with details on Migration from command line arguments to configuration file.

Based on the info above, I think it's possible to allow multiple client ids with a structure similar to:

jwt:
- issuer:
    url: https://issuer1.example.com
    audiences:
    - kubectl
    - headlamp
    audienceMatchPolicy: MatchAny
    ...

Then, each client can have different settings in the IDP:

• headlamp - use a client secret which is shared only between the IDP and headlamp
• kubectl - use a public client with PKCE

This structured authentication config feature is in beta and enabled by default as of kubernetes 1.30. I haven't tried it yet, but it looks promising.

[BinaryMan32]

The above workaround to use separate clients for headlamp and kubectl is working for me. I'm using kubernetes 1.33.1 via k3s, authelia 4.39.4 (chart 0.10.17), and headlamp 0.31.1. If headlamp supported public clients I could simplify my configuration, but I'm now able to use headlamp with a client secret and kubectl with a public client.

[ErikThorsell]

A couple of updates here:

Are you able to implement this feature?
I think so. We have already started discussing this here: https://kubernetes.slack.com/archives/C01FXB5E8ER/p1744348416232779
and I will reach out in the thread for more advice.

This now seems unlikely. I'd gladly see that someone else gave this a try.

@BinaryMan32 wrote:

One approach I've found would be to configure kubernetes OIDC using structured authentication configuration in order to configure multiple audiences or client IDs. There's also a kubernetes blog post with details on Migration from command line arguments to configuration file.

And even though this is technically a workaround that could be used, I still think the issue at hand is something Headlamp should address. Your comment as a whole is a perfect description of the problem though.

[illume]

Hi @ErikThorsell @BinaryMan32 @J4nsen @thatMacAdmin

There is a PR by @k-airos to add support for this...

• backend: headlamp: Add pkce support #3692

What do you think?

[ErikThorsell]

Hi @ErikThorsell @BinaryMan32 @J4nsen @thatMacAdmin

There is a PR by @k-airos to add support for this...

• backend: headlamp: Add pkce support #3692

What do you think?

Sorry for the late response, been on vacation.

I must admit that I'm not 100% following the PR. Or, rather, it does not implement the "fix" in the way I envisioned it. It is likely that this is a better way though, so if it solves the problem and is considered a good fix by others -- I'm all game.