OpenKeel implementation in Go of OpenStack Barbican (key manager), generated from the reverse-specification of branch stable/2026.2 by the generate-go-from-spec skill. It replaces the Python service without its clients noticing: same routes, status codes, error bodies, microversions and policies. What is reproduced and what differs is in docs/CONFORMANCE.md; the security checklist is in docs/SECURITY.md.
Go module: github.com/openkeel/openkeel-barbican
Binaries (one image holds all four): | Binary | Replaces | Role | |---|---|---| | barbican-api | barbican-wsgi-api | REST API on port 9311, health and metrics on 9090; -migrate applies the schema | | barbican-worker | barbican-worker | processes orders (key and asymmetric generation) from RabbitMQ, oslo.messaging wire format | | barbican-keystone-listener | barbican-keystone-listener | deletes a project's resources on Keystone's identity.project.deleted notification | | barbican-manage | barbican-manage | db upgrade/clean/sync_secret_stores, simple_crypto rewrap_pkek/new_pkek/rewrap_secrets, hsm gen_mkek/check_mkek/gen_hmac/check_hmac/rewrap_pkek | barbican-retry is not ported (no retry is ever scheduled on this branch, CONFORMANCE.md).
Secret stores: simple_crypto (Fernet, master KEK file), p11_crypto (PKCS#11 HSM, cgo build only, below), vault_plugin (Vault or OpenBao KV v1/v2). The database is shareable with Python Barbican (Alembic head 8c74e2d7f1ff).
Configuration: YAML, see config/config.example.yaml
Setting up a development environment, the database and the tests: docs/GETTING-STARTED.md
Database schema, migrations and upgrades: docs/DATABASE.md
Extracto de openkeel-barbican/README.md (en inglés).
API REST
57 operaciones de la API REST original (rutas y acciones de cuerpo) y su estado en OpenKeel.
Barbican se verifica mediante replay, con sus propios tests funcionales, enviando las mismas peticiones a Python y a Go, y ejecutando ambos en paralelo sobre una misma base de datos y un mismo bus.
Replay de los intercambios grabados
Replay E2E de los intercambios funcionales
Los intercambios funcionales grabados dan las mismas respuestas desde el servicio Go.
Ejecución
make e2e-strict en el motor integrado y en MariaDB 11.4.
Último resultado 2 766 / 2 792 iguales, 26 diferencias conocidas (claves aleatorias, fechas grabadas, base de datos compartida); todos se superan en vivo.
Fuente: openkeel-barbican/docs/CONFORMANCE.md
Contrato de cliente
functionaltests de Barbican sobre Go
Los functionaltests/ upstream de Barbican se superan contra el servicio Go con un Keystone real.
Ejecución
test/functional/run_functional.py --target go a través del adaptador de conformidad.
Último resultado 563 ok, 0 fallos, 69 omitidos.
Fuente: openkeel-barbican/docs/CONFORMANCE.md
Test diferencial
Sonda diferencial Python vs Go
Las mismas peticiones enviadas a Barbican en Python y en Go, que comparten un mismo Keystone, obtienen las mismas respuestas.
Ejecución
test/functional/diff_probe.py, y --new-defaults para los valores por defecto de RBAC.
Se reproducen todas las decisiones de políticas de oslo.policy y el formato de almacenamiento cifrado de Barbican en Python.
Ejecución
make test sobre policy-vectors.json.gz y los vectores simple_crypto y p11_crypto.
Último resultado Políticas 40 704 / 40 704; simple_crypto 25 / 25; p11_crypto 8 / 8 emulados, 4 / 8 en SoftHSM 2. Ningún HSM real probado.
Fuente: openkeel-barbican/docs/CONFORMANCE.md
Test diferencial
Python y Go en paralelo
Python y Go comparten una misma MariaDB y un mismo RabbitMQ: lecturas cruzadas de cada tipo de secreto, órdenes en ambos sentidos, barbicanclient, castellan y openstack secret.
Ejecución
test/functional/interop.py; test/amqp/run.sh con oslo.messaging sobre RabbitMQ 3.13 y 4.4.
Último resultado Interop 75 / 75; AMQP 3 / 3.
Fuente: openkeel-barbican/docs/CONFORMANCE.md
Concurrencia en Galera
Concurrencia en MariaDB Galera
Las escrituras a través de un nodo y a través de tres nodos se mantienen coherentes.
Ejecución
make galera-test: TestOneWriteNode, TestThreeWriteNodes.
Último resultado Superado, 3 ejecuciones cada uno.
Fuente: openkeel-barbican/docs/CONFORMANCE.md
Excluido del rewrite
Barbican conserva toda su API y los stores simple_crypto, PKCS#11 y Vault, y prescinde del proceso de reintentos sin uso, de Dogtag y de la infraestructura oslo.
Obsoleto o sin uso en upstream
Proceso barbican-retry
Por qué se excluyó
En esta rama ningún camino de código programa un reintento: el proceso solo consulta una tabla siempre vacía.
Por qué la solución no se ve afectada
Ninguno: los pedidos los procesa barbican-worker como en upstream.
Fuente: openkeel-barbican/docs/CONFORMANCE.md
Obsoleto o sin uso en upstream
Almacén de secretos y CA de Dogtag
Por qué se excluyó
Requiere un servidor Dogtag y su cliente Python, y los pedidos de certificados están desactivados en upstream en esta rama.
Por qué la solución no se ve afectada
Los secretos usan simple_crypto, un HSM mediante PKCS#11 o Vault. Las tablas de certificados existen pero no se modifican.
Fuente: openkeel-barbican/docs/CONFORMANCE.md
Asumido por la plataforma Cloud Native
Logs en archivos, middleware healthcheck, oslo_reports
Asumido por Kubernetes probes
Por qué se excluyó
Los logs van a stdout, el estado de salud a las probes de Kubernetes y los diagnósticos a pprof en el listener de administración.
Aquí solo figura lo que se excluyó por diseño; el trabajo aún no realizado está en los Known gaps del docs/CONFORMANCE.md del módulo. Todos los módulos
Interacciones Barbican
Vista de servicio generada por la skill de diagramas a partir del modelo de OpenKeel.