Preguntas frecuentes
Incluidas las que no nos dejan en buen lugar. Si algo está desactualizado o falta una respuesta, abra una issue y se corregirá en abierto.
Producto y alcance
¿Qué hace Attestkeep exactamente?
Escanea en busca de vulnerabilidades las images que ejecuta su cluster, verifica sus firmas y attestations, decide qué acepta el admission webhook y guarda un registro de auditoría de cada decisión, excepción y break-glass. El operator, su API, su consola y su base de datos se instalan en un namespace de su propiedad.
¿Qué no hace?
No es un sensor runtime. No vigila por sí mismo syscalls, flujos de red ni árboles de procesos dentro de un container en ejecución; si instala Falco, lo hace Falco, y las policies de runtime de Attestkeep deciden qué consecuencia tienen sus eventos. Tampoco es una herramienta de postura cloud: no lee su cuenta del proveedor cloud ni sus políticas IAM.
Lo que hace es más acotado y demostrable: decide qué puede arrancar y guarda el registro de lo que decidió.
¿Sustituye a Kyverno u OPA Gatekeeper?
En seguridad de images coincide con ellos y va más allá: esos motores pueden expresar «rechazar el tag :latest», pero detrás de la regla no tienen un escáner, una caché de CVE ni un verificador de firmas. Attestkeep tiene los tres y aplica las reglas relativas a images desde el mismo almacén de veredictos en el que escribe sus escaneos.
Para todo lo demás que hace un motor de policies (labels, límites de recursos, convenciones de namespaces) siguen siendo la herramienta adecuada, y los dos funcionan uno junto al otro sin conflictos. Hay una respuesta más larga en la página que compara Kyverno y Attestkeep, y lo mismo para Trivy Operator y Sigstore policy-controller.
¿Puede una consola mostrar todos mis clusters a la vez?
No en este release. Cada cluster ejecuta su propio operator con su propia base de datos y su propia consola, y son independientes por diseño: precisamente por eso nada tiene que cruzar la frontera de un cluster. Una vista de flota que resuma muchas instalaciones en una página está en la hoja de ruta, sin fecha; preferimos decirlo antes que anunciar un release cuyo plazo podríamos no cumplir.
¿Funciona en un cluster mixto amd64 / arm64?
El operator en sí, sí: la image del release se construye y firma para ambas. Sin embargo, los veredictos de escaneo se registran hoy para linux/amd64, así que en una image multiarquitectura el hallazgo describe la image amd64 del índice y no la variante que ejecutará un node arm64. Los veredictos por plataforma están en la lista.
¿Qué versiones de Kubernetes se admiten?
Cualquier distribución conforme a partir de la 1.27, incluidos los servicios gestionados, k3s y OpenShift. El operator usa admission webhooks y CRD estándar; no necesita un agente en los nodes, ni un DaemonSet privilegiado, ni un módulo del kernel.
Privacidad y datos
¿Attestkeep nos envía algo?
Tres valores, una vez al día, para la licencia: el identificador de licencia, una huella del cluster y la versión del operator. Nada más, y nada que describa lo que ejecuta: ni nombres de image, ni hallazgos, 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 es que decidamos no enviarlos: es que no hay ningún camino por el que puedan salir. Los límites que su plan fija para images, frameworks y nodes los cuenta y aplica el operator dentro de su propio cluster, así que esas cifras no tienen por qué salir de él. No guardamos ninguna copia de sus hallazgos, de sus nombres de image ni de la forma de su cluster, y una consola de seguridad que necesite la lista de todas las images que usted ejecuta es justo lo que este producto se ha construido para no ser.
Por qué existe el control diario y qué pasa cuando falla está en la página de licencias.
¿Hay telemetría o analítica de uso?
Ninguna. El control diario de licencia no es analítica ni hace sus veces: lleva los tres valores indicados arriba y devuelve un veredicto, y nada en él describe cómo usa usted el producto. Nadie aquí puede saber cuántas images escaneó, qué frameworks abrió o si alguien inició sesión esta semana.
El sitio web tampoco tiene ninguna (ni script de analítica, ni tag manager, ni contenido incrustado de terceros), y por eso el aviso de cookies tiene tan poco que preguntar.
¿Dónde se guardan los resultados y la evidencia?
En una base de datos PostgreSQL que controla usted, en su propio namespace o en su propio servidor. Expórtela, haga copias de seguridad o borre el namespace: no podemos leerla y no guardamos ninguna copia.
¿Qué contiene realmente una notificación?
El nombre de la instalación, la referencia de la image y el veredicto; nunca un nombre de node, una dirección interna ni un endpoint. Las notificaciones van a los canales que usted configure (Slack, Teams, correo, webhook) y a ningún otro sitio.
¿Funciona en un cluster air-gapped?
Sí. El escáner y el verificador de firmas van fijados en la image del release, usted replica la base de datos de vulnerabilidades en su propio registry y el mapeo de cumplimiento viene dentro del operator, así que una instalación desconectada informa lo mismo que una conectada.
La licencia era la parte que antes necesitaba una ruta hacia fuera. Ahora se resuelve con un certificado que usted lleva hasta el cluster: la consola genera una pequeña solicitud de activación que identifica este cluster (la huella, la clave pública del operator, el nombre del cluster y la versión), usted la sube en su página de licencia (en una licencia Enterprise, aceptando antes las condiciones de activación offline) y el certificado que recibe se emite solo para ese cluster. Es válido hasta el final del periodo pagado más treinta días, o doce meses en una licencia sin fecha de fin, y avisa treinta días antes de caducar. Mientras la instalación tenga uno, no hace ninguna llamada de licencia.
La activación offline está disponible en licencias Enterprise anuales a partir del decimoquinto día después de la compra, y en cualquier licencia anual abierta mediante un acuerdo con nosotros. Los pasos están en la guía de instalación. Un cluster que sí tiene ruta hacia fuera sigue el camino más sencillo: una clave de activación y el control diario.
Instalación y operación
¿Tengo que mantener una base de datos?
El chart de Helm trae su propio PostgreSQL o acepta el DSN de una base de datos que ya tenga. Si lo apunta a una base existente, el chart no crea ni base de datos ni volume claim para ella; el único claim que queda es la caché de la base de vulnerabilidades del escáner. En los dos casos, el operator crea y migra sus propias tablas en el primer arranque: no hay SQL que ejecutar ni ningún paso de migración que olvidar al actualizar.
¿Qué pasa si el operator cae?
Por defecto, la failure policy del webhook es Ignore: si el operator no puede responder, los despliegues siguen adelante sin protección en lugar de detenerse. Es el valor seguro para un cluster que tiene que seguir funcionando. Cualquier edición, Community incluida, puede poner Fail y rechazar todo lo que aún no se haya escaneado: un compromiso deliberado, asumido de forma explícita.
¿Es de alta disponibilidad?
La admission está replicada y repartida entre nodes. El trabajo periódico (escaneos, controles de licencia, retención) lo lleva exactamente una réplica a la vez mediante un advisory lock de PostgreSQL, así que una segunda réplica nunca duplica un escaneo ni una notificación.
¿Quién gestiona los certificados TLS del webhook?
El operator. El par de claves se genera y se rota dentro del cluster, y cada réplica adopta el nuevo sin reiniciarse. No depende de cert-manager ni necesita un recordatorio anual en su calendario.
¿Cómo actualizo o desinstalo?
Para actualizar, helm upgrade; las migraciones integradas aplican los pasos nuevos y omiten el resto. Para desinstalar, helm uninstall y después borrar el namespace. El webhook se elimina con el release, así que un operator desinstalado nunca deja la admission bloqueada.
Licencia y facturación
¿Cómo funciona la clave de licencia?
Usted crea una cuenta en attestkeep.com, elige un paquete y los complementos que quiera, y recibe una clave. La introduce en su propia consola, y la activación la cambia por un certificado firmado que recoge lo que compró, el cluster para el que se emitió y la fecha hasta la que es válido. Community Edition funciona igual; su certificado, sencillamente, no caduca.
A partir de ahí, en cada arranque, el operator comprueba el certificado sin salir del cluster: nuestra firma, la caducidad y si la huella que contiene es la de este cluster. Por separado, una vez al día, comprueba la licencia con nosotros. El certificado es válido durante treinta días, así que un fallo del control diario no cambia nada durante mucho tiempo; la página de licencias lo explica todo.
¿Qué pasa cuando caduca la licencia?
La instalación vuelve a Community Edition. No se detiene, no le bloquea el acceso y no empieza a rechazar despliegues: el escaneo y la admission siguen dentro de los límites gratuitos. Un control de seguridad que se apaga solo por una fecha de facturación es peor que una factura impagada.
Un certificado que caduca porque el servidor de licencias lleva un mes inaccesible se comporta igual, y se avisa con mucha antelación: la consola avisa tras una semana sin conexión y los administradores reciben un correo antes de que el certificado caduque.
¿Hay un periodo de prueba?
No hay un periodo de prueba limitado, y es a propósito: Community Edition incluye todas las funciones de seguridad y no caduca, así que cumple el papel de una prueba, en su propio cluster y durante todo el tiempo que quiera. Los planes de pago añaden capacidad y single sign-on, no funciones de seguridad. Cuando una licencia de pago caduca sin renovarse, la instalación vuelve a Community Edition en lugar de apagar nada.
¿Quién gestiona el pago y el IVA?
Los pagos los cobra Polar Software, Inc., nuestro merchant of record, que le revende la licencia: la factura es de Polar, el impuesto que corresponda según su dirección de facturación se calcula y se cobra en el checkout de Polar, y ningún número de tarjeta llega a nosotros. La licencia y el soporte son nuestros. Las empresas de la UE registradas a efectos del IVA lo liquidan ellas mismas por inversión del sujeto pasivo.
¿Puedo usar una clave en más de un cluster?
Sí, hasta el número que paga su plan: eso es justamente el número de clusters de la lista de precios. Community y Team incluyen 1, Business 3 y Enterprise 5. La misma clave activa cada uno y cada activación ocupa un slot; su cuenta muestra qué clusters ocupan slots y cuántos quedan libres.
Por encima de ese número, la siguiente activación se rechaza en lugar de permitirse en silencio. Puede liberar un slot que no use o añadir clusters a la clave que ya tiene sin tocar las instalaciones en marcha.
¿Se cuentan los nodes?
No para facturar: no hay medición por uso ni una factura que cambie con el consumo. Cada plan fija un tope de nodes por cluster: Community 1, Team 6, Business 10 y Enterprise 20. Los nodes adicionales se compran de uno en uno, hasta 50 nodes por cluster en el checkout.
El operator cuenta los nodes Ready dentro del cluster y la cifra no se envía a ninguna parte; el control diario de licencia lleva los mismos tres valores de siempre. Por encima del tope nada se detiene: la consola y una notificación lo avisan e indican una fecha 14 días más adelante. Pasados esos 14 días, solo se rechazan los nombres de image que aún no han aparecido en el periodo, y todo lo ya contado sigue funcionando. Volver por debajo del tope pone el contador a cero.
¿Y si el servidor de licencias no está accesible?
Durante un plazo de entre diez días y un mes no cambia nada, según la vida que le quedara al certificado cuando se perdió la conexión. Los controles fallidos se reintentan a las pocas horas, no al día siguiente, así que una caída tiene que durar semanas para convertirse en un problema de licencia, y la consola avisa tras la primera semana en lugar de dejar que usted se entere más tarde.
Estar inaccesible y ser rechazado son cosas distintas: el silencio consume la vida restante del certificado, mientras que una respuesta que diga que la licencia se ha liberado o revocado se aplica de inmediato.
¿Qué pasa con mi licencia si reconstruyo el cluster?
Reinstalar el operator es gratis: la huella se deriva del cluster, no del operator, así que borrarlo y volver a desplegarlo no requiere nada de nosotros y el certificado sigue funcionando.
Reconstruir el cluster genera una huella nueva, que para la licencia es un cluster nuevo, así que ocupa un slot. Si aún tiene el cluster antiguo, desactívelo allí primero y el slot quedará libre al instante. Si ya no existe, libere su slot desde su cuenta: la entrada muestra cada cluster que ocupa uno y cuándo se activó, para que pueda distinguirlos.
Cumplimiento
¿A qué frameworks se puede mapear el paquete de evidencia?
Hoy, 13 instrumentos: el Cyber Resilience Act (Reglamento (UE) 2024/2847) con NIS2 a su lado, DORA, los Trust Services Criteria de SOC 2, NIST SP 800-190, el SSDF (SP 800-218), una selección de controles de SP 800-53 Rev. 5, ISO/IEC 27001:2022 Annex A, el artículo 32 del RGPD, PCI DSS v4.0.1 Requirements 6 y 11, las MAS Technology Risk Management Guidelines (enero de 2021), el ASD Essential Eight Maturity Model (noviembre de 2023), los Control Criteria de ISMAP (agosto de 2024) y los criterios de certificación ISMS-P (noviembre de 2023).
El mapeo viene dentro del operator en lugar de descargarse, así que un cluster cuya única ruta hacia fuera es el endpoint de licencias produce el mismo documento que uno totalmente conectado. Cada requisito lleva su propia cita y la evaluación que lo respalda; el requisito que un cluster no puede responder se marca fuera de alcance con el motivo, porque un paquete de evidencia que afirma de más vale menos que uno que reconoce sus límites.
La edición gratuita incluye 1 framework a su elección; los planes de pago incluyen más.
¿El paquete de evidencia es una certificación?
No, y así lo dice el propio documento. Es evidencia generada a partir de sus propios registros, y ningún auditor está obligado a aceptarla. Lo que hace es eliminar la fase de la hoja de cálculo: quién aceptó qué riesgo, cuándo y durante cuánto tiempo ya está por escrito.
¿Cuáles son los cuatro estados de control?
met (cumplido), partial (parcial), gap (carencia) y outside_scope (fuera de alcance). Un informe de aprobado o suspenso obliga a cada control a mentir; outside_scope dice que un control no se aplica a un admission controller de Kubernetes, lo que es una respuesta defendible y distinta de suspender. Si el webhook estuvo caído cuarenta minutos un martes, ese intervalo figura en el documento.
Soporte
¿Dónde aviso de un error?
En el tracker público de issues, github.com/attestkeep/attestkeep-docs. Allí se gestionan en abierto los avisos de todas las ediciones, también los de Community Edition: la edición gratuita es de donde vienen la mayoría de los primeros avisos, y cerrarlos en privado sería desaprovecharlos.
¿Cómo aviso de una vulnerabilidad de seguridad?
No en una issue pública. Use la vía de advisory privado que se describe en la página de seguridad, y recibirá un acuse de recibo en un plazo de tres días hábiles. Los problemas corregidos se publican como advisories en el mismo repositorio cuando sale un release con la corrección.
¿Qué soporte incluye cada plan?
Community Edition tiene soporte a través del tracker público de issues, donde también se gestionan los errores de las ediciones de pago: los avisos no se ordenan según lo que usted paga. Los planes de pago añaden soporte por correo y, a partir de Business, su correo se atiende antes que la cola.
No publicamos una garantía de tiempo de respuesta para ningún plan. Una cifra en esta página sería una promesa hecha a todos a la vez por un equipo que no la ha acordado con nadie en concreto, y preferimos responder rápido antes que escribir una cifra que tendríamos que defender en una mala semana.