Ediciones y licencia¶

kubelatch tiene dos ediciones. Free es el producto entero con algunos límites; Pro los quita con una clave de licencia que kubelatch verifica por su cuenta, sin llamar a ningún servicio. Esta página dice qué incluye cada edición, cómo instalar una clave y qué pasa cuando caduca.

Qué incluye cada edición¶

Cada persona habilitada cuenta, también los administradores y las cuentas break-glass; los bots nunca. Deshabilitar a alguien libera su plaza. Un cluster es cualquier cluster registrado, en cualquier estado; borrar uno libera su plaza. Pro se cobra por persona: ver kubelatch.com/pricing, que ofrece también una prueba de 30 días sin tarjeta.

La edición en vigor aparece junto al nombre, arriba de la barra lateral, para todo el mundo. Un administrador puede pulsarla para abrir «Edición», que también está en el menú de la cuenta, al pie de la barra lateral.

Qué hace un límite¶

Un límite solo frena un alta nueva. Estas responden 422 edition.limit:

• Invitar a la sexta persona, o rehabilitar a una cuando hay 5 habilitadas.
• Registrar el tercer cluster.
• Crear o editar un rol personalizado.

kubelatch-server user create rechaza a la sexta persona con un mensaje que apunta a esta página. La interfaz lo dice donde ocurre y en «Edición». Nada de lo que existe se corta: el proxy, los grants, las credenciales, los clusters y las personas siguen funcionando.

En Free, «Auditoría» muestra las últimas 24 horas. Una instancia que nunca tuvo clave conserva la auditoría 24 horas como máximo (un KUBELATCH_AUDIT_RETENTION mayor se recorta a 24 horas, y 0 también pasa a 24 horas); la que tiene o tuvo una clave (también una clave caducada, y una que no verifica mientras siga configurada) mantiene su retención configurada y solo deja de servir lo anterior a 24 horas hasta instalar una clave.

La página de Edición¶

«Edición» abre con una frase que dice en qué punto está la instancia, con fechas relativas a hoy:

• Free · 2 de 2 clusters · 4 de 5 personas · auditoría 24 h
• Pro · 20 plazas · caduca en 365 d (9 oct 2027), o Prueba de Pro · acaba en 12 d (22 oct)
• Pro caducada · gracia hasta el 8 nov (en 12 d): después, topes de Free para altas nuevas
• Pro caducada · topes de Free para altas nuevas desde el 8 nov

Bajo una clave de pago, una cronología da sus tres hitos: «Pro hasta el …», «Gracia hasta el …» y «Topes de Free desde el …», con el actual en negrita. Una prueba no la tiene: no tiene gracia.

«Uso y límites» cuenta personas, clusters y roles personalizados contra sus topes. Cada etiqueta enlaza a su lista («Usuarios», «Clusters», «Roles»), y una fila en su tope dice qué libera una plaza: En el tope: deshabilitar a alguien libera una plaza. o En el tope: eliminar un cluster libera uno. Un tope de cero dice «Solo en Pro» (3 conservados · solo en Pro cuando una clave caducada dejó roles personalizados). «Retención de auditoría» da el valor en vigor (24 h, 90 d o «Se conserva siempre») y, en una instancia Free cuya retención configurada es mayor, se muestran las últimas 24 h.

«Estado» lista, además de la frase, el «Origen de la clave» («Sin clave», KUBELATCH_LICENSE o «Pegada aquí»), el «Cliente», el «Id de licencia» en un campo para copiar, «Gracia hasta» (solo en gracia), «Por encima de las plazas desde» (solo mientras lo está) y «Problema con la clave» (cuando no verifica). La fila «Versión» dice qué versión de kubelatch se ejecuta y qué encontró la comprobación diaria: 0.30.0 · hay 0.31.0 publicada con «Cómo actualizar», 0.30.0 · es la última (comprobado hace 3 h), 0.30.0 · sin comprobar todavía o 0.30.0 · comprobación desactivada. Con la comprobación activa, «Comprobar ahora» comprueba en el momento (Actualizar).

«Salud de la instalación» lista los ajustes que protegen la instancia, cada uno con su estado: Pod Security Admission, la verificación en dos pasos en la organización de GitHub, la sincronización con GitHub y su webhook member_removed (estos tres solo con la GitHub App), la conciliación de los clusters, la clave de licencia (solo con una clave de pago o una prueba) y la versión. Una comprobación que falla dice qué significa y enlaza a donde se arregla; una sin datos todavía lo dice. En «Inicio», un administrador ve al pie una línea, Estado de la instalación: 2 recomendaciones pendientes, que lleva aquí; con todas las comprobaciones en verde, la línea no aparece.

En Free, «Free y Pro» pone las dos lado a lado en cuatro filas: clusters, personas, roles personalizados y auditoría visible. Al pie, una línea repite a qué nos comprometemos y enlaza a ello.

Instalar una clave¶

La clave llega por correo tras una compra o una prueba. Tres formas de instalarla:

1. «Edición» (la edición junto al nombre, arriba de la barra lateral, o «Edición» en el menú de la cuenta): pega la clave en «Clave de licencia» y pulsa «Instalar la clave». Se guarda cifrada y se comprueba de nuevo cada hora.
2. La variable KUBELATCH_LICENSE (ver Configuración). Mientras esté puesta, una clave ya pegada en «Edición» se ignora y la interfaz no puede instalar ni quitar una clave.
3. En Kubernetes, la misma variable en el Secret kubelatch-secrets, con secrets.env (solo con secrets.create) o con tu propio Secret (secrets.existingSecret).

kubelatch-server license show imprime la edición en vigor y kubelatch-server license verify <fichero> comprueba un fichero de clave antes de instalarla (CLI del servidor). Cada clave lleva su cliente y sus plazas; la clave de renovación llega cada año y sustituye a la actual. Una renovación pegada en «Edición» se aplica al momento; una puesta con la variable o con el Secret del chart se lee al arrancar, así que reinicia kubelatch (Actualizar y copias de seguridad dice qué reinicia los pods).

¿Has perdido la clave? Pídela de nuevo en kubelatch.com/es/pro/key con la dirección de correo con la que compraste: se vuelve a enviar la clave de cada suscripción activa. Las plazas, las facturas y la cancelación se gestionan desde el portal de cliente enlazado en ese correo.

Caducidad, gracia y plazas¶

• Desde 30 días antes de que caduque la clave, los administradores ven un aviso en la campana y en «Edición».
• Al caducar, Pro sigue 30 días de gracia.
• Una clave de prueba es Pro durante 30 días, sin límite de personas y sin gracia después.
• Tras la gracia (o al acabar una prueba), la clave está caducada: los límites de Free se aplican a las altas nuevas, los roles personalizados existentes siguen funcionando y solo se pueden borrar, y la auditoría se sirve 24 horas hacia atrás. No se borra nada: la retención configurada se mantiene, y al instalar otra clave vuelve a verse todo lo conservado.
• Plazas: cuando hay más personas habilitadas que plazas en la clave, los administradores reciben un aviso; a los 30 días no se pueden añadir más personas hasta ampliar las plazas o deshabilitar a alguien. Instalar otra clave nunca reinicia esos 30 días; solo empiezan de nuevo cuando las personas caben otra vez en las plazas o se instala una clave de pago sin límite de plazas. Las plazas se amplían desde el portal de la suscripción; la clave nueva llega por correo en minutos.

A qué nos comprometemos¶

• Lo que está en Free sigue en Free; sus límites solo se relajan.
• Sin telemetría: la clave se verifica sin conexión. La única llamada de kubelatch a Picaporte Labs es la comprobación diaria de versión (un GET de un JSON pequeño sin identificador ni versión; lo que ven los administradores), y KUBELATCH_UPDATE_CHECK=false la desactiva. Las instalaciones aisladas de internet funcionan.
• Un límite solo frena un alta nueva. Nada de lo que existe se corta: el acceso a través del proxy, los grants, las credenciales, los clusters, las personas y los roles personalizados ya materializados siguen funcionando. Si alguna vez se instaló una clave, la auditoría anterior a 24 horas se conserva, sin servirse, hasta instalar una clave.
• A petición, el código puede revisarse bajo NDA, y nos comprometemos a publicar el resumen de un pentest externo en kubelatch.com/es/security.