- Don't use ServiceAccount tokens outside of your cluster
- Create service accounts inside of your authentication identity provider, assign RBAC privileges
- Easy with Okta and OpenUnison
The Right Way To Authenticate to Your Clusters From Your CI/CD Pipelines
You have a shiny new cluster and new pipeline to automate the deployment of your applications! You're in DevOps heaven. Except. How are you talking to your API server? Are you using a ServiceAccount token? If your pipeline is running outside of your cluster, you shouldn't be. ServiceAccount tokens were not designed to be used from outside of your cluster, they're designed to provide an identity to the workloads running inside of your cluster. I've written about how you shouldn't use a ServiceAccount token for users, I've also written about how you shouldn't use certificates for authentication either. What's the correct way to access your cluster and why? The short answer is to use the same system your developers and admins use! Let's dive into the details as to why.
ServiceAccount Tokens - A Breach Waiting To Happen
A bit dramatic? Maybe, though being in security paranoia is part of the equation. That said, there's some very good reasons why you shouldn't be using a ServiceAccount token for accessing your cluster. First, let's create a token:
We now have a token we can use to access the cluster! Assuming we provide some RBAC bindings to this ServiceAccount all I need to do is embed the token in the Authorization header of each request to the API server or embed it into a kubectl configuration file for use with any of the Kubernetes client SDKs out there. That's because this token is known as a "Bearer token", as in the bearer of the token can do whatever the token is authorized to do. It's much like a ticket to your favorite sporting event or show. There's nothing tying the ticket to you, anyone who has it can use it. If you drop your ticket and someone else uses it, you're out of luck. This is in contrast to certificate authentication where the secret part, the private key, never leaves the client. The fact that bearer tokens travel across the wire means that every system that comes in contact with them is a potential breach. Accidentally log your tokens? Now your backup solution is a potential breach. Your CNI has a vulnerability? That's now a potential breach. Your cluster is many layers of virtual networks, proxies, logs, and that's even before you get to your pipeline! The question isn't if these layers will have bugs that can leak your tokens, it's when.
To mitigate this risk, bearer tokens should be short lived. Our deployments of OpenUnison deploy tokens with one minute life spans with the hope that should a token get leaked, by the time an attacker gets the token, recognizes it, and tries to use it it's already expired. Here's a typical token generated by OpenUnison for your cluster:
This token, like the ServiceAccount token we generated earlier, is a JSON Web Token, or JWT. A JWT is a bit of digitally signed JSON that can be verified with the correct public key. This lets the API server, or anyone else, verify and trust the attributes in the JSON. My favorite tool for inspecting tokens is jwt.io. Dropping this token in shows the following "claims":
A "claim" in the JSON is something that the JWT is asserting. As in, this JSON is claiming I'm mmosley. The important claims are iat (initiated at), nbf (not before), exp (expires). All three of these claims are expressed as seconds since January 1, 1970 GMT. In this case, the token was initialized at Tuesday, January 26, 2021 1:14:24 AM UTC and expires at Tuesday, January 26, 2021 1:15:24 AM UTC one minute later. This means an attacker would need to get this token, recognize what it is, and exploit it within sixty seconds. That's a tall order.
Now lets drop our ServiceAccount token into jwt.io:
There's no iat, nbf, or exp claims! This token will NEVER expire. The only way to get Kubernetes to reject this token is to delete the Secret associated with the ServiceAccount, and if you're using Kubernetes' new oidc endpoint to get certificates for ServiceAccount verification you can get into real trouble! But that's another blog. The point here is that unless you have some very specific controls in place to constantly rotate your ServiceAccount tokens you're exposing your cluster to a potential break from multiple layers. Every system has bugs and you won't generally have control of that. You want to minimize the amount of time a token is useful. Want some more evidence of how scary ServiceAccount tokens can be? Take a look at darkbit.io's blog post on HoneyTokens.
This issue is one of the reasons why the TokenRequest API was created. The long term vision is to eliminate ServiceAccount token Secrets altogether in favor of short lived tokens that are generated as needed for specific workloads. Instead of a Secret being mounted into your Pod, each Pod will get a token mounted that has an exp claim that will tell Kubernetes how long to accept the token and the token won't be stored in Etcd. This api is still in beta and few applications know how to use these short lived tokens. The good news is OpenUnison will support them naively in our next release!
Authentication The Right Way
The short answer is use the same method as your developers and admins! Hopefully you're using OpenUnison, but that doesn't mean it's the only way to do this. Let's assume you are, and your users and groups are stored in Okta. If your pipelines get an oidc token from OpenUnison the same way your developers and admins do the "secret" for authentication can't be leaked by your cluster because your cluster will never see it, drastically cutting down on your attack surface. You still need to secure your CI/CD infrastructure, but that's another blog.
The goal for your pipeline is often to generate a kubectl configuration file that can be leveraged by the python, go, or some other SDK. Once you're generated that file the SDK does the rest of the work. The good news is OpenUnison does this for you already! If you login to your OpenUnison and click on the "Kubernetes Token" badge:
You'll see a screen much like this:
Depending on your browser, hit F12 for the developer tools and you'll see that your browser is just making a RESTful web services call to get your kubectl command:
You work with APIs all the time! So how to call this API from your pipeline? That really depends on how you store your users. The inspiration for this blog post was a customer using Okta, so we'll use that as an example. The basic steps are:
- Initialize your request by openning a connection to https://openunison.host.domain/k8stoken/token/user
- Follow the redirects to your provider's login page
- Submit a login
- Follow the redirects back to https://openunison.host.domain/k8stoken/token/user
- Extract the "kubectl Command" from the final JSON and run, giving you a kubectl configuration!
Step 3 is really the hardest part and very dependent on your identity provider. Some make this easier then others. Okta's was really easy! Here's the code we wrote to do it:
First we initialize a session with Python's Requests library to track cookies. Next we start the process by accessing the token url. Once the redirects are finished, Okta has an API it uses to authenticate the user's credentials and then redirect you back to your original request. Finally, OpenUnison validates your session and generates a kubectl command for you, including everything you need such as certificates, URLs, etc. To see the code used:
The first thing we do is get a kubectl configuration command from OpenUnison using our Okta domain information and our service account username and password. We next get the kubectl configuration command and run it, generating a ready to go configuration file. Finally, we initialize our Python SDK using the configuration file. The great thing about this is that if your process takes more then a minute, the Python SDK will refresh your token for you! You can have your cake and eat it too. Use a service account for accessing your cluster without exposing it to the risks of a never expiring bearer token! The complete code snippet is available as a gist.
At this point you might ask "why not just use a standard API?". Because there isn't one. Each authentication system is different and can involve any number of different steps. The good news is most authentication pages these days are like Okta, where it's just a simple matter of inspecting their API in a browser.
In addition to the direct security benefits of not exposing never-expiring-bearer-tokens from your cluster, this mechanism makes it easier to use RBAC. Instead of directly referencing a ServiceAccount object in the bindings, you can reference groups instead and add your pipeline service accounts to those groups. Just like with your developers and admins groups can be used to more easily audit your service account access.
If you want to start simplifying your cluster access, take a look at the multiple editions we have of the Orchestra Login Portal, including OIDC, SAML2, LDAP, and GitHub! If you want to learn more about the details of Kubernetes authentication and authorization you may be interested in the book I co-authored: Kubernetes and Docker: The Enterprise Guide!