Grant permissions¶
A permission gives a person or a bot a tier on a cluster, over a namespace or over the whole cluster. Here's how to grant and revoke one in Permisos (Permissions), and what rules kubelatch applies.
What each tier does and why these rules exist is in Permission tiers and Security model.
Before you start¶
- The subject exists and is enabled (Users and bots).
- The cluster is registered and isn't in Sin tokens (No tokens) (Register a cluster).
- For
developer,debuggeroradmin, the namespace has thepod-security.kubernetes.io/enforcelabel set tobaselineorrestricted.
Grant a permission¶
- Open Permisos.
-
Fill in the form:
Field What to put Sujeto (Subject) The person or the bot. Disabled ones don't show up. Cluster One of the clusters with tokens. Nivel (Tier) viewer,developer,debugger,secrets-reader,adminorcluster-admin. Its description shows below.Ámbito (Scope) A namespace in the cluster (with its PSA level) or todo el cluster (*)(the whole cluster (*)). Protected namespaces don't show up.Expira (Expires) Optional, except for cluster-admin. Empty means "never".Nota (Note) Optional: the ticket or the reason. -
Click Conceder (Grant).
The form warns before submitting if something doesn't add up, for example a namespace without PSA. The server applies the same rules and responds 400 with the reason.
Each grant reconciles the cluster right away: within a second or two the binding exists and the person can use it. If the cluster is in Error, see Troubleshooting.
Each permission translates into a group the proxy impersonates, for example kubelatch:ns:apps:viewer. You can see it by hovering over the scope in the table.
The rules¶
| Rule | Detail |
|---|---|
| Protected namespaces | kube-system, kube-public, kube-node-lease, kubelatch-system and the ones in KUBELATCH_PROTECTED_NAMESPACES accept no permission, at any tier. |
Scope * |
Only viewer and cluster-admin. cluster-admin is only ever granted with *. |
| The namespace exists | Checked on the cluster when granting. |
| PSA | developer, debugger and admin require pod-security.kubernetes.io/enforce=baseline or restricted on the namespace. |
cluster-admin |
A mandatory expiry of 8 h at most. The Dentro de 8 h (In 8 hours) button fills it in. |
| Expiry | If you set one, it must be in the future. |
To work in a protected namespace, use the cluster's native administrator access: Accounts and recovery.
The namespace is the boundary
Anyone who can create pods in a namespace reaches all its Secrets and ServiceAccounts by mounting them into a pod. developer doesn't have secrets or exec, but it reaches them anyway. Grant developer, debugger and admin only on namespaces whose contents that person may see and touch, and don't mix different teams' workloads in one namespace.
Two more warnings:
vieweron*sees nodes, PersistentVolumes, StorageClasses, CRDs and the pod logs of every namespace. Logs can contain secrets.- With
KUBELATCH_REQUIRE_PSA=false, the PSA check is turned off and Permisos warns about it in the header. Only use this if something else (OPA, Kyverno) enforces the same thing: without PSA, anyone who can create pods can create a privileged one and take over the node.
Grant emergency access with cluster-admin¶
cluster-admin is the preferred route for an urgent intervention while kubelatch is working. It's audited: the control plane logs who granted it and to whom, and every request made with it is logged.
- In Permisos, choose the subject, the cluster and the
cluster-admintier. The scope switches totodo el cluster (*). - Click Dentro de 8 h, or set a shorter expiry.
- Write the reason in Nota and click Conceder.
- Revoke it as soon as the intervention is done.
Revoke a permission¶
- In Permisos, find the permission with Filtrar (Filter) (login, cluster, tier, scope or note).
- Click Revocar (Revoke) and confirm.
Revoking reconciles the cluster: the binding and the group disappear within seconds. The person's credentials still work for the rest of their permissions. If they're left with no permission on a cluster, the proxy responds 403 … no tiene permisos activos en el cluster (403 … has no active permissions on the cluster).
A permission that expires stops counting on the proxy at that exact instant. Its binding is removed by the periodic pass (every 10 minutes) or a manual Reconciliar (Reconcile).
To also see revoked permissions, check Incluir revocados (Include revoked). The Estado (Status) column says Activo (Active), Expirado (Expired) or Revocado el … (Revoked on …).
Add CRDs to a tier¶
The viewer, developer, debugger and secrets-reader tiers are aggregated ClusterRoles. To have them include a CRD's resources, create a small ClusterRole on the cluster with the label kubelatch.io/aggregate-to-<tier>: "true":
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: certificates-viewer
labels:
kubelatch.io/aggregate-to-viewer: "true"
rules:
- apiGroups: ["cert-manager.io"]
resources: ["certificates", "issuers"]
verbs: ["get", "list", "watch"]
Anything you add to viewer also reaches developer, which contains it. admin and cluster-admin are Kubernetes' own roles and follow their own aggregation rules.
Check what someone can do¶
kubelatch doesn't support kubectl --as: the proxy rejects any Impersonate-* header from the client with a 400. To check what a subject can do, use the cluster's native administrator access with its user and group:
kubectl --kubeconfig <cluster-admin-kubeconfig> auth can-i create pods --subresource=exec -n apps \
--as user:alice --as-group kubelatch:ns:apps:debugger
Bots show up as bot:<name>. Each permission's exact group appears in Permisos and on the person's Inicio (Home).