Una clave funciona en los clusters pagados, y en ninguno más.

Actualizado: 14 de octubre de 2026

Todas las ediciones tienen licencia, también la gratuita

Community Edition recibe una clave y la activa como cualquier otra edición. La diferencia está en la clave, no en el procedimiento: una clave Community no caduca y una de pago sí.

No es una cuestión de contabilidad. Todo lo que una instalación puede hacer está en el certificado que recibió: sus funciones, su cupo mensual de nombres de image, su número de frameworks y de clusters. Una instalación sin certificado no es una instalación gratuita; es una instalación sin respuesta a esa pregunta, y la única forma de atenderla sería suponer una respuesta. Una suposición no se puede contar, ni vincular a un cluster, ni retirar. Por eso no existe un modo sin licencia: la edición gratuita es gratuita por lo que dice su clave, no porque le falte una.

Conseguirla requiere los mismos tres pasos en los dos casos. Cree una cuenta en attestkeep.com, tome la clave gratuita o compre el plan que quiera, y luego introduzca esa clave en su propia consola. No hace falta nada más antes: ninguna llamada comercial para acceder a la edición gratuita, ningún formulario antes de instalar.

A qué se vincula una clave

La activación es un intercambio único por cluster. La instalación envía su clave de activación y una huella del cluster en el que funciona; vinculamos la clave a esa huella y devolvemos un certificado firmado que lleva la huella dentro.

Una clave se vincula a tantos clusters como paga el plan. Community y Team incluyen 1, Business 3 y Enterprise 5; los slots adicionales se compran en el checkout hasta 10 clusters, y por encima de 10 se necesita un acuerdo a medida. Si intenta activar un cuarto cluster con una clave de tres, la activación se rechaza, y el rechazo indica cuál de los dos casos se da: se ha quedado sin clusters y puede comprar otro, o uno de los tres es un cluster que ya no tiene y puede liberarlo.

A partir de ahí, en cada arranque, el operator comprueba tres cosas sin que nada salga del cluster: que la firma es nuestra, que el certificado no ha caducado y que la huella que contiene coincide con el cluster en el que realmente se ejecuta. Un certificado copiado a un cluster para el que no se emitió falla en la tercera comprobación, en local y offline, sin consultarnos. El vínculo no es una consulta que hagamos a petición; forma parte de lo que firmamos.

La huella es un hash del identificador del namespace kube-system de su cluster. Nace con el cluster y no cambia en toda su vida. Borrar y reinstalar el operator no la cambia, así que una reinstalación no necesita nada de nosotros. Montar un cluster nuevo sí la cambia, y de eso trata la sección sobre mover una licencia.

Su cupo de clusters, y lo que queda de él

Una clave lleva un cupo en lugar de un único vínculo, y cada activación gasta un slot. Compre tres clusters: la primera instalación deja dos, la segunda uno, la tercera ninguno. Siempre la misma clave, sin una segunda que vigilar.

Lo que queda no tiene que recordarlo. Su cuenta muestra la clave, los clusters que ocupan sus slots con la fecha de activación de cada uno y el número de slots libres; el operator muestra lo mismo en su propia pantalla de licencia en cuanto se activa. Quedarse sin cupo no es un error. Tiene dos respuestas normales: liberar un slot que no usa o añadir uno.

Puede añadir clusters a una clave que ya tiene, desde su cuenta, sin tocar las instalaciones en marcha. El cupo sube y el siguiente control diario lo detecta: un cambio en lo que compró es una de las cosas que provocan la emisión de un certificado nuevo, de modo que en un día cada cluster lleva la nueva cifra por sí solo.

Por qué solo el número de clusters nos necesita

Su cupo mensual de nombres de image y su número de frameworks los cuenta el operator dentro de su propio cluster, porque todo lo que cuentan ocurre allí. Para eso no hacemos falta y no se envía nada al respecto. Con el tope de nodes pasa lo mismo: va en el certificado y se comprueba dentro del cluster frente a su propio recuento de nodes Ready.

El número de clusters es de otra naturaleza. Un operator que funciona en un cluster no tiene forma de saber que la misma clave funciona también en otros dos. Dentro de un cluster no hay ningún punto desde el que ver los demás. El único lugar que puede guardar esa cifra es el lado que emitió la clave y conserva los vínculos.

Así que el control diario no es una formalidad alrededor de una licencia que se sostendría sin él. Es lo que respalda una línea que de verdad vendemos; la alternativa sería poner en la lista de precios un número de clusters que nada hace cumplir. Un cluster que recibe un certificado offline en lugar de pasar el control gasta su slot en el momento en que se emite ese certificado: es la misma cifra, guardada en el mismo lado.

El control diario

Una vez al día, una instalación conectada comprueba su licencia con nosotros, y recibe un certificado nuevo cuando algo ha cambiado o el que tiene está a punto de caducar. No es algo que se pueda desactivar por configuración: no hay ningún ajuste para ello, ni en el chart ni en otro sitio. Una licencia a la que se le puede decir que deje de comprobar la aplica quien la instaló, y eso no es aplicarla. La única instalación que nunca comprueba es la que tiene un certificado offline, y eso tampoco es un ajuste: lo emitimos nosotros, ante una solicitud que vimos, para un cluster cuyo slot consumió.

El control envía tres valores y ninguno más:

• el identificador de licencia,
• la huella del cluster descrita arriba,
• la versión del operator.

No envía nombres de image, ni hallazgos de escaneo, ni identificadores CVE, ni nombres de workloads o namespaces, ni topología del cluster, ni cuentas de usuario, ni nada de su base de datos. No puede: los límites de images y frameworks se cuentan dentro de su cluster, así que esas cifras no tienen motivo para salir y no hay ningún camino de código que las lleve. Lo que viaja basta para responder una sola pregunta: ¿sigue teniendo esta licencia derecho a funcionar en este cluster? Nada de ello respondería una segunda.

Los campos exactos, cuánto tiempo los guardamos y con qué base legal están en el aviso de privacidad.

Usted compra un año; el certificado dura un mes

Los planes se venden por meses o por años. El certificado de una instalación conectada nunca dura tanto: vale treinta días como máximo y se sustituye por uno nuevo mucho antes de que caduque. Su suscripción no cambia en nada. La fecha de la factura es la que pagó; el certificado se renueva en silencio por debajo. El certificado offline es la excepción y cubre todo el periodo, porque detrás no viene nada que lo renueve.

El control diario y el certificado son dos cosas distintas, y solo una ocurre cada día. El control hace una pregunta y casi siempre recibe «sigue siendo válida», lo que no cambia nada ni cuesta nada. Se emite un certificado nuevo en dos casos: cuando algo ha cambiado de verdad (ha añadido clusters, liberado uno, renovado, cancelado) o cuando al que tiene le quedan menos de diez días. Así, una instalación nunca tiene menos de unos diez días de margen ni más de treinta, y nadie firma y guarda un certificado nuevo cada mañana sin motivo.

El techo es de treinta días porque un certificado firmado es una promesa que no podemos retirar. Si escribiéramos un año, habríamos regalado un año: una cancelación, un reembolso, un contracargo o una licencia trasladada a otro cluster tendrían que esperar a que acabara ese año para tener efecto. Treinta días es el tiempo máximo que aceptamos pasar sin poder cambiar de opinión. También es lo máximo que puede estar desconectado. No es casualidad: es la misma cifra vista desde dos lados.

Cerca del final del periodo, el certificado nunca va más allá de la suscripción a la que pertenece. El último se acorta para terminar con su año, de modo que una licencia nunca sobrevive a lo que la pagó. Renueve y el siguiente control restablece los treinta días completos.

Cuando no puede contactarnos, y cuando nunca lo hará

Detrás de una misma frase hay dos situaciones: un cluster que perdió su ruta durante un tiempo y un cluster que nunca iba a tenerla. Tienen respuestas distintas.

Un cluster que normalmente está conectado. Durante un plazo de entre diez días y un mes no pasa nada, según la vida que le quedara al certificado cuando se perdió la conexión. Un control fallido se reintenta a las pocas horas en lugar de esperar al día siguiente, así que una ventana de mantenimiento, un cambio de firewall o una tarde de mal enrutamiento nunca llegan a la instalación como un evento de licencia. Tampoco dos semanas de cortes así.

Tampoco falla en silencio. Tras una semana sin ruta hacia nosotros, la consola lo indica y hace la cuenta atrás de los días restantes; antes de que caduque el certificado, los administradores reciben un correo. Nadie debería enterarse al notar que falta una función.

Pasados treinta días, el certificado caduca y una instalación de pago vuelve a Community Edition: el escaneo, la verificación de firmas, el admission control y la evidencia continúan dentro de los límites gratuitos. No se detiene, no le bloquea el acceso y no empieza a rechazar despliegues. Una instalación Community no se ve afectada, porque su certificado no caduca.

Estar inaccesible y ser rechazado son estados distintos, y la instalación los trata de forma distinta. El silencio consume los treinta días. Una respuesta que diga que la licencia se ha liberado o revocado se aplica de inmediato, porque en ese caso sí hubo contacto y la respuesta fue no.

Un cluster sin ninguna ruta hacia fuera. Se activa a mano una vez y después queda con licencia sin hablar nunca con nosotros. La consola genera una pequeña solicitud de activación que identifica el cluster: su huella, la clave pública que el operator generó dentro, el nombre del cluster y la versión del operator. En su página de licencia sube ese archivo y descarga el certificado emitido para él; en una licencia Enterprise acepta antes allí las condiciones de activación offline, y en una licencia abierta mediante un acuerdo ese paso ya está hecho. Es el mismo documento firmado que devuelve el camino online, para ese único cluster, con un campo más que indica que su modo es offline.

Ese certificado vale hasta el final del periodo pagado más treinta días, y doce meses desde su emisión en una licencia sin fecha de fin. Una instalación que lo tiene no hace ninguna llamada de licencia (ni activación, ni control diario, ni renovación), así que no queda nada que bloquear. Treinta días antes de que caduque, la instalación emite su aviso de licencia a punto de caducar e indica que hay que obtener uno nuevo; pasada esa fecha vuelve a Community Edition como cualquier licencia caducada, y una licencia renovada necesita un certificado nuevo.

Un certificado que no podemos retirar tampoco lo podemos liberar, así que el slot que ocupa lo libera nuestro equipo de soporte, no su cuenta, y Deactivate en la consola solo quita el certificado del cluster donde está. La activación offline está disponible en licencias Enterprise anuales a partir del decimoquinto día tras la compra, y en cualquier licencia anual abierta mediante un acuerdo con nosotros; las licencias Community, Team y Business compradas en el checkout no la tienen. Los pasos están en la guía de instalación.

Mover una licencia a otro cluster

Cuando todos los clusters que paga un plan están vinculados, el siguiente se rechaza con un mensaje que dice cuál es su problema en lugar de un fallo genérico: esta licencia ya está activa en otro cluster y, para usarla aquí, primero hay que liberar aquel. El rechazo nombra los clusters que ocupan los slots y cuándo se activó cada uno, de modo que «¿cuál es el viejo?» es una pregunta que puede responder.

Desde el cluster antiguo. Ejecute Deactivate allí: el slot se libera al instante, el certificado local se borra y el cluster nuevo puede tomarlo enseguida. Es el camino limpio y el que debe usar mientras el cluster antiguo siga existiendo.

Desde su cuenta. Si el cluster antiguo ya no existe de verdad (borrado, reconstruido, perdido con el hardware), libere su slot desde su cuenta y el cluster nuevo podrá tomarlo.

Hay algo que esto no hace. Si el cluster antiguo sigue existiendo y funcionando, liberarlo en su cuenta no llega hasta él ni lo apaga. Nada puede hacerlo: tiene un certificado que se verifica offline. Lo que ya no puede hacer es renovar. Su certificado caduca en un plazo de treinta días, normalmente antes, y esa instalación vuelve por sí sola a Community Edition.

Esa ventana es limitada y conocida, no abierta, y cada liberación queda registrada. Liberar la misma licencia una y otra vez se ve desde nuestro lado, y es el tipo de patrón por el que preguntaremos.

Fin de una licencia

La caducidad y la cancelación se comportan como un certificado caducado: la instalación vuelve a Community Edition y sigue funcionando dentro de los límites gratuitos. No hay ningún corte brusco. El admission control no se detiene y no se le quita nada de lo que ya haya escaneado o registrado.

Cancelar a mitad de periodo no apaga nada el día en que cancela. Conserva lo que pagó hasta que termina el periodo, porque eso es lo que pagó; el certificado simplemente deja de renovarse después de esa fecha.

Todas las funciones de seguridad están en la edición gratuita. Lo que compra una clave de pago es escala y single sign-on, y la comparativa detalla qué incluye cada plan.