
This user token is not usable directly as authentication for kubernetes, so it then sends it to the Google authentication servers to obtain a one-hour valid access token for the kubernetes cluster. When running a command, when it needs an access token for the cluster it invokes KubiKey to get one.Īt this point, KubiKey first asks the user for a pin to unlock the yubikey, and then proceeds to sign a user token.

This service account is configured with the public key from the yubikey's authentication (slot 9a) key.įor our cluster, kubectl is configured to use KubiKey as its authentication provider. This was chosen as Google only allows external private key access for gcloud service accounts, enforcing standard google authentication for normal gcloud user accounts. KubiKey is built to provide access to gcloud service accounts. The yubikey's pin, when needed, can be fetched in-terminal during the kubectl command execution as needed, significantly reducing login flow friction for end users at the same time. It achieves this by utilizing a private key stored in a yubikey secure hardware token, and using this to generate kubernetes access tokens when running kubectl. KubiKey aims to solve this by providing shorter-lived access tokens for our main use case, kubernetes access, whilst at the same time reducing friction by integrating the login flow into the user experience of kubectl. Furthermore, the process of logging in the Google Cloud SDK, whilst not overly complicated, still requires a number of steps to be completed by the user, leading to friction when forced to log in often.

It is possible to manually log out the SDK after use, but as this is a user initiated process, it comes with the risk of a user forgetting to do this. This leads to risks of stolen credentials should a computer be lost whilst its Google Cloud SDK is still logged in. Unfortunately, the authentication process with the Google Cloud SDK leads to the creation of access tokens on the computers harddrive with very long lifetimes. When used as intended, this provides a relatively low-friction way to access the cluster. The default, Google supported way of accessing such a cluster from the command line is through logging in via the Google Cloud SDK, and letting it configure kubectl for you. We use the Google kubernetes engine as one of the tools for hosting products. Check out David’s first weeks at Tweede golf Kubikey was David's introductory project when he started with us.
