Acceso por dominio y solicitudes de alta¶

Con el login con OIDC, quien no tiene cuenta puede entrar sin que un administrador se la cree antes. Una regla de dominio da de alta a quien llega con un correo verificado de ese dominio y lo mete en un grupo, así que aterriza en «Inicio» con los permisos del grupo. Los demás pueden pedir unirse desde la misma pantalla a la que llegan, y un administrador aprueba o deniega la solicitud en «Usuarios». Las dos cosas funcionan igual en Free y en Pro. El login con GitHub no da de alta a nadie: una cuenta de GitHub no demuestra ninguna dirección de correo.

El primer acceso de una persona¶

kubelatch busca la cuenta de la persona en este orden y se queda con lo primero que encuentra:

La identidad del proveedor ya está vinculada a una cuenta: entra con ella.
Una cuenta tiene esa dirección de correo: se vincula por correo, si OIDC_AUTOLINK lo permite (Cómo se vinculan las cuentas). Solo cuentan las cuentas habilitadas; si todas están deshabilitadas, o hay dos, el acceso se rechaza como siempre (disabled, ambiguous_account).
Ninguna cuenta tiene la dirección, ni siquiera a través de una identidad del proveedor: si el dominio tiene regla, kubelatch crea la cuenta y entra con ella; si no la tiene, o la regla no puede dar de alta a la persona, el navegador va a «Pedir unirse».

Antes, la dirección tiene que pasar las comprobaciones de siempre: que el proveedor la garantice y que su dominio esté en OIDC_ALLOWED_DOMAINS. Si no, el acceso acaba en email_unverified o en domain_not_allowed antes de llegar a ninguna regla ni solicitud. Si una cuenta tiene la dirección solo a través de su identidad, con otra identidad del proveedor, el acceso recibe identity_mismatch, como en Bajas y direcciones reutilizadas: una dirección que ha cambiado de manos nunca crea una cuenta junto a la antigua ni llega a una solicitud. Esos casos los tiene que mirar un administrador.

Acceso por dominio¶

Una regla nombra un dominio de correo de OIDC_ALLOWED_DOMAINS, el grupo en el que entran las personas nuevas y, si quieres, cuánto dura esa pertenencia. Los permisos los lleva el grupo: lo que cambies en el grupo llega a todos los que entraron por la regla, como a cualquier miembro (Grupos).

Todo el dominio recibe los permisos del grupo

Una regla da los permisos del grupo a cualquier persona de la empresa que entre por primera vez. Apúntala a un grupo con un rol modesto, como viewer en los namespaces que necesita todo el mundo, y concede el resto a mano. Un grupo nunca lleva cluster-admin.

Añadir un dominio¶

En «Usuarios», la tarjeta «Acceso por dominio» lista las reglas. Solo aparece con el login con OIDC activo. Pulsa «Añadir dominio».
En «Dominio», elige uno de OIDC_ALLOWED_DOMAINS que aún no tenga regla. Son dominios exactos, como en la variable: un subdominio es otro dominio.
En «Entra en el grupo», elige «Existente» y el grupo, o «Nuevo grupo»: su «Nombre del grupo», su «Id del grupo» (se propone a partir del nombre, puedes cambiarlo hasta guardar y nunca se reutiliza) y, si quieres, su «Primer permiso (opcional)», con el mismo formulario que los permisos de un grupo.
En «Pertenencia», elige «Sin caducidad», «30 días», «90 días» u «Otra» con sus «Días»: cuánto dura la pertenencia de cada persona nueva, contada desde su alta. Los permisos del grupo conservan sus propias caducidades.
Pulsa «Guardar». El aviso dice «Regla de {domain} creada.».

Con «Nuevo grupo», el grupo, su primer permiso y la regla se crean a la vez: un permiso que las reglas rechazan no deja ningún grupo detrás. Un dominio va a un solo grupo; para llevarlo a otro, quita su regla y añade una nueva.

Qué recibe cada persona nueva¶

Una cuenta, con el login sacado de lo que va antes de la @ de su dirección: en minúsculas, con cada carácter que no sea una letra de la a a la z, una cifra, ., _ o - cambiado por -, y sin los ., _ o - con los que empiece. Ana.Perez@acme.com da ana.perez. Si ya hay una cuenta con ese login, habilitada o no, se usa <login>.<dominio> (ana.perez.acme.com); si ese también existe, no se crea nada y la persona va a «Pedir unirse», donde eliges tú el login. El nombre viene del proveedor, y el correo de la cuenta es la dirección del proveedor.
Su identidad vinculada: en «Usuarios», «Entrada» dice «{name} · por dominio».
La pertenencia, marcada «dominio {domain}» en la ficha del grupo, y los permisos del grupo que se derivan de ella. Esos permisos nombran como quien los concedió a quien creó la regla, porque fue esa persona quien decidió que el dominio los recibiera.

Los logins se reparten por orden de llegada entre todos los dominios de OIDC_ALLOWED_DOMAINS, por regla o por solicitud: bob@contractor.io puede quedarse con bob antes de que entre bob@acme.com. En un cluster cuya plantilla de identidad usa {login} y enlaza usuarios por nombre, usa {email} o {oidc_subject} en su lugar.

Antes de crear nada, kubelatch vuelve a comprobar los permisos del grupo, igual que cuando añades a un miembro a mano. Si uno ya no pasa, por ejemplo porque su namespace perdió la etiqueta de PSA, o un cluster no responde, no se da de alta a nadie: la persona va a «Pedir unirse». Arregla o revoca ese permiso del grupo.

La tabla de reglas¶

Cada fila lleva su «Dominio», el grupo en el que «Entra en el grupo» con lo que ese grupo da, la «Pertenencia» («sin caducidad» o «30 días desde el alta») y cuántas personas «Han entrado» por ella. Un dominio que ha salido de OIDC_ALLOWED_DOMAINS lleva la etiqueta «fuera de la configuración»: la regla no hace nada hasta que el dominio vuelva.

El menú de la fila tiene:

«Cambiar caducidad»: la caducidad de la pertenencia de quienes se den de alta a partir de ahora. Quienes ya están conservan la suya; cámbiala en la ficha del grupo («Prorrogar»).
«Quitar»: tras confirmarlo, borra la regla y retira las pertenencias que añadió y que siguen vivas, con los permisos que derivan. Las cuentas siguen habilitadas, sin esos permisos, y los miembros que añadiste a mano se quedan. Una regla solo actúa cuando alguien se da de alta: a un miembro que quitas a mano no lo vuelve a añadir.

Un grupo al que apunta una regla no se puede borrar hasta que quites la regla (409 signup_domain.group_in_use).

El tope de personas de Free¶

Cada cuenta que crea una regla ocupa una plaza. En Free, con las cinco personas ya dentro, a la sexta no se la da de alta: llega a «Pedir unirse» con «kubelatch está en su tope de personas; un administrador tendrá que liberar una plaza o ampliar la edición.», y puede enviar su solicitud. Aprobarla responde 422 edition.limit mientras no haya una plaza libre (Ediciones y licencia). Dos primeros accesos a la vez nunca ocupan más plazas de las que hay.

Solicitudes de alta¶

Qué ve la persona¶

«Pedir unirse» dice «Has entrado con {provider} como {address}, pero ninguna cuenta de kubelatch tiene esa dirección.». Enseña el nombre que mandó el proveedor, sin poder cambiarlo, un «Motivo» opcional de hasta 500 caracteres, el contacto de acceso (KUBELATCH_ACCESS_CONTACT) y «Probar con otra cuenta». «Enviar solicitud» la deja pendiente:

Estado	Qué dice la página
«Solicitud pendiente»	Cuándo la pidió y cuándo caduca si nadie decide: 30 días después.
«Solicitud denegada»	La fecha y el contacto. Nunca tu nota.
Aprobada	No hay nada que esperar: entra en su siguiente acceso.
Caducada	El formulario otra vez, con «Tu última solicitud caducó sin respuesta. Puedes pedirlo de nuevo.».

La persona nunca escribe su dirección: la pone el proveedor, en una cookie firmada que dura diez minutos y que se gasta al enviar la solicitud. Para ver más tarde cómo va, vuelve a entrar con «Entrar con {name}».

Cada persona puede tener una solicitud pendiente, y la instancia, 100 como mucho (a partir de ahí, 429 join.too_many); la página comparte el límite por IP del login. Una solicitud no ocupa plaza hasta que la apruebas.

Aprobar o denegar¶

La tarjeta «Solicitudes de alta», en «Usuarios» y solo con el login con OIDC activo, lista las pendientes con «N pendientes»: el nombre de la persona, su dirección, el proveedor, cuándo lo pidió y su motivo. «Avisos», en la barra superior, dice «1 persona ha pedido unirse a kubelatch.» y lleva hasta ella.

«Aprobar…» abre «Aprobar a {name}». El «Login» viene sugerido a partir de la dirección, con la regla de arriba; un login no cambia después. En «Acceso inicial», elige «Grupo» y el grupo, «Permiso directo» con el formulario de siempre, o «Ninguno». Con un tope de personas, una línea dice qué plaza ocupa: «Ocupa una plaza: 4 de 5.». «Aprobar» crea la cuenta, vincula su identidad («{name} · por solicitud» en «Entrada») y le da ese acceso, todo a la vez o nada: si el grupo o el permiso se rechazan, no se crea nada y la solicitud sigue pendiente. Un login que ya existe marca el campo.
«Denegar» pregunta antes, con una «Nota interna (opcional)». La persona ve que se ha denegado y el contacto de acceso, no tu nota. Si se la deniegas, la persona puede volver a pedirlo.

Si entretanto alguien creó una cuenta con esa dirección, aprobar responde 409 join.email_taken: vincula esa cuenta en su lugar. Una solicitud cuya persona ha entrado por otra vía (una regla nueva, una cuenta emparejada por correo, un enlace) se cancela sola. La que espera 30 días caduca, y la persona puede volver a pedirlo. La tarjeta solo lista las pendientes: las decididas, canceladas y caducadas quedan en el registro de control.

En el registro de auditoría¶

Cada paso deja su fila en «Auditoría» → «Plano de control» (El plano de control):

Qué pasó	Filas
Un alta por dominio	`user.create` con `via: domain` y el `domain`, sin actor; `oidc.link` con `via: domain`; `group.member.add` sin actor y con `rule`, el dominio; un `grant.create` por permiso derivado, con quien creó la regla como actor y `rule`; `login.success`.
Un alta que no ocurrió	`login.failure` con `reason: unknown_account` y, cuando había regla, `signup_refused`: `seat_limit`, `login_taken` o `group_check`.
Una solicitud	`access_request.create`, sin actor, con la dirección, el issuer y el subject del proveedor.
Una aprobación	`user.create` con `via: join` y el `request_id`; `oidc.link` con `via: join`; las filas propias del grupo o del permiso; `access_request.approve` con la dirección, el `login` y el acceso concedido.
Una denegación	`access_request.deny` con la dirección. La nota va en la solicitud, no en la fila.
Una solicitud cancelada	`access_request.cancel`, con cómo entró la persona (`via`).
Una regla	`signup_domain.create`, `signup_domain.update` (`from` y `to`, en segundos) y `signup_domain.delete` (`members_removed`), con un `group.member.remove` por cada pertenencia retirada, con `rule`.

Por API¶

Las rutas están en API HTTP y sus errores en Errores.