This plugin to kubectl helps to setup OpenId Connect authentication for clients to connect to a kubernetes cluster.

In order for this to work for me authenticating against a cluster, the administrator have to hand me oidc-issuer-url, oidc-client-id and oidc-client-secret so that the tool can do its job authenticating me with OpenId Connect.

The administrator also will have to hand out the same data to all other users of the cluster.

If this secret is leaked, what's worst the attacker can do? If I understand this correctly, they should not be able to access the cluster, as the secret will only allow them to supply their own identity that normally would not have any permissions. Anything else?

1 Answer 1


Let's assume that I have the client secret of an application legit.app.org, and I can create a malicious application bad.app.org, with the issuer being oidc.app.org.

If I can convince a user to connect to bad.app.org using oidc.app.org I will be able to receive the tokens for this user associated with the legit.app.org credential. So If I use those tokens to connect to legit.app.org I will be able to impersonate the user.

Thankfully, there's a second layer of protection which is that the legit.app.org will have to register valid redirect_uris. Requests usign legit.app.org client_id/client_secret will have to use one of those registered redirect_uri, and the auth server is supposed to do an exact match. So with bad.app.org I'll also have to somehow "control" a redirect_uri considered as valid for the client_id/client_secret of legit.app.org to be able to intercept valid tokens.

Note that most of the auth services allow to either revoke client_secret and get a new one. Last but not least, if somehow you need to include a client_secret in an unsafe app like a SPA or mobile app, the solution is to use PKCE instead of regular client_secret.

PS: forgot to add that if you use HS256 instead of RS256 to sign the token id, it's the client secret which is used to sign the id token. See https://openid.net/specs/openid-connect-core-1_0.html#Signing. So basically you can emit falsely signed id tokens and if the client accept symmetric signed keys with no iss check, you can impersonate anybody. Obviously that's why you shouldn't use JWT authentication with symmetric algorithm

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .