Pedir acceso¶

En Pro, cuando necesitas un rol que no tienes, lo pides desde el propio kubelatch, durante un tiempo, con un motivo y un ticket: desde «Inicio», desde el enlace que trae el 403 de un cluster o con kubelatch request. Lo deciden los dueños del sitio o un administrador, y el permiso que recibes termina solo.

Desde dónde se pide¶

Inicio. Mientras no tengas ningún permiso, el paso 2 de «Tu conexión» ofrece «Pedir acceso», con «El formulario te dice quién lo decide.». Cada cluster de «Mis clusters» ofrece «Pedir más», que abre el formulario con ese cluster elegido, y cada línea de un permiso con final ofrece su forma de pedir más tiempo (Prórrogas); también «Tu semana», para lo que termina en los próximos siete días.
La paleta de comandos (⌘K o Ctrl K): «Pedir acceso».
El enlace de un 403. Cuando el cluster rechaza una petición y kubelatch conoce un rol que la permitiría, el error termina con un enlace que abre el formulario con el cluster, el namespace y el rol ya puestos (403 — sin permiso). Si no tienes sesión, kubelatch te pide entrar y te devuelve al formulario.
El aviso de caducidad. Cuando un permiso tuyo termina en menos de 24 horas, la campanita y el correo que te avisan ofrecen «Pedir prórroga» (o «Pedir más»), que abre el formulario con ese permiso elegido.
El terminal, con kubelatch request (kubelatch request): la misma solicitud, que espera la decisión en el terminal.

El formulario¶

«Pedir acceso» pide seis cosas:

«Cluster»: los clusters enrolados en kubelatch.
«Dónde»: «Todo el cluster», o «Un namespace», cuyo nombre escribes. kubelatch no comprueba que el namespace exista al pedirlo: lo comprueba la aprobación, como en cualquier permiso. Un namespace protegido (como kube-system) no se puede pedir.
«Rol»: los roles que puedes pedir en ese cluster, cada uno con su descripción. El que nombró el 403 va primero, marcado «Lo que pedía el 403», y los demás esperan en «Más roles». Un rol que no va donde elegiste sigue en la lista, desactivado, y dice por qué: «Solo en todo el cluster.» o «Solo en un namespace.». «Sin aprobación» marca un rol que el entorno del cluster concede al momento.
«Durante»: las duraciones que caben, empezando por la que propone kubelatch, y debajo la regla que las limita, por ejemplo «prod permite como mucho 8 h.».
«Motivo»: siempre obligatorio. Lo lee quien decide.
«Ticket»: un enlace, o una clave como INC-123. Es opcional, salvo que el entorno del cluster lo pida: entonces el campo lo dice («· obligatorio en prod»). Si tu kubelatch enlaza las claves con el tracker de tu equipo, el formulario enseña el enlace que será el ticket.

Junto al formulario, «Lo decide» nombra a quien se le pide decidir la solicitud, o dice que el entorno concede el rol sin aprobación. En Pro un sitio puede tener dueños: la solicitud se pide a los del namespace, si no a los del cluster, si no a los de su entorno, y también puede decidirla un administrador; sin dueños, deciden los administradores. Una solicitud de cluster-admin, de un rol nativo o de un rol privilegiado siempre espera a un administrador. «Ya tienes aquí» enumera tus permisos en ese cluster, con de dónde viene cada uno.

El botón dice lo que va a pasar: «Pedir debugger en pagos durante 2 h», «Pedir viewer en todo prod durante 8 h», u «Obtener viewer en web durante 8 h» cuando el entorno concede ese rol sin aprobación. Mientras falte algo, el botón dice qué debajo de él.

Al enviarla se abre la página de la solicitud, donde ves quién la decide y cómo va. Si la misma solicitud (mismo cluster, rol y sitio) ya esperaba, kubelatch no crea otra: abre la que espera.

Si nadie más puede decidirla, por ejemplo porque eres el único administrador y nadie más es dueño del sitio, el formulario dice «Nadie más puede decidirlo.». Un administrador se lo concede en «Permisos»: «Concédetelo en Permisos» lleva allí.

Cuánto tiempo se puede pedir¶

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

el máximo que el entorno del cluster permite a un permiso de una persona;
el máximo del propio rol: cluster-admin dura como mucho 8 horas;
30 días.

Una solicitud nunca pide un permiso sin final: uno permanente lo concede un administrador en «Permisos». Quien decide puede acortar lo que pediste, nunca alargarlo.

Prórrogas¶

Una solicitud del rol y el sitio de un permiso directo tuyo que tiene final es una prórroga: al aprobarse, suma su tiempo al final del permiso en vez de crear otro. El formulario lo dice antes de enviarla, «Es una prórroga: tu permiso termina el 12 nov, 18:00; con 2 h más terminaría el 12 nov, 20:00.», «Durante» ofrece lo que aún puede sumar una prórroga, con la regla debajo («Una prórroga puede sumar ahora como mucho 6 h.»), y el botón lo dice: «Pedir 2 h más de debugger en shop».

Una prórroga sigue los límites de un permiso ampliado a mano: el final nuevo no pasa del máximo del entorno contado desde ahora, y las 8 horas de cluster-admin cuentan desde que se creó el permiso. Un permiso que ya no admite más tiempo dice «Este permiso ya no admite más tiempo. Pide uno nuevo cuando termine.», y uno sin final, «Ya tienes este permiso, sin caducidad.»: ninguno de los dos se puede pedir.

En «Inicio», cada línea de un permiso con final ofrece «Pedir prórroga», junto a «Copiar comando», y lo mismo su recuadro en «Tu semana». Un permiso que te llega por un grupo o un conjunto no admite prórroga: su línea ofrece «Pedir más», una solicitud nueva del mismo rol y sitio. Lo que caducó esta semana lleva a «Pedir acceso».

La vida de una solicitud¶

Espera una decisión 24 horas. Después caduca, y puedes volver a pedirlo.
Puedes tener como mucho 20 solicitudes esperando a la vez.
Mientras espera, puedes cancelarla: desde «Inicio», desde su página o con kubelatch request cancel <id>.

«Mis solicitudes», en «Inicio», enumera tus solicitudes que esperan, con cuánto hace que las pediste y «Cancelar», y las cerradas en las últimas 24 horas: aprobadas, denegadas, caducadas o canceladas, con quién decidió (o la regla del entorno), hasta cuándo dura el permiso y la nota que te dejó. «Ver todas» las abre todas.

Después de la aprobación¶

El permiso aparece en «Mis clusters», y su línea dice de dónde viene: «por solicitud», un enlace a la solicitud, y después quién la aprobó («aprobada por luis») o «sin aprobación» si la concedió el entorno del cluster; un permiso que la solicitud amplió dice «prórroga» en su lugar. Dura lo aprobado y termina solo, como cualquier otro permiso (Caducidad y revocación). Si el cluster es nuevo para ti, consigue su contexto con kubelatch kubeconfig (La CLI) o con una credencial nueva (Obtener una credencial).

Una solicitud denegada lleva la nota de quien la denegó.

En Free¶

No hay formulario: el paso 2 de «Tu conexión» y la página de solicitud dicen a quién pedírselo, el contacto que configuraron tus administradores o, sin él, el administrador más antiguo, y el 403 también lo nombra. Las solicitudes y aprobaciones de los agentes de IA funcionan como siempre (Agentes de IA).