Solicitudes de acceso¶

En Pro, una persona le pide a kubelatch un rol en un cluster o en un namespace, durante un tiempo, con motivo y ticket: desde «Inicio», desde el enlace que trae el 403 de un cluster o con kubelatch request. Un administrador aprueba o deniega cada solicitud en su propia página, y el permiso que resulta termina solo. Un entorno puede además conceder algunos roles sin aprobación. Esta página es para quien decide y para los administradores que configuran los entornos; cómo se pide está en Pedir acceso.

Antes de empezar¶

• La edición es Pro (Ediciones y licencia). En Free nadie presenta solicitudes.
• Eres administrador de kubelatch. Cada administrador habilitado decide las solicitudes de los demás; nadie decide las suyas.

Qué se puede pedir¶

Una persona habilitada pide un rol en un cluster registrado, en todo el cluster o en un namespace. Los bots no piden: no tienen sesión. Los agentes de IA siguen con sus propias solicitudes (Agentes de IA). Una solicitud nombra uno de estos:

• uno de los seis roles del sistema;
• un rol personalizado que el cluster admite: bootstrap v2, y el cluster entre los del rol (Gestionar roles);
• un rol nativo de ese cluster.

El rol y el sitio siguen las reglas de cualquier permiso (Las reglas): cluster-admin y los roles nativos van solo en todo el cluster, y un rol pensado para namespaces va en un namespace. Un namespace protegido, como kube-system, no se puede pedir. kubelatch no comprueba que el namespace exista al presentar la solicitud, para no contarle a quien no tiene acceso qué hay en el cluster: lo comprueba la aprobación.

Cuánto tiempo¶

El tiempo cuenta desde la aprobación. Una solicitud pide 15 minutos como mínimo, y como mucho lo menor de:

• la duración máxima del entorno del cluster (Reglas);
• el máximo del propio rol: cluster-admin dura 8 horas como mucho;
• 30 días.

Una solicitud nunca pide un permiso sin fin: uno permanente se concede en «Permisos». El formulario propone la caducidad por defecto del entorno, 8 horas como mucho, u 8 horas si no tiene, dentro de esos límites.

Una solicitud espera 24 horas una decisión; después caduca y la persona puede volver a pedirla. Una persona tiene como mucho 20 solicitudes esperando y presenta como mucho 30 en una hora, canceladas incluidas. La misma solicitud (misma persona, cluster, rol y sitio) nunca se presenta dos veces: mientras una espera, pedirla otra vez la abre.

Dónde te llegan¶

• «Solicitudes», debajo de «Agentes» en la barra lateral, cuenta las solicitudes que esperan tu decisión.
• La campanita lo dice en una línea, «2 solicitudes esperan tu decisión.», con un enlace a «Solicitudes».
• Cada solicitud te manda un correo al momento, con su enlace, si el correo está configurado (Solicitudes de acceso (Pro)).
• Un webhook con el evento access_request.created lleva cada solicitud a Slack, a Teams o a tu receptor, y access_request.decided su desenlace (Los eventos).

La página de Solicitudes¶

«Solicitudes» tiene tres pestañas, que se guardan en la dirección (?tab=):

• «Te esperan»: las solicitudes que puedes decidir, las más antiguas primero, con su número.
• «Tuyas»: las que has presentado tú, y en qué quedaron.
• «Decididas»: las decididas en los últimos 30 días, por ti y por los demás.

Cada fila es una frase, «dev pide debugger en prod/shop durante 2 h», con el motivo entre comillas debajo, el ticket, cuánto hace que se pidió y cuándo caduca, y «Abrir». Una fila marca una «Prórroga», con el final que tiene ahora el permiso, y una solicitud que «Lo decide un administrador». Una fila decidida enseña su estado y quién la decidió, o «la regla de su entorno». Quien no decide nada ve solo sus solicitudes, sin pestañas.

Decidir una solicitud¶

Abre la solicitud desde su fila, su correo, la campanita o el mensaje del webhook. Su página, /requests/<id>, tiene:

• La solicitud como título, su estado, cuánto hace y desde dónde se pidió («desde un 403: create pods/exec», «desde la CLI», «desde la web») y cuándo caduca.
• «La solicitud»: «Quién», «Rol» con lo que hace, «Dónde», «Durante», «Motivo», «Ticket» (un enlace si tu kubelatch enlaza los tickets), «Pedida», «Quién decide» y «Ya tiene aquí», los permisos que la persona tiene en ese cluster y de dónde viene cada uno.
• «Tu decisión»: «Durante», la duración pedida u otra más corta, y «Nota para dev», que la persona lee con la decisión, en la campanita y por correo.
• «Denegar» y «Aprobar 2 h», debajo de la decisión. En el móvil se quedan al pie de la pantalla.

Una aprobación puede acortar la solicitud, nunca alargarla. Si la duración máxima del entorno bajó desde la solicitud, la página ofrece lo que cabe ahora y lo dice: «Pedía 8 h; ahora cabe como mucho 1 h.».

«Aprobar» concede el permiso con todas las comprobaciones de un permiso concedido en «Permisos»: el namespace existe y aplica el nivel de Pod Security que el rol necesita, el cluster puede nombrar a la persona y un rol que el cluster hace privilegiado dura 8 horas como mucho (Las reglas). Si una comprobación falla, la página dice por qué y la solicitud sigue esperando. El permiso lleva el motivo y el ticket de la solicitud, te nombra como quien lo concedió, enlaza la solicitud y termina solo (Caducidad y revocación).

«Denegar» cierra la solicitud con tu nota. La persona puede volver a pedirla.

Si otra persona la decidió antes, o caducó o se canceló mientras la leías, la página dice «Esta solicitud ya no espera una decisión.» y enseña cómo ha quedado.

Decidir necesita el navegador: kubelatch request pide, espera, consulta y cancela, pero nunca aprueba ni deniega.

Decidir varias a la vez¶

En Te esperan, cada solicitud que puedes decidir tiene una casilla. Marca varias y aparece una barra con Aprobar N y Denegar N, hasta 50 a la vez. Una solicitud que solo decide un administrador no tiene casilla para ti.

Cada botón abre una confirmación que lista las solicitudes. Admite una Nota para quienes piden opcional, que cada una de esas personas lee con la decisión. Aprobar concede cada solicitud por el tiempo que pide, con las mismas comprobaciones que una aprobación suelta; el lote es todo o nada, así que si una solicitud no se puede aprobar (otra persona la decidió antes, o el cluster la rechaza), no se aprueba ninguna, la página nombra esa solicitud y las casillas siguen marcadas. Denegar las cierra todas o ninguna.

En el registro de auditoría el lote se lee como una sola línea, «ana aprobó 3 solicitudes de acceso», con los permisos que concedió contados como cambios derivados.

Prórrogas¶

Una solicitud de un rol y un sitio que la persona ya tiene por un permiso directo suyo pide ampliarlo: su fila y su página dicen «Prórroga», y «Durante» dice hasta dónde lleva el permiso. La aprobación mueve el final de ese permiso, dentro del máximo del entorno; si el permiso terminó entretanto, concede uno nuevo desde la aprobación. Un permiso que llega por un grupo o por un conjunto no se amplía: la solicitud concede uno directo.

Cuando nadie más puede decidir¶

Nadie decide su propia solicitud. Cuando pide el único administrador y nadie más es dueño del sitio, la solicitud no se presenta: el formulario dice «Nadie más puede decidirlo.» y lleva a «Permisos», donde un administrador concede el permiso como siempre. Una solicitud que solo decide un administrador tampoco se presenta cuando la pide el único administrador, sea quien sea el dueño del sitio.

Solicitudes que solo decide un administrador¶

Algunas solicitudes llevan «Lo decide un administrador»: cluster-admin, un rol nativo o un rol que la lectura en vivo del RBAC del cluster dice que es privilegiado para esa persona y ese sitio. Si no se puede leer el cluster, la solicitud también se marca: falla hacia lo seguro. Un dueño del sitio no puede decidirla, y nunca se concede sin aprobación.

Sin aprobación (Pro)¶

Un entorno puede conceder algunos roles sin aprobación: una solicitud de uno de ellos, en sus clusters, se concede al presentarla, con todas las comprobaciones de un permiso.

1. En la página del entorno, pulsa «Cambiar reglas» en la tarjeta «Reglas».
2. En «Sin aprobación», marca los roles. «Roles del sistema» lista todos los roles del sistema menos cluster-admin, con la línea «cluster-admin siempre lo decide un administrador.»; «Roles personalizados» lista los roles personalizados. Los roles nativos nunca se ofrecen.
3. Pulsa «Guardar».

La tarjeta «Reglas» los dice después en «Sin aprobación», como viewer, developer, o «Ninguno».

Qué pasa con una solicitud de uno de esos roles:

• Si pasa todas las comprobaciones, el permiso se concede al momento, y la solicitud dice «Concedida sin aprobación por la regla de su entorno».
• Si una comprobación falla (el namespace no existe, le falta Pod Security, el cluster no puede nombrar a la persona), no se presenta ninguna solicitud: la persona recibe el error, como en el formulario de «Permisos».
• Si el rol es privilegiado para esa persona y ese sitio, o no se puede leer el cluster, la solicitud se presenta y espera a un administrador.

Un rol sin marcar siempre necesita aprobación, así que un rol personalizado nuevo la necesita hasta que alguien lo marque. Un rol personalizado eliminado sigue marcado, con «(eliminado)», hasta que lo desmarques.

Dueños (Pro)¶

Un administrador puede nombrar dueños: personas, o grupos de kubelatch, que gestionan un sitio sin ser administradores. Un dueño es una persona habilitada (un bot nunca lo es), y un grupo cuenta por los miembros que tiene en vigor.

Los administradores conservan todo lo demás: cuentas, roles, clusters, entornos, credenciales y el nombramiento de dueños.

Nombrar a un dueño¶

Cada una de estas páginas tiene una tarjeta «Dueños»: la del cluster en la pestaña «Acceso», la del entorno después de su tarjeta «Permisos» y la del grupo antes de «Detalles».

1. Pulsa «Añadir dueño».
2. En «Quién», elige «Una persona» o «Un grupo». Un grupo no puede ser dueño de sí mismo.
3. En un cluster, en «Dónde», elige «Todo el cluster» o «Un namespace» y escribe el namespace; los namespaces del cluster se ofrecen mientras escribes.
4. Pulsa «Añadir dueño».

La tarjeta lista cada dueño con el sitio que cubre. En un cluster muestra también los dueños de su entorno, marcados «heredado de prod»: se quitan desde la página del entorno. Un grupo que es dueño de algo lo dice en su propia página: solo un administrador cambia sus miembros.

Para quitar a un dueño, abre el menú de su fila, pulsa «Quitar dueño» y confirma. Deja de actuar al instante; los permisos que concedió siguen.

Nombrar dueños es de Pro. En Free, o con la clave caducada, las tarjetas muestran los dueños ya nombrados y dejan quitarlos, pero «Añadir dueño» cede su sitio a «Ver Pro», y los dueños no actúan hasta que la edición vuelva a ser Pro.

Quién decide¶

Una solicitud se pide a los dueños de su sitio, los más concretos que haya: los del namespace, si no los del cluster, si no los de su entorno. Su página, el formulario y kubelatch request los nombran con su sitio, "luis, carmen (owners of prod/shop) or an administrator", hasta 50 y cuántos más. Sin más dueño que quien pide, deciden los administradores, como sin dueños.

Decide cualquier dueño del sitio, no solo los nombrados: el dueño de prod también decide una solicitud en prod/shop, y la encuentra en «Te esperan». Un administrador decide todas las solicitudes.

El correo de una solicitud nueva va a las personas que nombra. Antes de enviar cada correo, kubelatch comprueba que su destinatario sigue decidiendo la solicitud: no le llega a quien dejó de ser dueño, ni a quien dejó de ser miembro del grupo dueño.

Una solicitud marcada «Lo decide un administrador» solo la decide un administrador: un dueño la ve en la lista, pero no puede aprobarla ni denegarla. Cuando un dueño aprueba un permiso que el cluster ha hecho privilegiado desde que se presentó la solicitud, la aprobación se rechaza con 403 access_request.admin_only, la solicitud se marca y los administradores reciben su correo.

Lo que ve un dueño¶

Un dueño que no es administrador tiene «Solicitudes» en la barra lateral y un grupo «Lo que gestionas» con «Permisos» y «Grupos»: las mismas páginas y acciones, con solo sus sitios y sus grupos. Para elegir a quién conceder o añadir, ve las personas habilitadas, solo con su login y su nombre, los grupos y los namespaces de cada cluster que gestiona entero. La página de una solicitud lista lo que la persona ya tiene en lo que el dueño gestiona, y nada del resto del cluster. Su formulario de «Conceder» sigue las reglas del entorno de cada cluster, como el de un administrador: propone la caducidad por defecto, se queda en el máximo y pide el motivo o el ticket que el entorno exige. «Usuarios», «Roles», «Credenciales» y «Auditoría» siguen siendo de los administradores.

En la auditoría¶

El plano de control tiene una frase para cada paso, con la solicitud como objetivo, que enlaza su página (El plano de control):

• «ana» pidió debugger en shop de prod durante 2 h, o pidió ampliar … 1 h;
• Solicitud de «ana» aprobada: debugger en shop de prod, hasta el …, o, sin persona, Solicitud de «ana» concedida por la regla de staging: …;
• Solicitud de «ana» denegada: …, «ana» canceló su solicitud: …, Solicitud de «ana» caducada sin decisión: … y Solicitud de «ana» cancelada al deshabilitarse su cuenta: ….

El grant.create del propio permiso dice «concedido a «ana» por la regla de staging» cuando lo concedió un entorno: quien pidió es su actor, pero nadie lo decidió.

En Free y con la clave caducada¶

En Free, presentar una solicitud responde 403 edition.feature (Errores). «Solicitudes» sigue en la barra lateral para los administradores, con «Pro», y su página explica la función con «Ver Pro». Marcar un rol en «Sin aprobación» pide Pro.

Con la clave caducada nadie presenta solicitudes nuevas y nada se concede sin aprobación, pero las que ya esperan las siguen decidiendo los administradores: «Solicitudes» conserva su lista y su número mientras quede alguna. Desmarcar un rol en «Sin aprobación» nunca pide Pro: en Free, «Cambiar reglas» sigue mientras quede alguno marcado.

Por API¶

/api/access-requests lista, lee, presenta, aprueba, deniega y cancela solicitudes, y PATCH /api/environments/{id} acepta auto_approve_roles (API HTTP).