OpenKeel: the sovereign French Cloud solution of the inherent group, with a European reach Discover inherent

Components · Identity and security

Barbican

Secrets, secret containers and keys.

Go MariaDB, PKCS#11openkeel-barbican

The module

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

Excerpt from openkeel-barbican/README.md (in English).

REST API

57 operations of the original REST API (routes and body actions), and their state in OpenKeel.

  • 57Implemented

How compatibility is tested

Barbican is checked by replay, by Barbican's own functional tests, by sending the same requests to Python and Go, and by running both side by side on one database and bus.

Replay of recorded exchanges

E2E replay of functional exchanges

The recorded functional exchanges give the same answers from the Go service.

How it runs

make e2e-strict on the embedded engine and on MariaDB 11.4.

Latest result 2 766 / 2 792 equal, 26 known differences (random keys, recorded dates, shared database); all pass live.

Source: openkeel-barbican/docs/CONFORMANCE.md

Client contract

Barbican functionaltests on Go

Barbican's upstream functionaltests/ pass against the Go service with a real Keystone.

How it runs

test/functional/run_functional.py --target go through the conformance adapter.

Latest result 563 ok, 0 failures, 69 skipped.

Source: openkeel-barbican/docs/CONFORMANCE.md

Differential test

Differential probe Python vs Go

The same requests sent to Python and Go Barbican, sharing one Keystone, get the same answers.

How it runs

test/functional/diff_probe.py, and --new-defaults for the RBAC defaults.

Latest result Legacy policies 804 / 833, 29 deliberate differences; enforce_new_defaults 378 / 378.

Source: openkeel-barbican/docs/CONFORMANCE.md

Unit and golden tests

Policy and at-rest vectors

Every policy decision of oslo.policy and the encrypted storage format of Python Barbican are reproduced.

How it runs

make test on policy-vectors.json.gz and the simple_crypto and p11_crypto vectors.

Latest result Policy 40 704 / 40 704; simple_crypto 25 / 25; p11_crypto 8 / 8 emulated, 4 / 8 on SoftHSM 2. No real HSM tested.

Source: openkeel-barbican/docs/CONFORMANCE.md

Differential test

Python and Go side by side

Python and Go share one MariaDB and RabbitMQ: cross reads of every secret type, orders both ways, barbicanclient, castellan and openstack secret.

How it runs

test/functional/interop.py; test/amqp/run.sh with oslo.messaging on RabbitMQ 3.13 and 4.4.

Latest result Interop 75 / 75; AMQP 3 / 3.

Source: openkeel-barbican/docs/CONFORMANCE.md

Concurrency on Galera

Concurrency on MariaDB Galera

Writes through one node and through three nodes stay consistent.

How it runs

make galera-test: TestOneWriteNode, TestThreeWriteNodes.

Latest result Pass, 3 runs each.

Source: openkeel-barbican/docs/CONFORMANCE.md

Left out of the rewrite

Barbican keeps its full API and the simple_crypto, PKCS#11 and Vault stores, and leaves out the dead retry process, Dogtag and the oslo plumbing.

Obsolete or unused upstream

barbican-retry process

Why it was left out

On this branch no code path schedules a retry: the process only polls an always-empty table.

Why the solution is not affected

None: orders are processed by barbican-worker as upstream.

Source: openkeel-barbican/docs/CONFORMANCE.md

Obsolete or unused upstream

Dogtag secret store and CA

Why it was left out

It needs a Dogtag server and its Python client, and certificate orders are disabled upstream on this branch.

Why the solution is not affected

Secrets use simple_crypto, an HSM through PKCS#11 or Vault. Certificate tables exist but are left untouched.

Source: openkeel-barbican/docs/CONFORMANCE.md

Done by the Cloud Native platform

File logging, healthcheck middleware, oslo_reports

Taken over by Kubernetes probes

Why it was left out

Logs go to stdout, health to Kubernetes probes, diagnostics to pprof on the admin listener.

Why the solution is not affected

The key manager API is unchanged.

Source: openkeel-barbican/config/dropped-options.md

Only what was left out by design is listed here; the work not done yet is in the Known gaps of the module's docs/CONFORMANCE.md. Every module

Barbican interactions

Service view generated by the diagram skill from the OpenKeel model.

Diagram openkeel-barbican.svg Full screen
The 2 interactions of the model
FromToProtocolWhat
Nova APIBarbicanREST APIencryption keys
GlanceBarbicanREST APIimage signatures

Specifications