01-auth0.md

Auth0

This page shows how to configure an Auth0 client for use with Kubernetes. You need an existing auth0 account, which you can get for free using Auth0's "development" pricing tier. You also need a user or two, which you can either add manually into Auth0 using a "Database" connection, or (much cooler) use one of their gazillion integrations. I have enable the "Google" integration in mine, which allows me to log in with my gmail account.

We'll use Auth0 groups to control access into our cluster. In an "enterprise" context these groups will likely come thru an ADFS integration or similar, but we'll simply add a group manually.

If you're using an integration, hit the "try" icon to test login, as this will create the auth0 user so that we can add groups to it:

After that's done, you should have (at least) one user in Auth0's "users" view:

Click your user and scroll down to the "metadata" field. This is where we'll add a group we can use for Kubernetes RBAC:

Add the following to app_metadata (remember to hit Save afterwards):

{
  "authorization": {
    "groups": [
      "KubernetesAdmins"
    ],
    "roles": [],
    "permissions": []
  }
}

We also need to set up a rule. This will be a super-simple rule that will expose the groups list to a "top-level" claim, which makes it easy for us to configure group-level access on Kubernetes' apiserver.

Still in auth0 to to "Rules", Select "Create Rule" and start with an empty one.

Paste in this code to the rule and call it "Kubernetes-Group-Claims" or something with similar sazz:

function (user, context, callback) {
  //console.log(user.authorization.groups);
  context.idToken.groups = user.authorization.groups;

  callback(null, user, context);
}

Now it's time to create an Auth0 Client which will represent Kubernetes. Go to "Clients", "Create Client", call it "Kubernetes" for instance, and give it the type "Regular Web Applications".

There are a couple of the items we'll need to fill in after we've provisioned Kubernetes, but take note of the following from the "Settings" view:

• Domain
• Client ID
• Client Secret

Under "Allowed Callback URLs", for now go ahead and add the following: https://openidconnect.net/callback

Under advanced settings -> OAuth, make sure your settings are as follows:

JWT Signature Altorithm: RS256
OIDC Conformant: Off

(Kubernetes only supports RS256, so it's super-important to get that configured.)

We can now test that we got everything right by using the OpenID Connect debugger. Browse to https://openidconnect.net/. Click the "Configuration" link, and fill in your domain from you Auth0 client settings, then click "use auth discovery document". Also fill in the client ID and Client secret. Mine looks like this: Hit "save" and then "Start". You should be prompted with a login box. Follow the "wizard" (basically hit "exchange", "next" and "verify" until you end up at the bottom of the page with a fully parsed jwt token). Mine looks like this:

From the metadata you can tell than I'm a dude, and that I'm a Kubernetes Admin. This proves that the rule we set up did its job, and exposes the "groups" object as a "top-level-thing" in the decoded jwt token data.

This is all we need for now as far as Auth0 goes. We'll head back here after we've gotten our Kubernetes cluster up and running, so head onwards to step 2!