Organización y personas
Política de seguridad, roles, habilitaciones y formación del personal. OpenKeel proporciona roles nominativos y el registro de auditoría de sus acciones.
OpenKeel: la solución Cloud soberana, francesa y de alcance europeo, del grupo inherent Descubrir inherent
Arquitectura
OpenKeel está diseñado para ser SecNumCloud-ready: lo que es conforme hoy, lo que está en curso y lo que queda por evolucionar, requisito por requisito, cada uno con su evidencia en el código.
SecNumCloud (ANSSI, marco 3.2) cualifica un servicio operado por un proveedor, no un software. El marco abarca la organización, los recursos humanos, la seguridad física, las operaciones, la gestión de incidentes y la protección frente al derecho extraeuropeo (§ 19.6) tanto como la técnica.
Por tanto, OpenKeel no puede estar «cualificado SecNumCloud». Aspira a ser una base SecNumCloud-ready: un software que no bloquea ningún requisito técnico del marco, que proporciona los mecanismos esperados (trazabilidad, segregación, cifrado, autenticación robusta) y la documentación que permite al proveedor demostrar la conformidad durante la auditoría.
Contabilizado a partir de las tablas siguientes; la parte del proveedor se indica aparte.
Una PKI interna gestionada por cert-manager (emisor openkeel-ca) firma los certificados de los servicios; la CA del operador de MariaDB firma los de la base de datos. Cada servicio verifica el servidor con el que habla.
| Flujo | Protocolo | Confianza |
|---|---|---|
| Clientes → Ingress → API | HTTPS, recifrado hacia backends HTTPS (Skyline, consola de Nova, wsproxy de Zun) | Certificado público; certificados internos de cert-manager |
| API ↔ API | REST sobre HTTPS, URL internas https en el catálogo | PKI interna, emisor de cert-manager openkeel-ca |
| Servicios → MariaDB | SQL sobre TLS, exigido por el servidor | CA del operador de MariaDB, verificada por cada servicio |
| Servicios → RabbitMQ | AMQPS (RPC y notificaciones) | PKI interna openkeel-ca |
| Neutron → OVN NB/SB | OVSDB sobre ssl:, TLS mutuo | Certificados de cliente y servidor de OVN |
Ya no hay Memcached ni Redis: ningún componente los leía, y okadm los retira de las instalaciones existentes. Solo los puertos de administración :9090 (salud, métricas), la distribución Erlang entre los nodos de RabbitMQ y la pasarela RGW de --ceph-s3 transportan aún tráfico en claro dentro del clúster. Toda la tabla está en el código (global.tls.internal, activado por defecto) y se verificó en el laboratorio el 2026-11-08.
Toda imagen que ejecuta un clúster de producción procede del registro del proveedor: las de OpenKeel, construidas desde el espacio de trabajo, y las de terceros, copiadas allí con su SBOM. Ambas se firman con la clave del proveedor.
| Imágenes | Registro | SBOM y procedencia | Firma |
|---|---|---|---|
Servicios de OpenKeel, okadm, sitio web | Construidas por make release y subidas a REGISTRY; los charts apuntan a él (global.imageRegistry) | SBOM SPDX por plataforma y procedencia SLSA, adjuntados por BuildKit en el índice de la imagen; exportados por make sbom | cosign, por digest del índice (make sign), atestaciones incluidas |
Binarios okadm | Archivos de versión en dist/cli, con SHA256SUMS | SBOM SPDX por binario (syft) | Sumas de verificación |
| Requisitos previos: cert-manager, operadores de MariaDB y RabbitMQ, MariaDB, RabbitMQ, Traefik | Copiadas de registro a registro por make mirror-prereqs, todas las plataformas, un prefijo por registro de origen | El SBOM del editor cuando la copia lo conserva; si no, un SBOM de syft adjuntado con cosign attest (MIRROR_SBOM=1) | Cada copia firmada con la clave de OpenKeel |
| Ironic (imágenes Kolla de origen) | Fijadas por digest en el manifiesto de versión de okadm, descargadas a través de global.imageRegistry | A través del espejo (MIRROR_EXTRA_IMAGES) | A través del espejo |
El clúster descarga del espejo sin cambiar ningún chart: un hosts.toml por registro de origen para containerd, machine.registries.mirrors en Talos. Ninguna firma, SBOM ni digest de imagen se envía a los servicios públicos de Sigstore (build/cosign/signing-config-private.json). Fuente: BUILD.md.
Hecho en el código y en los charts, o documentado para el proveedor.
| Requisito | SecNumCloud 3.2 | Estado | Evidencia | Siguiente paso |
|---|---|---|---|---|
| Control del código, sin dependencia de un fabricante no europeo | § 19 | Hecho | Reescritura open source en Go de Keystone, Nova, Neutron, Cinder, Glance, Manila, Barbican… (openkeel-*); sin telemetría, sin llamadas salientes a terceros | Reconstruir las imágenes en una CI europea |
| Registro de las acciones de API | cap. 12 | Hecho | Un evento CADF por llamada en todas las API (internal/audit), eventos de identidad de Keystone (internal/notify), contadores openkeel_audit_events_{sent,dropped,failed}_total | Añadir kube-apiserver y la API de Talos al registro de auditoría |
| Conservación e integridad de los logs | cap. 12 | Hecho | Documentado en openkeel-chart/docs/audit-trail.md: archivo WORM (object lock, modo compliance), 12 meses con 3 en línea (Loki 400 d), NTP en los nodos Talos, alertas ante pérdidas, reglas SIEM | Demostrarlo en una plataforma real (proveedor) |
| Control de acceso a las API | cap. 9 | Hecho | Políticas RBAC de OpenStack (admin, member, reader, service, ámbitos de proyecto y de sistema) aplicadas por cada servicio; rechazos 403 como en OpenStack, cubiertos por las pruebas de conformidad | Reducir las cuentas de servicio con privilegios excesivos |
| Gestión de secretos y claves | cap. 10 | Hecho | Barbican en Go con un HSM PKCS#11 (internal/crypto/p11.go, pruebas con SoftHSM) o Vault / OpenBao; rotación de la KEK (internal/manage/rotate.go) | HSM cualificado por la ANSSI en producción |
| Aislamiento de los contenedores de los tenants | cap. 13 | Hecho | Zun con Kata Containers por defecto (RuntimeClass kata): un kernel por contenedor de tenant | — |
| Cifrado del plano de control de la red | cap. 10, 13 | Hecho | OVN Northbound / Southbound en TLS mutuo (ssl:) entre Neutron, ovn-octavia-provider, FWaaS, VPNaaS, ovn-bgp-agent y OVN central | — |
| Las API opcionales pueden desactivarse | cap. 13 | Hecho | ec2-api puede desactivarse en el Configurator (componente ec2-api de su catálogo) | — |
| Autenticación multifactor | cap. 9 | Hecho | Keystone: método TOTP (internal/keystone/totp.go) y reglas MFA por usuario (options.multi_factor_auth_rules, internal/api/mfa_test.go) | Federación OIDC |
| Cifrado de los flujos de base de datos | cap. 10 | Hecho | MariaDB con TLS obligatorio (infrastructure.mariadb.tls.required: true), la CA del operador MariaDB verificada por cada servicio (global.tls.trustedCAs, que okadm pasa a cada release), tls=skip-verify rechazado; aplicado y verificado en el laboratorio (require_secure_transport en ON) | Comprobar la replicación de Galera en TLS en un clúster de tres nodos (el laboratorio solo tiene uno) |
| Suites TLS de los listeners | cap. 10 | Hecho | internal/tlsx en los 16 servicios (una copia del de Keystone): TLS 1.2 como mínimo, solo ECDHE con AES-GCM o ChaCha20 (guía TLS de la ANSSI), certificado releído al renovarse; RabbitMQ limitado a TLS 1.2/1.3 y suites AEAD | — |
| Menor superficie de ataque: ningún servicio de datos sin uso | cap. 13 | Hecho | Memcached y Redis eliminados: ningún componente los leía; okadm los elimina de las instalaciones existentes (internal/deploy/retired.go) | — |
| Cifrado de todos los flujos internos | cap. 10 | Hecho | global.tls.internal: true por defecto: CA interna de cert-manager (openkeel-ca), un certificado por chart (ECDSA P-256, 90 días); RabbitMQ solo en AMQPS; URL internas y catálogo interno en https://; Ingress hacia backends HTTPS verificados (Traefik ServersTransport, anotaciones de nginx); paso de okadm rabbitmq-trust; informes de estado de ovn-octavia-provider hacia un punto de escucha TLS dedicado de Neutron (openkeel-neutron-lbaas:9878, fuera del puerto de administración). Verificado en el laboratorio el 2026-11-08: 18 puntos de escucha en HTTPS con certificado verificado, HTTP en claro rechazado, conexiones AMQP en TLS 1.3 | Captura de red: ningún flujo de aplicación en claro fuera de :9090 |
| Integridad y trazabilidad de las imágenes de OpenKeel | cap. 14 | Hecho | Cada imagen construida con --sbom=true --provenance=mode=max (ATTEST=1, por defecto): un SBOM SPDX por plataforma (paquetes Debian de la base distroless, cada módulo Go) y la procedencia SLSA en el índice de la imagen; make sbom los exporta a dist/sbom, con el SBOM de cada binario okadm; make sign firma cada índice por digest con cosign, lo que cubre sus atestaciones (build/sbom.sh, BUILD.md) | Imponer las firmas en la admisión |
| Imágenes de terceros en un registro controlado, con un SBOM | cap. 14 | Hecho | make mirror-prereqs copia las imágenes de los requisitos previos (cert-manager, operadores de MariaDB y RabbitMQ, MariaDB, RabbitMQ, Traefik: 14 imágenes) de registro a registro, todas las plataformas, según el manifiesto de versión de okadm; containerd o Talos redirigen cada registro de origen al espejo; MIRROR_SBOM=1 exporta un SBOM por copia, adjunta uno con cosign attest cuando el editor no lo proporciona y firma cada copia con la clave de OpenKeel; las imágenes de OpenKeel y las de Ironic, fijadas por digest, se descargan a través de global.imageRegistry | Replicar las imágenes que KubeVirt y CDI determinan en tiempo de ejecución |
Los números de capítulo orientan la lectura; deben contrastarse con el marco publicado antes de elaborar la matriz de conformidad. Fuente: openkeel-docs/SECNUMCLOUD-STATUS.md.
| Requisito | SecNumCloud 3.2 | Estado | Evidencia | Siguiente paso |
|---|---|---|---|---|
| Suites TLS uniformes | cap. 10 | En curso | Servicios (tlsx) y RabbitMQ alineados; queda el lado público de los controladores de Ingress | Perfil TLS de la ANSSI en los puntos de entrada públicos del Ingress |
| Charts coherentes | — | En curso | Conflicto de nombres del helper svc.volumes entre sub-charts (montaje de las CA de confianza) | Prefijar los helpers por chart |
| Imágenes construidas y controladas por el proveedor | cap. 14 | En curso | make release construye cada imagen multiarquitectura desde el espacio de trabajo (distroless sin root, UID 65532, sin shell) con su SBOM, su procedencia y su firma; la configuración de firma por defecto no usa ninguno de los servicios públicos de Sigstore (build/cosign/); Ironic aún usa las imágenes Kolla (Python) de origen, replicadas por digest | Ejecutar make release en una CI europea; sustituir las imágenes Kolla |
| Vigilancia de vulnerabilidades de las imágenes | cap. 14 | En curso | make vuln (govulncheck, go mod verify) en cada módulo Go; los SBOM de las imágenes de OpenKeel y de terceros se analizan sin volver a descargar las imágenes (grype, trivy sbom) | Analizar los SBOM en cada versión y periódicamente en busca de nuevas CVE |
| Requisito | SecNumCloud 3.2 | Estado | Evidencia | Siguiente paso |
|---|---|---|---|---|
| MFA de los administradores a través de un IdP | cap. 9 | Pendiente | Solo TOTP local | Federación OIDC en Keystone (IdP europeo, MFA a cargo del IdP), asociada a roles |
| MFA para los administradores de Kubernetes | cap. 9 | Pendiente | Acceso por kubeconfig con un certificado de cliente (okadm access) | OIDC y MFA en el kube-apiserver, roles de Kubernetes nominativos, sin cluster-admin permanente |
| Configurator autenticado | cap. 9 | Pendiente | UI sin inicio de sesión; su ClusterRole modifica los nodos y lee todos los logs (deploy/kustomize/base/rbac.yaml) | Autenticación OIDC, una ClusterRole más reducida, acceso solo desde el SI de administración |
| Cuentas de servicio mínimas | cap. 9 | Pendiente | Rol admin para ec2-api (all_tenants), Masakari, Zun (binding:host_id), Skyline y neutron-vpnaas; openstack-exporter con la contraseña de admin | Roles dedicados y reglas de política específicas por servicio; un exporter de solo lectura (reader de sistema) |
| Requisito | SecNumCloud 3.2 | Estado | Evidencia | Siguiente paso |
|---|---|---|---|---|
| Una clave por tenant para los volúmenes | cap. 10 | Pendiente | Cinder registra la clave fija 00000000-0000-0000-0000-000000000000 y deja el cifrado a la StorageClass | Vincular Cinder a Barbican: una clave por volumen cifrado, en el proyecto del tenant |
| Cifrado de discos | cap. 10 | Pendiente | — | Longhorn LUKS por volumen; cifrado de MariaDB, Glance y Swift |
| Borrado al final del contrato | cap. 19 | Pendiente | — | Borrado criptográfico: destruir las claves Barbican del proyecto, con un procedimiento trazado |
| Ningún algoritmo obsoleto | cap. 10 | Pendiente | Firmas EC2 v0/v1 en HMAC-SHA1 aceptadas por Keystone (internal/keystone/ec2sign.go) | Una opción para aceptar solo v2 (SHA-256) y v4, con las antiguas desactivadas por defecto en producción |
| HSM cualificado | cap. 10 | Pendiente | PKCS#11 genérico probado con SoftHSM | Validar con un HSM cualificado por la ANSSI |
| Requisito | SecNumCloud 3.2 | Estado | Evidencia | Siguiente paso |
|---|---|---|---|---|
| Firmas impuestas en la admisión | cap. 14 | Pendiente | Imágenes firmadas y atestadas, pero el clúster ejecuta cualquier imagen | Kyverno verifyImages o el policy-controller de Sigstore con cosign.pub, tanto para las imágenes de OpenKeel como para las de los operadores |
| Requisito | SecNumCloud 3.2 | Estado | Evidencia | Siguiente paso |
|---|---|---|---|---|
| SI de administración separado | cap. 9, 13; PA-022 | Pendiente | Una propuesta escrita: zonas Z1, Z2 y Z3 (openkeel-docs/SECNUMCLOUD-ADMIN-SI.md) | Red de administración, bastión, puestos de administración (proveedor) |
| Plano de control separado del plano de datos | cap. 13 | Pendiente | Un único clúster Talos aloja las API y las cargas de trabajo de los tenants | Etapa 1: refuerzo del clúster único, agentes de Nova y Zun centralizados (sin DSN en los hipervisores); objetivo: clústeres de control y de datos separados |
| Registro de la administración de la plataforma | cap. 12 | Pendiente | Solo se trazan las API de OpenStack | Política de auditoría del kube-apiserver, logs de la API de Talos, del bastión y de los BMC, archivados como el registro CADF |
| Puertos de administración cifrados | cap. 10 | Pendiente | Salud y métricas en :9090 en HTTP en claro, dentro del clúster; los informes de estado de ovn-octavia-provider ya no pasan por ahí: Neutron los recibe en un punto de escucha TLS dedicado | TLS (o mTLS de Prometheus) en :9090, o una NetworkPolicy que solo deje entrar a Prometheus |
| Sin soporte remoto no europeo | § 19.6 | Pendiente | Soporte remoto de las cabinas de almacenamiento (Pure1, acceso remoto del fabricante) no desactivado por OpenKeel | Documentarlo y comprobar que está desactivado en la guía de instalación de producción |
| Distribución Erlang de RabbitMQ | cap. 10 | Pendiente | Tráfico entre los nodos de RabbitMQ (puerto 25672) sin cifrar, dentro del clúster | TLS para la distribución Erlang (ssl_dist), que el operador no gestiona |
Pasarela RGW (--ceph-s3) | cap. 10 | Pendiente | RGW llega a Keystone en HTTPS verificado (caBundleRef), pero sirve S3 y Swift en HTTP en claro en el puerto 80 dentro del clúster | Puerto seguro de RGW con un certificado de la CA interna |
| Llamadas de okadm a las API | cap. 10 | Pendiente | A través del proxy de servicios del servidor de API de Kubernetes en https:: cifrado, sin verificar los certificados de los pods | Llamar a través del Ingress, o verificar en el lado del cliente |
Las API de OpenKeel forman parte del servicio vendido a los tenants: no son el SI de administración. Por ello, la propuesta separa tres zonas, y las interfaces de administración de Z2 y Z3 (kube-apiserver, API de Talos, BMC, etcd, puertos de administración) solo son accesibles desde Z1.
| Zona | Contenido | Quién accede |
|---|---|---|
| Z1, SI de administración | Puestos de administración, bastión, IdP de los administradores (MFA), runner de okadm y repositorio Git de los values, Configurator, recogida y almacenamiento de los logs (Loki, SIEM, bucket WORM), réplica firmada del registro | Solo los administradores, desde sus puestos |
| Z2, plano de control del servicio | API de OpenKeel, conductors, schedulers, MariaDB, RabbitMQ, Barbican, Ingress público | Tenants (API públicas a través del Ingress); administradores a través de Z1 |
| Z3, plano de datos | Hipervisores (KubeVirt), nodos Zun (Kata), almacenamiento (Longhorn), pasarelas de red (OVN gateway, BGP) | Tenants (sus VM y contenedores); administradores a través de Z1 |
Recomendación de la propuesta: una red de administración y un clúster único reforzado desde ahora, en todo despliegue de producción; agentes de Nova y Zun centralizados como primer desarrollo; clústeres de control y de datos separados como objetivo para una oferta cualificada. Nada de ello está implementado todavía.
Terminar TLS en todos los flujos internos y comprobarlo después con una captura de red.
OIDC y MFA para los administradores, cifrado en reposo con una clave por tenant.
Imágenes construidas en una CI europea, firmas impuestas en la admisión, el SI de administración y la separación de los planos.
La matriz de requisitos, una revisión interna y después una preauditoría por un auditor cualificado.
La mayor parte del marco concierne al proveedor que opera el servicio. OpenKeel no lo sustituye, pero no debe obstaculizarlo, y aporta parte de las evidencias.
Política de seguridad, roles, habilitaciones y formación del personal. OpenKeel proporciona roles nominativos y el registro de auditoría de sus acciones.
Centros de datos, control de acceso a las salas y al hardware. OpenKeel se ejecuta en los propios servidores del proveedor, en Francia y en Europa.
Cambios, copias de seguridad, gestión de vulnerabilidades y de capacidad. okadm planifica, instala y actualiza un componente cada vez; Grafana muestra el estado de cada servicio.
Detección, tratamiento y notificación de incidentes. El registro CADF, Loki y las alertas de Prometheus aportan los hechos.
§ 19.6: propiedad, ubicación de los datos y soporte en la Unión Europea. OpenKeel es open source, sin telemetría y sin llamadas salientes.
Configuraciones, políticas y logs reunidos en la matriz de conformidad, versionados con el código.
| Paso | Qué | Resultado |
|---|---|---|
| Matriz de requisitos | SecNumCloud 3.2 capítulo por capítulo: responsable (OpenKeel o proveedor), mecanismo, prueba | Matriz de conformidad versionada con el código |
| Revisión interna | Cada prueba verificada en una instalación en modo producción | Informe de revisión, brechas abiertas en seguimiento |
| Preauditoría | Auditor cualificado, sobre una plataforma piloto completa | Informe de preauditoría y plan de tratamiento |
| Prueba de intrusión PASSI | API públicas, escape de VM y de Kata hacia el plano de control, SI de administración | Informe, correcciones y nueva prueba |
| CSPN (opcional) | Componentes críticos: Keystone, Barbican, aislamiento de Kata y KubeVirt | Certificación de primer nivel de los componentes elegidos |