kubelatch¶

kubelatch gives every person and every CI pipeline their own credential for your Kubernetes clusters, with tiered permissions. It always knows who has access to what and until when, and it logs every request to the API server.

Without kubelatch, the usual setup is a shared admin kubeconfig or a hand-created ServiceAccount per person: nobody knows who uses it or when it expires. With kubelatch, every credential has an owner, an expiry date and a usage log, and it can be revoked instantly.

flowchart LR
    u["People and CI<br/>kubectl, k9s, Helm"] -->|"own credential"| kl["kubelatch<br/>proxy and audit"]
    adm["Administrators"] -->|"permissions"| kl
    kl -->|"acts as that person"| k8s["Your clusters<br/>EKS · GKE · AKS · k3s…"]
    kl --> pg[("Postgres<br/>inventory and audit")]

What you get¶

• A credential of your own, per person or pipeline. A klt_… token with its kubeconfig, with an expiry, that can be revoked instantly. GitHub Actions workflows get their own without storing any secret in GitHub.
• Tiered permissions. Six fixed tiers (viewer, developer, debugger, secrets-reader, admin and cluster-admin) over a namespace or a whole cluster. kubelatch maintains the cluster's RBAC for you.
• Inventory. Who each credential belongs to, until when it's valid, and when it was last used.
• Per-request audit. Every request to the API server is logged with who, what, where and the result, including exec and port-forward.
• Any cluster. Works the same on managed clusters (EKS, GKE, AKS) and self-managed ones (kubeadm, k3s, RKE2, Talos): it only uses the standard Kubernetes API.

Where to start¶