Conceder permisos¶

Un permiso da a una persona o a un bot un nivel en un cluster, sobre un namespace o sobre todo el cluster. Aquí ves cómo concederlo y revocarlo en «Permisos», y qué reglas aplica kubelatch.

Qué hace cada nivel y por qué existen estas reglas está en Niveles de permiso y Modelo de seguridad.

Antes de empezar¶

El sujeto existe y está habilitado (Usuarios y bots).
El cluster está registrado y no está en «Sin tokens» (Registrar un cluster).
Para developer, debugger o admin, el namespace tiene la etiqueta pod-security.kubernetes.io/enforce con baseline o restricted.

Conceder un permiso¶

Abre «Permisos».

Rellena el formulario:

Campo	Qué poner
«Sujeto»	La persona o el bot. Los deshabilitados no aparecen.
«Cluster»	Uno de los clusters con tokens.
«Nivel»	`viewer`, `developer`, `debugger`, `secrets-reader`, `admin` o `cluster-admin`. Debajo sale su descripción.
«Ámbito»	Un namespace del cluster (con su nivel PSA) o «todo el cluster (*)». Los namespaces protegidos no aparecen.
«Expira»	Opcional, salvo para `cluster-admin`. Vacío significa «nunca».
«Nota»	Opcional: el ticket o el motivo.

Pulsa «Conceder».

El formulario avisa antes de enviar si algo no cuadra, por ejemplo un namespace sin PSA. El servidor aplica las mismas reglas y responde 400 con el motivo.

Cada alta reconcilia el cluster al momento: en uno o dos segundos el binding existe y la persona puede usarlo. Si el cluster está en «Error», mira Solución de problemas.

Cada permiso se traduce en un grupo que el proxy impersona, por ejemplo kubelatch:ns:apps:viewer. Lo ves al pasar el ratón por el ámbito en la tabla.

Las reglas¶

Regla	Detalle
Namespaces protegidos	`kube-system`, `kube-public`, `kube-node-lease`, `kubelatch-system` y los de `KUBELATCH_PROTECTED_NAMESPACES` no admiten ningún permiso, de ningún nivel.
Ámbito `*`	Solo `viewer` y `cluster-admin`. `cluster-admin` solo se concede con `*`.
El namespace existe	Se comprueba en el cluster al conceder.
PSA	`developer`, `debugger` y `admin` exigen `pod-security.kubernetes.io/enforce=baseline` o `restricted` en el namespace.
`cluster-admin`	Caducidad obligatoria de 8 h como máximo. El botón «Dentro de 8 h» la rellena.
Caducidad	Si la pones, debe ser futura.

Para trabajar en un namespace protegido, usa el acceso nativo de administrador del cluster: Cuentas y recuperación.

El namespace es la frontera

Quien puede crear pods en un namespace alcanza todos sus Secrets y ServiceAccounts montándolos en un pod. developer no tiene secrets ni exec, pero llega a ellos igualmente. Concede developer, debugger y admin solo en namespaces cuyo contenido pueda ver y tocar esa persona, y no mezcles cargas de distintos equipos en un namespace.

Dos avisos más:

viewer en * ve nodos, PersistentVolumes, StorageClasses, CRDs y los logs de los pods de todos los namespaces. Los logs pueden contener secretos.
Con KUBELATCH_REQUIRE_PSA=false, la comprobación de PSA se desactiva y «Permisos» lo avisa en la cabecera. Úsalo solo si otra cosa (OPA, Kyverno) impone lo mismo: sin PSA, quien crea pods puede crear uno privilegiado y hacerse con el nodo.

Conceder acceso de emergencia con `cluster-admin`¶

cluster-admin es la vía preferida para una intervención urgente cuando kubelatch funciona. Queda auditado: el plano de control registra quién lo concedió y a quién, y cada petición hecha con él queda en la auditoría.

En «Permisos», elige el sujeto, el cluster y el nivel cluster-admin. El ámbito pasa a «todo el cluster (*)».
Pulsa «Dentro de 8 h», o pon una caducidad más corta.
Escribe en «Nota» el motivo y pulsa «Conceder».
Revócalo en cuanto termine la intervención.

Revocar un permiso¶

En «Permisos», busca el permiso con «Filtrar» (login, cluster, nivel, ámbito o nota).
Pulsa «Revocar» y confirma.

La revocación reconcilia el cluster: el binding y el grupo desaparecen en segundos. Las credenciales de la persona siguen valiendo para el resto de sus permisos. Si se queda sin ningún permiso en un cluster, el proxy responde 403 … no tiene permisos activos en el cluster.

Un permiso que caduca deja de contar en el proxy en ese mismo instante. Su binding lo retira la pasada periódica (cada 10 minutos) o un «Reconciliar» manual.

Para ver también los permisos revocados, marca «Incluir revocados». La columna «Estado» dice «Activo», «Expirado» o «Revocado el …».

Añadir CRDs a un nivel¶

Los niveles viewer, developer, debugger y secrets-reader son ClusterRoles agregados. Para que incluyan los recursos de un CRD, crea en el cluster un ClusterRole pequeño con la etiqueta kubelatch.io/aggregate-to-<nivel>: "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"]

Lo que agregas a viewer llega también a developer, que lo contiene. admin y cluster-admin son los roles de Kubernetes y siguen sus propias reglas de agregación.

Comprobar qué puede hacer alguien¶

kubelatch no admite kubectl --as: el proxy rechaza con 400 cualquier cabecera Impersonate-* del cliente. Para comprobar qué puede hacer un sujeto, usa el acceso nativo de administrador del cluster con su usuario y su grupo:

kubectl --kubeconfig <kubeconfig-admin-del-cluster> auth can-i create pods --subresource=exec -n apps \
  --as user:alice --as-group kubelatch:ns:apps:debugger

Los bots aparecen como bot:<nombre>. El grupo exacto de cada permiso sale en «Permisos» y en «Inicio» de la persona.