EN ES

kubelatch.com

blog

Sign in to kubelatch with your company account

· 5 min read

As of 0.45, people sign in to kubelatch with their company account: Google Workspace, Entra ID, Okta, Keycloak or another OpenID Connect provider that publishes its discovery document. That SSO already tells you who gets into your clusters; kubelatch adds the rest: how long each permission lasts, what it allows and a record of every request. Here’s what changes when you turn it on, and what stays out, such as offboarding, which is still on you.

Your cluster already knows who signs in

If your clusters run on EKS, AKS or GKE, people may well sign in to them with their company account already: IAM Identity Center or an OIDC provider on EKS, Entra ID on AKS, Google on GKE. Your bindings already grant permissions to users and groups that come from there, so who gets in is solved.

But that SSO only knows who you are. A binding to the platform-admins group grants cluster-admin today, next month and next year to whoever is still in the group. With three clouds, audit logs sit in three places, each in its own format. And the AI agent working in your terminal gets in with your kubeconfig and can do everything you can.

That’s where kubelatch comes in. A permission lasts 30 days unless you pick another date in the web UI; you can also pick Never, except for cluster-admin, which can’t last past 8 hours. Every credential has an owner and expires: by default, 30 days at most for a person, 90 for a bot and one hour for a CI job. And every request that goes through kubelatch leaves one readable row, the same on every cloud.

Until now, signing in to kubelatch meant GitHub or a local password. As of 0.45 you can sign in with the same provider as the cluster, as long as it supports OpenID Connect. Google, Entra ID, Okta and Keycloak do. IAM Identity Center’s own directory doesn’t: it offers SAML to applications, and SAML is under “On request” on the roadmap. If Okta, Entra ID or Google sits behind your Identity Center, kubelatch registers with that one.

One more application in your provider

kubelatch doesn’t replace your cluster’s SSO, and it doesn’t put a second one on top. It registers with your provider as one more application, like Argo CD or Grafana, and people sign in with the session they already have open in the browser. Once it’s on:

  • The login screen shows Sign in with and the name you set in displayName (Sign in with SSO if you set none). If GitHub login is on too, both buttons show.
  • Every existing account links itself the first time its owner signs in, when it has the same e-mail address and the provider vouches for it. An account with no address needs one first, or a linking link. The kubelatch login doesn’t change: clusters still see user:ana and nobody loses a permission.
  • kubelatch login still opens the browser, and only goes through the provider when it has to.
  • Passwords stop working, except for break-glass accounts.

On Kubernetes, the client ID and secret go in a Secret, and the rest in the chart’s config.oidc. The chart refuses an issuer without allowedDomains, the e-mail domains allowed in, and the other way round. If your provider uses a private CA, the chart’s new extraEnv lets you point SSL_CERT_FILE at it. The OIDC login guide has the steps for Google Workspace, Entra ID, Okta, Keycloak, Authentik and Auth0.

By default, a first sign-in links any enabled account with the same address, which is what lets you turn passwords off without sending everyone a link. If people in your directory can change their own address, set autolink: off in config.oidc, and each account links through a link you send. The guide explains when invited is enough: it links only accounts that never signed in or hold a pending invitation.

A break-glass account first

Turn OIDC on without a break-glass account and, if anything fails (the provider, its configuration or your administrator’s link), no administrator gets in until you flag one from the server’s CLI. So do it first. Replace admin with your administrator’s login; $MGMT_KUBECONFIG is the kubeconfig of the cluster kubelatch runs on:

kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch exec -it deploy/kubelatch -- /kubelatch-server user set-break-glass admin

That account is also your way in when the provider is down or its configuration breaks: kubelatch checks its password without asking the provider, and the server’s CLI doesn’t need it either. The catch is that it has no second factor, so keep these accounts few, with long passwords in your secret manager.

What this does not solve

  • No automatic sign-up. Someone whose address matches no account is turned away, and the login screen says who to ask, from config.accessContact. Accounts are still created in Users; getting in without waiting for an invitation is in phase 1 of the roadmap.
  • No automatic offboarding. The provider gives kubelatch no member list. When someone leaves, Disable their account: it closes their sessions and revokes their credentials at once. Until you do, what they hold keeps working until it expires, even after the provider has closed their account: 12 hours for the web session, 12 hours by default for the CLI session and up to 30 days by default for each credential.
  • Two-factor is your provider’s job. kubelatch records how each person authenticated, when the provider says, but requires nothing.
  • Identity inside the cluster stays separate. The bindings your cluster gives the provider’s groups are the cluster’s business, and what comes in through them doesn’t go through kubelatch. When Ana comes in through kubelatch, the cluster sees user:ana, not her address. In phase 1, a kubelatch permission will be able to put someone in a group your cluster already uses for as long as it lasts, so the RBAC you already have applies.
  • kubelatch is in public preview. Some pieces are still missing (they’re on the roadmap), only the latest release is supported, and there’s no stability commitment between versions yet.

Try it

If you already run kubelatch, follow OIDC login: the break-glass account first, then the application in your provider, and last a helm upgrade to 0.45 with the Secret and config.oidc together. With Google, expect a new redirect URI to take from five minutes to a few hours to start working. It works the same in Free and Pro, and linking creates no account, so it never counts toward Free’s five people.

If you don’t have it yet, the local tutorial sets it up on your machine with a throwaway kind cluster in about fifteen minutes, plus the first downloads. The tutorial uses local passwords; you add OIDC login afterwards with the guide.

kubelatch is developed at Picaporte Labs, in Spain. If anything doesn’t match what you see, write to me at hola@picaportelabs.com or hello@kubelatch.com.