Glosario¶
Los términos que usa esta documentación, en orden alfabético, con un enlace a donde se explican.
| Término | Qué es |
|---|---|
| Acceso privilegiado | Lo que tiene un grupo o un usuario cuando el RBAC del cluster le da una capacidad que puede llevar a cluster-admin, como ejecutar cargas de trabajo o leer Secrets en un namespace privilegiado. Todo permiso que lo da necesita una caducidad de 8 h como máximo. Ver Qué cuenta como privilegiado. |
| Administrador (rol) | Persona con el rol de administrador en kubelatch: gestiona clusters, permisos, cuentas y reglas de confianza. No confundir con el rol de sistema admin, ni con los roles que concede un permiso. Ver Usuarios y bots. |
| Agente de IA | Un cliente MCP, como Claude Code o Cursor, que trabaja en los clusters a través del servidor MCP de kubelatch, como bot o en nombre de una persona. Ver Agentes de IA. |
| Ámbito | Dónde vale un permiso: un namespace o * (todo el cluster). Ver Roles de sistema. |
| Audit-ID | Identificador único (UUIDv7) que kubelatch pone a cada petición del proxy. Va en la respuesta, en la fila de auditoría y en la petición al cluster, que lo usa como su auditID. Ver El viaje de una petición. |
| Auditoría | Los dos registros de kubelatch: audit_events (una fila por petición al proxy) y control_events (acciones del plano de control e intentos de login). Ver Modelo de seguridad. |
| Auditoría nativa | El registro de auditoría del propio cluster o de su proveedor cloud. Segunda fuente, correlacionada por Audit-ID. Ver Modelo de seguridad. |
| Bootstrap | Manifiesto que kubelatch genera para cada cluster: crea el namespace kubelatch-system, las ServiceAccounts del proxy y del reconciliador, y la jaula del reconciliador. Ver Registrar un cluster. |
| Bot | Sujeto para automatizaciones: sin contraseña ni sesión, solo credenciales. En el cluster aparece como bot:<nombre>. Ver Usuarios y bots. |
| Canje de CI | Canje del token OIDC de un job de GitHub Actions por una credencial de bot de corta duración, en /v1/ci/github-actions/token. Ver Credenciales para GitHub Actions. |
| Capacidad | Conjunto de reglas con nombre del catálogo de kubelatch (workloads.read, pods.exec…) que activa un rol personalizado. Ver Roles. |
| Cluster | Un cluster de Kubernetes registrado en kubelatch, con un id (slug) que forma parte de la URL del proxy: /clusters/<id>. Ver Registrar un cluster. |
| Cluster de gestión | El cluster donde se ejecuta kubelatch. Puede ser uno de los que gestiona. Ver Instalar. |
| Credencial | Un token klt_…, normalmente con el kubeconfig que lo usa. Tiene dueño, caducidad, último uso y se puede revocar. Ver Obtener una credencial. |
| Cuenta break-glass | Cuenta que puede entrar con contraseña aunque el login con GitHub u OIDC esté activo. Solo se marca desde la CLI del servidor (kubelatch-server user set-break-glass) y no tiene doble factor. Ver Identidad. |
| Deshabilitar | Cortar el acceso de un sujeto: cierra sesiones, revoca credenciales y lo saca de los clusters. Conserva sus permisos por si se rehabilita. Ver Identidad. |
| Enlace de enrolamiento | Enlace de un solo uso (<base>/api/enroll/kle_…, 1 h) dentro del comando de enrolamiento que un admin genera en la página del cluster, donde también puede invalidarlo. El comando aplica el bootstrap y envía los tokens a kubelatch; el enlace es la única credencial. Ver Registrar un cluster. |
| Enlace de invitación | Enlace de un solo uso (<base>/account-link#kli_…, 72 h) con el que una persona nueva fija su contraseña, o vincula GitHub o el proveedor OIDC. Ver Identidad. |
| Enlace de vinculación | Enlace de un solo uso (24 h) que genera un admin, desde la ficha de la cuenta, para vincular una cuenta existente con GitHub o con el proveedor OIDC. Sin login externo, o en una cuenta break-glass, la misma opción del menú se llama «Restablecer acceso» y da un enlace de restablecimiento, que fija una contraseña nueva. Ver Identidad. |
| Enrolar | Ejecutar el comando de enrolamiento de un cluster, una vez registrado. «Registrar un cluster» solo crea su ficha, con el estado «Sin enrolar»; enrolar aplica el bootstrap y envía a kubelatch los tokens, y el cluster pasa a «Listo». Ver Registrar un cluster. |
| Entorno | Un nombre que un administrador da a unos clusters, como prod o staging, con la marca de producción si la necesita. Un cluster está en uno como mucho. Agrupa y filtra los clusters, y sus reglas, en Pro, limitan lo que duran en ellos los permisos de las personas. Ver Entornos y etiquetas. |
| Etiqueta (de un cluster) | Un par clave: valor de un cluster en kubelatch, como equipo: pagos, con un solo valor por clave y hasta 20 por cluster. Agrupa y filtra los clusters, y un permiso sobre un conjunto puede seguirla. No hay que confundirla con las etiquetas de un objeto de Kubernetes. Ver Entornos y etiquetas. |
| GitHub App | La aplicación de tu organización de GitHub con la que las personas entran en kubelatch y que permite las bajas automáticas. Ver Login con GitHub. |
| Grupo | Un conjunto con nombre de miembros (personas y bots) y permisos del grupo. Cada miembro tiene cada permiso del grupo, como permisos derivados que siguen al grupo. No confundir con un grupo de Kubernetes kubelatch:…. Ver Grupos. |
Grupo kubelatch:… |
Grupo que el proxy suplanta por cada permiso activo: kubelatch:ns:<namespace>:<nivel> o kubelatch:cluster:<nivel>, con role-<id> en lugar del nivel para un rol personalizado. Los bindings del cluster apuntan a estos grupos. Ver Roles de sistema y Roles. |
| Identidad OIDC | Lo que vincula una cuenta con el proveedor de identidad: el issuer del proveedor, el nombre del claim que identifica a la persona (sub, u oid en Entra ID) y su valor. La dirección de correo solo sirve para encontrar la cuenta en su primer acceso. Ver Identidad. |
| Instancia | Un despliegue de kubelatch. Cada cluster pertenece a una sola instancia; la etiqueta kubelatch.io/instance, con el valor de KUBELATCH_INSTANCE_ID, distingue en el cluster los objetos de cada una. Ver Mover un cluster a otra instancia. |
| Jaula del reconciliador | kubelatch-reconciler-jail, la política de admisión del bootstrap que limita las escrituras del reconciliador a objetos kubelatch-*. Kubernetes 1.30 o superior. Ver Modelo de seguridad. |
| kubeconfig | Fichero de configuración de kubectl. El de kubelatch tiene un contexto por cluster, llamado kubelatch-<id>, todos con server: https://<kubelatch>/clusters/<id> y el mismo token. Ver kubectl, k9s, Lens y Helm. |
| MCP (Model Context Protocol) | El protocolo con el que los agentes de IA llaman a herramientas. kubelatch sirve un servidor MCP en /mcp. Ver Servidor MCP. |
| Miembro (de un grupo) | Una cuenta en un grupo, con su propia caducidad opcional. Una cuenta deshabilitada conserva sus pertenencias, que no cuentan hasta que se habilita. Ver Grupos. |
| Modo delegado | Un agente de IA que actúa como una persona, solo con los permisos que la persona eligió al autorizarlo, durante horas. Ver Agentes de IA. |
| Nivel (tier) | Otro nombre de un rol de sistema: viewer, developer, debugger, secrets-reader, admin o cluster-admin. Ver Roles de sistema. |
| Namespace protegido | Namespace que no admite permisos de ningún rol: kube-system, kube-public, kube-node-lease, kubelatch-system y los de KUBELATCH_PROTECTED_NAMESPACES. Ver Roles de sistema. |
| OIDC (OpenID Connect) | El estándar detrás de dos cosas distintas de kubelatch. El login con OIDC deja entrar a las personas con el proveedor de identidad de tu empresa (Login con OIDC (SSO)). El canje de CI toma el token OIDC que GitHub Actions da a un job y emite la credencial de un bot (CI: reglas de confianza). No comparten configuración: la CI funciona con cualquiera de los dos logins, o sin ninguno. |
| Origen (source) | De dónde viene un permiso: concedido a la cuenta, o a través de un grupo. Todas las listas de permisos lo dicen en la columna «Por qué»: «directo», o «vía» y el grupo. Ver Leer un permiso. |
| Permiso (grant) | Sujeto + cluster + rol + ámbito, con caducidad opcional (obligatoria para cluster-admin). Activo mientras no esté revocado ni caducado. Ver Conceder permisos. |
| Permiso del grupo | Un cluster, un rol y un ámbito dados a un grupo, con caducidad opcional. Nunca cluster-admin. Ver Grupos. |
| Permiso derivado (de un grupo) | Un permiso que kubelatch crea por cada combinación de un miembro y un permiso de un grupo. Caduca en la primera de dos fechas, la de la pertenencia y la del permiso del grupo, y solo se cambia o se revoca a través de su grupo. Ver Grupos. |
| Permiso derivado (de un agente) | Un permiso de la sesión de un agente delegado, hecho a partir de uno de su persona: el mismo cluster y ámbito, el mismo rol o viewer, nunca cluster-admin, y termina con la sesión o con el permiso de la persona. Ver Agentes de IA. |
| Permiso sobre un conjunto | Un permiso que da a una persona, a un bot o a un grupo un rol en todos los clusters de un entorno o con una etiqueta, y sigue al conjunto: el cluster que entra lo recibe, y el que sale lo pierde. Pro. Ver Permisos sobre un conjunto. |
| Persona | Sujeto humano: entra en la interfaz y pide credenciales. En el cluster aparece como user:<login>, o como la nombre la plantilla de identidad del cluster. Ver Identidad. |
| Plano de control | La API JSON y la interfaz web de kubelatch. Ver Arquitectura. |
| Plantilla de identidad | Cómo nombra un cluster a las personas en Impersonate-User: texto libre alrededor de una variable, {login}, {email}, {oidc_subject} o {github_login}. user:{login} por defecto; oidc:{email} da oidc:ana@acme.com. Una por cluster. Ver Identidad en el cluster. |
| Proveedor de identidad (IdP) | El servicio en el que entran las personas de tu empresa, como Google Workspace, Microsoft Entra ID, Okta o Keycloak. kubelatch puede usarlo para el login por OpenID Connect. Ver Login con OIDC (SSO). |
| Proxy | La parte de kubelatch que recibe las peticiones de kubectl y la CI en /clusters/<id>/… y las reenvía al cluster con suplantación, actuando como el sujeto. Ver El viaje de una petición. |
| PSA (Pod Security Admission) | Control de Kubernetes que limita qué pods se pueden crear en un namespace según su etiqueta pod-security.kubernetes.io/enforce. developer, debugger, admin y los roles personalizados que lo necesitan exigen baseline o restricted. Ver Roles de sistema. |
| Reconciliador | La parte de kubelatch que mantiene en cada cluster los ClusterRoles de los niveles y de los roles personalizados, los bindings y la lista de a quién puede suplantar el proxy. Se ejecuta al cambiar un permiso, a petición y cada 10 minutos. Ver Arquitectura. |
| Reenrolar | Volver a ejecutar el comando de enrolamiento de un cluster desde su página. «Reenrolar» sustituye los dos tokens de ServiceAccount del cluster por otros nuevos, con un comando que lleva --rotate; «Reenrolar sin cambiar los tokens» aplica el bootstrap actual y los conserva. Rotarlos hace falta tras cambiar KUBELATCH_ENCRYPTION_KEY o la CA del cluster. Ver Rotar los tokens de las ServiceAccounts. |
| Regla avanzada | Regla que un administrador escribe en un rol personalizado, para lo que ninguna capacidad cubre: grupos de la API, recursos, verbos y, si hace falta, nombres de objeto. Ver Roles. |
| Regla de confianza | Regla que dice qué repositorio (y opcionalmente qué ref o entorno) de GitHub puede canjear su token OIDC por una credencial de qué bot. Ver CI: reglas de confianza. |
resourceNames |
Lista de nombres a los que se limita una regla de RBAC. La ServiceAccount del proxy solo puede suplantar a los usuarios y grupos de esa lista. Ver Modelo de seguridad. |
| Retención | Cuánto tiempo se guarda la auditoría antes de que la tarea periódica de retención la borre: KUBELATCH_AUDIT_RETENTION, 90 días por defecto (24 horas como máximo si la instancia nunca tuvo clave). Ver Auditoría y retención. |
| Revocar | Invalidar una credencial o un permiso antes de su caducidad. Una credencial revocada falla en la petición siguiente y sus streams se cortan en 10 s. Ver Caducidad y revocación. |
| Rol | Lo que concede un permiso: un rol de sistema, un rol personalizado o un rol nativo. No es el rol de administrador. Ver Roles. |
| Rol de sistema | Uno de los seis roles que trae kubelatch, también llamados niveles. De solo lectura; todos menos admin y cluster-admin se pueden duplicar. Ver Roles de sistema. |
| Rol nativo | Rol que nombra grupos que el SSO propio del cluster ya conoce. Un permiso de él es pertenencia temporal a esos grupos: kubelatch los suplanta y no escribe ningún binding. Siempre sensible y concedido a todo el cluster. Ver Roles nativos. |
| Rol personalizado | Rol que compone un administrador en «Roles» con capacidades y reglas avanzadas. Es de Pro; se puede editar y eliminar, y necesita el bootstrap actual en el cluster. Ver Roles. |
| ServiceAccount del proxy | kubelatch-proxy, la identidad con la que el proxy habla con cada cluster; solo puede suplantar. Ver Arquitectura. |
| ServiceAccount del reconciliador | kubelatch-reconciler, la identidad con la que el reconciliador escribe RBAC en cada cluster. Ver Arquitectura. |
| Sesión | La cookie __Host-kubelatch_session de la interfaz web (kubelatch_session sobre http sin cifrar), válida 12 h. No sirve para hablar con los clusters. Ver Identidad. |
| Sesión de agente | El registro en kubelatch de un agente de IA conectado por el servidor MCP: en nombre de quién actúa, su credencial, sus condiciones y su línea de tiempo. Para un bot, una por credencial; para un agente delegado, una por autorización. Se corta desde «Agentes». Ver Agentes de IA. |
| Sesión de la CLI | La credencial que crea kubelatch login (tipo cli), guardada en ~/.config/kubelatch/session.json y válida lo que diga KUBELATCH_CLI_SESSION_TTL, 12 h por defecto. Un login nuevo revoca la anterior. Ver La CLI. |
| Sincronización de miembros | Pasada horaria que deshabilita las cuentas cuyo dueño ya no es miembro de la organización de GitHub. Ver Identidad. |
| Solicitud (de un agente) | Lo que un agente pide decidir a una persona: una escritura retenida para aprobar, o acceso a un rol durante un tiempo. «Agentes» lista en «Te esperan» las que puedes decidir, y cada una tiene su página para decidir. Ver Agentes de IA. |
| Sujeto | Todo lo que puede tener permisos: una persona o un bot. Ver Identidad. |
| Suplantación (impersonation) | Mecanismo de Kubernetes por el que una identidad (la ServiceAccount del proxy) actúa en nombre de otra, con las cabeceras Impersonate-*. Ver Por qué un proxy. |
| Techo | Lo que puede hacer un agente delegado: sus permisos derivados, cada uno a partir de un permiso de su persona. Ver Agentes de IA. |
Token klt_ |
La parte secreta de una credencial: klt_ y 43 caracteres. Se muestra una sola vez; kubelatch solo guarda su SHA-256. Ver Modelo de seguridad. |
| Versión del bootstrap | Qué manifiesto de bootstrap tiene un cluster: 1, el anterior, o 2, el actual con la jaula del reconciliador. Los roles personalizados necesitan la 2. Ver Actualizar el bootstrap. |
| Vincular | Asociar una cuenta de kubelatch con el id numérico de una cuenta de GitHub, o con una identidad OIDC. Ver Identidad y La identidad OIDC. |