Skip to content

Authenticate to Kubernetes with OIDC on K3s

This recipe describes how to configure K3s for OIDC authentication against an authentik instance.

For details on why you'd want to do this, see the Kubernetes Authentication Guide.

Requirements

Ingredients

Setup authentik for kube-apiserver

Start by logging into your authentik instance with a superuser account.

Create provider

Navigate to Applications -> Providers, and Create a new OAuth2/OpenID Provider.

Give your provider a name (I use kube-apiserver), and set the following:

  • Authentication flow: default-authentication-flow (Welcome to authentik!)
  • Authorization flow: default-provider-authorization-implicit-consent (Authorize Application)
  • Client type: Confidential

Scroll down, and set:

  • Client ID: kube-apiserver take note, this is non-default
  • Client Secret: <pick a secret, or use the randomly generated one>
  • Redirect URIs/Origins (RegEx): http://localhost:18000 1

Finally, enable Include claims in id_token, instructing authentik to send the user claims back with the id token:

..and click Finish. On the following summary page, under OAuth2 Provider, take note of the OpenID Configuration URL (/application/o/kube-apiserver/.well-known/openid-configuration if you followed my conventions above) - you'll need this when configuring Kubernetes.

What's that redirect URI for?

We'll use kubelogin to confirm OIDC login is working, which runs locally on port 18000 to provide a web-based OIDC login flow.

Create application

authentik requires a one-to-one relationship between applications and providers, so navigate to Applications -> Applications, and create an application for your new provider.

You can name it anything you want (but it might be more sensible to name it for your provider, rather than a superhero! 🦸)

Create group

Remember how we setup a groups property-mapper when deploying authentik? When kube-apiserver requests the groups scope from Authentik, the mapper will return all a user's group names.

You can create whatever groups you prefer - later on, you'll configure clusterrolebindings to provide RBAC access to group members. I'd start with a group called admin-kube-apiserver, which we'll simply map to the cluster-admin clusterrole.

Navigate to Directory -> Groups, create the necessary groups, and make yourself a member.

Summary

What have we achieved? We've configured authentik as an OIDC provider, and we've got the details necessary to configure our Kubernetes platform(s) to authenticate against it!

Summary

Created:

  • authentik configured as an OIDC provider for kube-apiserver
  • OIDC parameters, including:
    • OIDC Client id (kube-apiserver)
    • OIDC Client secret (<your chosen secret>)
    • OIDC Configuration URL (https://<your-authentic-hosts>/application/o/kube-apiserver/.well-known/openid-configuration)

What's next?

Return to the Kubernetes Authentication Guide for instructions re configuring your particular Kubernetes platform!

Chef's notes 📓

  1. Later on, as we add more applications which need kube-apiserver authentication, we'll add more redirect URIs. ↩

Tip your waiter (sponsor) 👏

Did you receive excellent service? Want to compliment the chef? (..and support development of current and future recipes!) Sponsor me on Github / Ko-Fi / Patreon, or see the contribute page for more (free or paid) ways to say thank you! 👏

Employ your chef (engage) 🤝

Is this too much of a geeky PITA? Do you just want results, stat? I do this for a living - I'm a full-time Kubernetes contractor, providing consulting and engineering expertise to businesses needing short-term, short-notice support in the cloud-native space, including AWS/Azure/GKE, Kubernetes, CI/CD and automation.

Learn more about working with me here.

Flirt with waiter (subscribe) 💌

Want to know now when this recipe gets updated, or when future recipes are added? Subscribe to the RSS feed, or leave your email address below, and we'll keep you updated.

Your comments? 💬