net-kingdom/docs/princedom-isolation-exploration.md

NetKingdom Tenant Roles and Isolation

worsch, 25.5.2026 r1

Context

The following exploration on the use and setup of OpenBao Secrets Vaults in the NetKingdom IT Security Framework details some background on the roles of tenants NetKingdom will host and what security guarantees those can expect for their NetPrincedoms.

Disclaimer

Please keep in mind this is an exploratory document and does not constitute any binding as to which and how current and future NetKingdom functionality will be implemented and which security guarantees will be provided to what level of suffistication.

Exploration of OpenBao MultiTentant Functionality

Can openbao be used as a multi tenant secret store? If I have a openbao secret store can I define a domain or realm or something where somebody or some group can store secrets and only they can access those secrets while they are cryptographically protected from all other access?

Yes. OpenBao can be used as a multi-tenant secret store, and the concept you are looking for is now called Namespaces.

OpenBao namespaces are explicitly intended for secure multi-tenancy inside a single OpenBao instance. A namespace acts like a “mini-OpenBao” environment with its own secret engines, auth methods, policies, identity groups, tokens, and delegated administrators. OpenBao’s docs describe this as “secure multi-tenancy” with tenant isolation and administration delegation. (openbao.org)

The important distinction is this:

OpenBao can isolate tenants at the authorization and administrative-boundary level. It does not automatically mean that tenant secrets are cryptographically unreadable to the ultimate OpenBao root/operator authority.

OpenBao encrypts data before writing it to the storage backend. The storage backend is treated as untrusted, and data stored there is encrypted by OpenBao’s barrier. So someone with direct database/storage access should not be able to read plaintext secrets. (openbao.org)

But once OpenBao is unsealed, OpenBao itself can decrypt data to serve legitimate read requests. A root user or sufficiently privileged administrator can do anything inside OpenBao; the root policy is explicitly described as all-powerful. (openbao.org)

So the model is:

Requirement	OpenBao answer
Team A and Team B have separate secret areas	Yes: namespaces, mounts, policies
Team admins can manage only their area	Yes: delegated namespace administration
Users can only access secrets allowed by policy	Yes: path-based ACL policies, deny by default
Storage backend admin cannot read secrets from disk/db	Yes, data is encrypted before storage
Root OpenBao admin cannot read tenant secrets	Not by default
Cryptographic separation from the platform operator	Not fully, unless you add extra design measures

For normal internal multi-tenancy, OpenBao namespaces are a strong fit. For example:

root/
  tenants/
    customer-a/
      kv/
      auth/
      policies/
    customer-b/
      kv/
      auth/
      policies/

Each tenant namespace can have its own auth method, policies, groups, and KV secret engine. Policies decide which users or workloads can read, write, list, or delete which paths. OpenBao policies are path-based and deny access by default. (openbao.org)

For hard cryptographic tenant isolation, you need to be more careful. Depending on your threat model, you might choose one of these patterns:

1. Soft multi-tenancy: one OpenBao cluster, one seal, multiple namespaces. Good for teams, departments, internal platforms, and moderate SaaS isolation.

2. Stronger tenant isolation: separate OpenBao clusters per tenant or per security domain. This gives each tenant a separate seal/unseal boundary and separate operational blast radius.

3. Tenant-side encryption: tenants encrypt secrets before sending them to OpenBao, and OpenBao only stores ciphertext. This protects against the OpenBao operator but makes secret lifecycle, rotation, search, dynamic secrets, and integrations harder.

4. HSM/KMS-backed seal with strict operator controls: improves protection of master keys and operational discipline, but still does not make secrets unreadable to all OpenBao-side privileged access once the service is legitimately serving reads.

So, for your wording:

“Can I define a domain or realm or something where somebody or some group can store secrets and only they can access those secrets?”

Yes: use OpenBao namespaces plus policies and identity/auth mappings.

“while they are cryptographically protected from all other access?”

Protected from storage-level access, yes. Protected from other tenants via ACL and namespace isolation, yes. Protected from OpenBao root/platform operators cryptographically, not by default.

For your use case around multi-tenant service landscapes, I would treat OpenBao namespaces as suitable for organizational/administrative tenancy, but not as sufficient alone for zero-trust tenant secrecy against the platform owner.

OpenBao vs. HashiCorp Vault

Would you compare that with hashicorp vault please. Would the assessment be different there?

The assessment is mostly the same for HashiCorp Vault Enterprise, with one important product/licensing difference and one OpenBao-specific nuance.

Core comparison

Question	OpenBao	HashiCorp Vault
Can it be used as a multi-tenant secret store?	Yes, with Namespaces.	Yes, with Namespaces, but this is a Vault Enterprise / HCP Vault Dedicated feature, not normal Vault Community Edition.
Tenant-like isolation concept	Namespace	Namespace
Can each tenant/team have own auth methods, policies, secret engines, tokens, identity objects?	Yes. OpenBao describes namespaces as isolated “mini-OpenBao” environments. (openbao.org)	Yes. HashiCorp describes namespaces as isolated “mini-Vault” environments with own policies, auth methods, secrets engines, tokens, identity entities, and groups. (HashiCorp Developer)
Delegated administration	Yes.	Yes.
Storage backend cryptographic protection	Yes, OpenBao encrypts stored data before writing to the backend, inherited from the Vault architecture lineage.	Yes, Vault uses the same core “encrypted barrier” model: storage is not trusted with plaintext.
Cryptographic protection from other tenants	Operationally yes via namespace/policy isolation; cryptographically mostly via the shared Vault/Bao barrier.	Same.
Cryptographic protection from the platform/root operator	No, not by default.	No, not by default.
Hard isolation option	Separate OpenBao clusters or tenant-side encryption.	Separate Vault clusters or tenant-side encryption.

The important licensing/product difference

With HashiCorp Vault, namespaces are an Enterprise feature. HashiCorp’s namespace docs are under Vault Enterprise and explicitly frame namespaces as secure multi-tenancy inside a single Vault Enterprise instance. (HashiCorp Developer)

With OpenBao, namespaces are available in the open-source OpenBao project. OpenBao added namespace support to provide secure multi-tenancy in a single OpenBao instance. (openbao.org)

So if the question is:

“Can I build a multi-tenant secret store without paying for Vault Enterprise?”

Then OpenBao changes the answer materially: yes, OpenBao gives you namespace-based multi-tenancy as an open-source capability.

The security assessment is not fundamentally different

For both systems, namespaces are a logical and administrative isolation boundary, not a magical cryptographic boundary against the ultimate service operator.

A tenant can be isolated from another tenant by:

namespace
auth method
identity/group mapping
policy
secret-engine mount
audit/logging controls

That means Team A cannot normally read Team B’s secrets if policies and namespaces are configured correctly.

But in both Vault and OpenBao, once the service is unsealed and serving requests, a sufficiently privileged root/operator can usually create policy, mint tokens, change configuration, or otherwise gain access. The storage backend is protected cryptographically, but the running secret-store authority is still trusted.

So the honest answer is:

Vault Enterprise and OpenBao both support strong organizational multi-tenancy. Neither gives full cryptographic secrecy from the platform authority by namespaces alone.

One OpenBao nuance: namespace isolation may be stricter in places

OpenBao’s namespace implementation was developed separately after the fork, and some commentary around the implementation notes that OpenBao defaults to a stricter identity isolation model, with a compatibility flag for Vault Enterprise-like cross-namespace identity behavior. (Adfinis)

That does not change the core operator-trust conclusion, but it is relevant if you compare detailed namespace semantics. OpenBao may actually be attractive if you want open-source namespaces with careful isolation defaults.

Practical conclusion

For your platform architecture, I would classify the options like this:

Threat model	Recommended pattern
Internal teams, apps, environments, business units	One OpenBao or Vault Enterprise cluster with namespaces
SaaS tenants where your company is trusted operator	Namespaces can be acceptable, with strong policy, audit, backup, and operational controls
SaaS tenants where even your operators must not be able to read secrets	Separate clusters per tenant/security domain, tenant-side encryption, external customer-owned KMS/HSM, or some combination
Regulatory/high-assurance tenant separation	Prefer cluster-per-domain or tenant-controlled keys over namespace-only design

My compact assessment:

HashiCorp Vault Enterprise and OpenBao are conceptually equivalent for namespace-based multi-tenancy. OpenBao is more accessible because namespaces are open source. But neither should be described as cryptographically isolating tenants from the ultimate secret-store operator unless you add a stronger key ownership or deployment isolation model.

Cryptographic Tentant Isolation

Is there an extension or modification for open bao that allows for a tenant to add a tenant key that openbao will then use to on the fly encrypt and decrypt assets of this tenant to add a cryptographic tenant from vendor and tenant from tenant boundry? This seem like not very complicated and would enable sealing and unsealing of tenant credentials by requesting to drop or reintroducing the tenant key.

Yes — you are describing almost exactly OpenBao’s planned “Per-Namespace Sealing” design.

As of the current public docs/release notes I found, this is an OpenBao RFC/design direction, not something I would treat as broadly available/stable production functionality yet. The RFC’s purpose is to “extend OpenBao’s tenant separation capabilities” by creating per-namespace sealing, with per-tenant encryption key separation. (openbao.org)

The design language matches your intuition very closely:

A sealed namespace discards its in-memory namespace-root key, which is required to decrypt the dedicated namespace encryption key, so OpenBao cannot respond to operations for that namespace while it is sealed. (GitHub)

So conceptually:

OpenBao cluster seal
  protects global OpenBao operation

Namespace / tenant seal
  protects tenant namespace root key

Namespace root key
  unwraps tenant namespace encryption key

Tenant namespace encryption key
  encrypts/decrypts that namespace’s data

That gives you the boundary you are looking for:

Tenant A sealed   -> OpenBao can continue serving other tenants
Tenant A unsealed -> OpenBao can serve Tenant A requests
Tenant A key gone -> OpenBao cannot decrypt Tenant A namespace data

OpenBao’s namespace announcement also says the working group is exploring namespace sealing, non-hierarchical namespaces, per-namespace storage backends, and plugin isolation as future improvements. (openbao.org)

Is there an extension/plugin today?

I would not assume there is a mature plug-in you can just install for this today. The most direct thing is the Per-Namespace Sealing RFC. OpenBao also has an External Keys RFC for KMS/HSM-backed key material, described as a per-namespace repository of seal configurations with mount-specific key information. That is related, but slightly different: it is about backing cryptographic material with external KMS/HSM systems for engines such as PKI, Transit, and SSH. (openbao.org)

So the current picture is:

Capability	Status / fit
Normal namespace multi-tenancy	Available in OpenBao namespaces
Lock/unlock namespace	Available as namespace functionality in 2.3-era release notes
Per-namespace cryptographic sealing	RFC / design direction
Tenant-controlled namespace key	Part of the per-namespace sealing vision
External KMS/HSM key backing	RFC / related design direction
Fully mature “tenant BYOK namespace encryption”	I would verify implementation status before relying on it

Why it is not quite “simple”

Your architectural idea is right, but implementing it safely inside a Vault/OpenBao-style secret store is more subtle than it first appears.

The hard parts are not just encrypt/decrypt. They include:

1. Key hierarchy correctness You need clear separation between global barrier keys, namespace-root keys, namespace encryption keys, mount keys, and possibly per-engine keys.

2. No plaintext leakage through cache/index/audit/replication If a tenant namespace is sealed, OpenBao must not still have decrypted values, derived keys, leases, cached auth state, indexes, plugin memory, or replication buffers that expose the tenant.

3. Operational semantics What should happen to leases, dynamic credentials, token renewal, PKI issuance, database credential rotation, and long-running plugins while the namespace is sealed?

4. Cluster behavior In HA, every active/standby node needs consistent behavior. A tenant key must not remain available on one node after sealing elsewhere.

5. Recovery and deletion semantics Losing a tenant key may mean permanent tenant data loss. That must be explicit and auditable.

6. Root/admin bypass Even with per-namespace sealing, once the tenant deliberately unseals, privileged OpenBao-side code may again be able to serve decrypted data. This improves cryptographic separation at rest and while sealed, but it does not automatically create a perfect “operator can never read anything” guarantee during active service.

Best architecture name for this

I would call the pattern:

Tenant-Controlled Namespace Sealing

or more explicitly:

Per-Tenant Cryptographic Namespace Boundary

The tenant key does not necessarily need to encrypt every secret directly. Better is usually envelope encryption:

Tenant-controlled key / tenant-unseal material
    unwraps
Namespace root key
    unwraps
Namespace data encryption key(s)
    encrypt actual namespace data

That allows key rotation, performance, and compatibility with OpenBao’s internal barrier/keyring model.

Practical recommendation

For a design today, I would distinguish three maturity levels:

Level	Pattern	Security meaning
Level 1	OpenBao namespaces + policies	Tenant isolation by ACL/admin boundary
Level 2	Separate OpenBao cluster per tenant/security domain	Strong operational and cryptographic isolation
Level 3	OpenBao namespace sealing / tenant BYOK once mature	Shared cluster, but tenant-controlled cryptographic availability

For your platform thinking, the idea is very promising. I would not yet base a production SaaS security promise on “tenant can cryptographically seal their namespace from us” unless you verify the exact OpenBao version and implementation state. But as a target architecture, OpenBao is clearly moving in the direction you are describing.

Tenant Isolation Variations

Ok, so to provide multi tenancy with strong cryptographic isolation of secrets for a tenant this tenant needs its own openbao instance. This is sound but will bring downstream complications as all security features using openbao transparently need to connect to the specific openbao instance if it's tenant or the global openbao if the tenant is "only" namespace separated. This needs to be managed and the only consistent way to do that would be one of two scenarios: A) Strong secrets protection in separate openbao leads to a completely separate runtime environment for the client. All fleet management to handle multiple client would need to be added in top of that. B) Strong secrets protection in separate openbao is mapped to a namespace in vendor openbao so that all services consumed by clients of the vendor keep their style and strength of multi tenancy without any additional separation of instances as the devices can access secrets via the vendors openbao in what one might call a federated openbao setup.

Yes — your conclusion is sound, and the architectural consequence is exactly the one you identified:

If strong cryptographic isolation means “the vendor’s OpenBao root/operator must not be able to decrypt tenant secrets,” then namespace-only tenancy is not enough today. The tenant needs either its own OpenBao instance/cluster, tenant-side encryption, or a future mature per-namespace sealing/BYOK mechanism.

OpenBao namespaces give secure multi-tenancy in one instance, but they are still within one OpenBao authority. The docs describe namespaces as multi-tenant isolated environments, and requests are routed by namespace path or the X-Vault-Namespace header. That is excellent for logical separation, but not the same as a separate cryptographic authority. (openbao.org)

Your two scenarios are the right fork.

Scenario A — Separate tenant OpenBao implies separate tenant runtime

This is the cleanest security story.

Tenant runtime A
  ├─ tenant apps
  ├─ tenant database
  ├─ tenant OpenBao
  ├─ tenant auth bindings
  └─ tenant operators / tenant key custody

Tenant runtime B
  ├─ tenant apps
  ├─ tenant database
  ├─ tenant OpenBao
  └─ ...

This gives you the strongest boundary because the tenant’s secrets, seal state, audit trail, auth config, leases, and operational lifecycle are all scoped to that tenant runtime.

The cost is exactly what you said: you now need fleet management on top.

That means you need to manage:

tenant provisioning
OpenBao deployment
seal / unseal / recovery policy
backup / restore
version upgrades
policy templates
auth method configuration
secret engine bootstrap
monitoring
audit log routing
incident response
tenant offboarding

This is operationally heavier, but it is conceptually honest. It is the model I would choose for tenants with high regulatory sensitivity, customer-owned encryption-key requirements, or explicit “vendor cannot decrypt” commitments.

The architecture label could be:

Tenant Runtime Isolation

or:

Dedicated Security Cell per Tenant

This is similar to a “cell-based architecture”: each tenant gets a security cell, and the platform manages a fleet of cells.

Scenario B — Federated OpenBao façade mapped into vendor tenancy

This is more interesting and probably closer to what you want for a scalable SaaS platform.

The idea would be:

Vendor services
  └─ talk to vendor OpenBao-compatible endpoint

Vendor secret broker / federation layer
  ├─ resolves tenant context
  ├─ maps request to tenant namespace or tenant OpenBao
  ├─ enforces vendor-side policy envelope
  └─ proxies/obtains secrets from correct backend

Backends
  ├─ vendor OpenBao namespace for ordinary tenants
  ├─ dedicated tenant OpenBao for strong-isolation tenants
  └─ possibly external KMS/HSM or tenant-side ciphertext store

In this model, applications keep a consistent integration style:

GET /v1/secret/data/foo
X-Vault-Namespace: tenants/acme/

or some equivalent internal contract.

But the platform control plane decides whether that tenant is backed by:

tenant mode = namespace
  -> route to shared vendor OpenBao namespace

tenant mode = dedicated_bao
  -> route to tenant-specific OpenBao cluster

tenant mode = external_key
  -> route to shared namespace plus tenant-controlled key mechanism

This is what you called federated OpenBao, and that is a good name. I would be slightly more precise and call it:

OpenBao Federation Gateway

or:

Secret Authority Router

The key idea is that tenant isolation mode becomes a routing and authority decision, not something every consuming service has to know.

The central design principle

You do not want every service to contain logic like:

if tenant is premium:
    use tenant-specific OpenBao URL
else:
    use shared OpenBao namespace

That would leak tenancy infrastructure into every service and become painful quickly.

Instead, every workload should use one stable abstraction:

resolveSecret(tenant_id, logical_secret_ref)

or, operationally:

tenant_id + secret_path -> secret authority route

Then a central component maps:

tenant_id
  -> isolation tier
  -> OpenBao endpoint
  -> namespace
  -> auth method
  -> policy envelope
  -> audit destination

This implies a small but important platform component

I would introduce a component like this:

secret-federation

or:

bao-federator

Its job is not to replace OpenBao. Its job is to provide a stable tenant-aware access layer.

Core responsibilities:

Tenant Secret Authority Registry
  Which OpenBao authority owns this tenant?

Secret Route Resolution
  Given tenant + logical path, where does the request go?

Credential Brokering
  How does the workload authenticate to the right authority?

Policy Envelope Enforcement
  What vendor-level constraints always apply?

Audit Correlation
  How do logs across shared and dedicated stores remain traceable?

Lifecycle Hooks
  What happens on tenant provisioning, upgrade, suspension, offboarding?

For Kubernetes workloads, this could integrate with patterns such as OpenBao Agent, agent injection, or CSI-based secret mounting. OpenBao Agent is designed to let applications consume rendered secrets without modifying the application, and OpenBao integrations include injector/CSI-style approaches for Kubernetes secret delivery. (openbao.org)

Important caveat: do not proxy plaintext unless necessary

A federation gateway can easily become the new weakest point.

There are two possible designs:

1. Secret proxy

App -> gateway -> tenant OpenBao -> gateway -> plaintext secret -> app

This is simple, but the gateway sees plaintext. That means the gateway becomes part of the trusted computing base.

2. Route/config broker

App/agent asks gateway:
  "Where and how do I fetch tenant X secret Y?"

Gateway returns:
  endpoint, namespace, auth config, policy constraints

App/agent fetches directly from tenant OpenBao.

This is often better. The broker controls routing, but does not necessarily handle plaintext secrets.

For strong isolation, I would prefer the second model wherever possible.

How this maps to OpenBao’s direction

OpenBao is already moving toward concepts that support your long-term target: namespaces, namespace sealing, external keys, and horizontal scalability work. Namespace sealing specifically aims to make sealed namespaces physically unable to serve operations because the namespace-root key is discarded from memory. (openbao.org)

The External Keys RFC is also relevant because it discusses per-namespace repositories of seal configurations and KMS/HSM-backed cryptographic material. (openbao.org)

But until those mechanisms are mature enough for your security promise, the production-grade options remain:

shared OpenBao + namespace
  good organizational isolation

dedicated OpenBao per tenant
  strong cryptographic authority isolation

federation gateway / secret authority router
  keeps the platform consumption model uniform

My recommendation

I would model this as a three-tier tenancy architecture:

Tier	Name	Secret-store backing	Security promise
T1	Shared Tenant	Shared OpenBao namespace	Isolated by namespace, policy, audit
T2	Sealed Tenant	Future per-namespace sealing / external keys	Tenant can suspend cryptographic availability
T3	Dedicated Tenant	Dedicated OpenBao instance/cluster	Tenant has separate cryptographic authority

Then build the platform so services never care which tier a tenant is in.

The key abstraction is:

TenantSecretAuthority

With fields roughly like:

tenant_id: acme
isolation_tier: dedicated
authority_type: openbao
endpoint_ref: openbao-acme.internal
namespace: /
auth_profile: kubernetes-workload-acme
audit_profile: acme-audit-stream
key_custody: tenant-controlled
lifecycle_policy: dedicated-security-cell

For a normal namespace tenant:

tenant_id: demo
isolation_tier: shared
authority_type: openbao
endpoint_ref: openbao-global.internal
namespace: tenants/demo
auth_profile: kubernetes-workload-shared
key_custody: vendor-controlled

That lets you keep one platform integration model while supporting multiple security strengths underneath.

So yes: A is the clean strong-isolation primitive; B is the necessary platform abstraction to make A usable without contaminating every service with tenant-specific secret-store routing.

Supported Tentant Roles

This is quite interesting and it is not trivial to understand downstream implications. Let's stick with namespace based isolation for now. The IT-Security setup I am trying to build is multi-tenant, multi-vendor, multi-customer in the following sense. A tenant can have a number of admins organizing a number of users consuming a number of apps of different vendors while being itself a vendor of multiple apps to be consumed by other tenants and non tenants. To achieve that the infrastructure uses age-keys and ssh for platform operations, IAM by keycloak or it's lightweight replacement keycape that delegates to authelia and lldap, privacyidea for 2FA, openbao as secrets vault. This is quite an interesting challenge and I am currently in the process of bootstrapping the environment securely and will hopefully be transitioning to onboarding a new vendor tenant and a new consumer tenant shortly. Conceptually I am thinking about four different roles tenants can adopt and one tenant can have multiple roles at the same time: 1) A PLTF tenant, this is the special tenant providing and operating the platform itself. 2) IAM tenants, they use the platform to organize their user base and secrets or some of it. 3) VEN tenants, they use the platform as vendors to provide apps for others that might be tenants themselves. 4) CUS tenants, they use the platform as customers to consume apps and services provided by PLTF or VEN tenants. Introducing strong cryptographic isolation for a tenant is not trivial at all. While adding this option might in principle be a decision for a future portfolio extension, it would be quite comforting to know that PLTF is cryptographically isolated ensuring there is a soundly secure management zone to operate the infrastructure from.

Yes. I would frame your current conclusion like this:

Stay with namespace-based tenant isolation for IAM/VEN/CUS tenants, but do not put the PLTF management zone merely “beside” them as another ordinary namespace. Treat PLTF as a higher-trust security cell with its own cryptographic root of authority.

That gives you a coherent bootstrap path without prematurely solving full tenant BYOK / per-tenant cryptographic isolation.

1. Your tenant-role model is good

Your four roles are not mutually exclusive tenant types; they are capability roles a tenant can hold:

PLTF = operates the platform itself
IAM  = uses the platform to manage users, auth, secrets, identity context
VEN  = provides applications/services to others
CUS  = consumes applications/services from PLTF or VEN tenants

That is the right abstraction because one tenant can be both VEN and CUS, or IAM and VEN, etc.

I would therefore avoid modeling these as separate tenant classes. Instead:

tenant_id: example-org
roles:
  - IAM
  - VEN
  - CUS
isolation_tier: namespace
trust_domain: standard

And for the platform tenant:

tenant_id: platform
roles:
  - PLTF
  - IAM
  - VEN
isolation_tier: dedicated-management
trust_domain: platform-root

The important part is that PLTF is not just a commercial role. It is a security authority role.

2. OpenBao namespaces are good for the ordinary tenant layer

For normal IAM/VEN/CUS separation, OpenBao namespaces fit well. OpenBao describes namespaces as supporting secure multi-tenancy within a single instance, with tenant isolation and delegated administration. A namespace creates an isolated environment with its own login paths and tenant-managed sensitive data. (openbao.org)

So for now, this is a reasonable structure:

openbao-shared
  /tenants/tenant-a/
    iam/
    apps/
    secrets/
  /tenants/tenant-b/
    iam/
    apps/
    secrets/
  /vendors/vendor-x/
    apps/
    delivery/
    integration-secrets/

But the security statement should be precise:

Namespace isolation protects tenants from each other by OpenBao policy, namespace boundaries, auth separation, and administration delegation. It does not give each tenant a separate cryptographic OpenBao authority today.

OpenBao’s storage backend is treated as untrusted and data is encrypted before being sent to storage, so storage-level compromise is a different threat than OpenBao/root/operator-level compromise. (openbao.org) OpenBao’s security model also describes a security barrier that encrypts data leaving OpenBao using AES-GCM. (openbao.org)

3. PLTF should probably be cryptographically separated

Your instinct is right: if there is one place where strong cryptographic isolation is worth the operational cost, it is PLTF.

The platform management zone holds the secrets that can affect everything else:

cluster bootstrap keys
age private keys or age recipient management
SSH CA / deploy keys / break-glass keys
OpenBao root/recovery material
Keycloak/Keycape admin bootstrap credentials
Authelia/LLDAP bind/admin credentials
privacyIDEA admin/bootstrap credentials
CI/CD deploy tokens
container registry credentials
backup encryption keys
DNS/provider credentials
Kubernetes admin kubeconfigs
Terraform/OpenTofu state credentials

If these live inside the same OpenBao instance that ordinary tenant admins can influence indirectly, then your conceptual hierarchy is weaker than it looks.

So I would separate:

PLTF Management Secret Authority
  dedicated OpenBao instance/cluster
  dedicated seal/unseal/recovery process
  dedicated admin identities
  dedicated audit path
  stores platform bootstrap and control-plane secrets

Shared Tenant Secret Authority
  OpenBao instance with namespaces
  stores IAM/VEN/CUS tenant secrets
  operated through PLTF-controlled automation

This gives you a strong principle:

PLTF manages tenant OpenBao, but tenant OpenBao does not manage PLTF.

That one sentence is probably the most important architecture rule here.

4. Recommended first architecture

I would start with a two-OpenBao architecture, not one OpenBao per tenant.

                  ┌────────────────────────────┐
                  │ PLTF Management Zone        │
                  │                            │
                  │ openbao-platform            │
                  │ - bootstrap secrets         │
                  │ - infra root secrets        │
                  │ - age/ssh/key material      │
                  │ - IAM bootstrap secrets     │
                  │ - tenant provisioning creds │
                  └─────────────┬──────────────┘
                                │ controls/provisions
                                ▼
                  ┌────────────────────────────┐
                  │ Shared Tenant Zone          │
                  │                            │
                  │ openbao-tenants             │
                  │ /tenants/acme               │
                  │ /tenants/example            │
                  │ /vendors/vendor-a           │
                  └────────────────────────────┘

This is much simpler than fully dedicated tenant runtimes, but it gives you a real management/security boundary where it matters most.

In your terminology:

PLTF tenant:
  cryptographically isolated by dedicated OpenBao

IAM/VEN/CUS tenants:
  namespace-isolated in shared OpenBao for now

That is a sane MVP security posture.

5. Why this is better than putting PLTF into the shared OpenBao root namespace

You could technically model PLTF as:

openbao-shared
  /platform/
  /tenants/a/
  /tenants/b/

But I would avoid that for bootstrap and governance reasons.

The PLTF authority should be able to answer questions like:

Can I rotate or rebuild the tenant OpenBao?
Can I revoke a tenant admin?
Can I recover from tenant OpenBao corruption?
Can I re-bootstrap Keycloak/Keycape?
Can I re-issue machine credentials?
Can I recover CI/CD and cluster operations?

If the answer depends on secrets stored in the same tenant-facing OpenBao, you have a circular dependency.

Better:

openbao-platform can rebuild openbao-tenants
openbao-tenants cannot rebuild openbao-platform

6. Future-proofing for per-namespace sealing

This does not block future stronger tenant isolation.

OpenBao is already exploring per-namespace sealing, namespace sealing, per-namespace storage backends, and plugin isolation as future namespace improvements. (openbao.org) The per-namespace sealing RFC explicitly aims to add per-tenant encryption key separation. (openbao.org) The RFC list also describes “Per-Namespace Sealing” as intended to add per-tenant encryption key separation. (openbao.org)

So your future model could become:

Tier 0: PLTF dedicated OpenBao
Tier 1: IAM/VEN/CUS shared namespace
Tier 2: IAM/VEN/CUS sealed namespace, once mature
Tier 3: IAM/VEN/CUS dedicated OpenBao/security cell

But for now, you can keep the platform manageable:

PLTF = dedicated cryptographic authority
others = namespace isolation

7. A useful control-plane model

I would introduce a small registry early, even if it is just YAML at first:

tenant_id: acme
roles:
  - IAM
  - CUS
secret_authority:
  mode: namespace
  openbao_ref: openbao-tenants
  namespace: tenants/acme
iam_authority:
  mode: platform-managed
  realm: acme
mfa:
  provider: privacyidea
  scope: tenant

For PLTF:

tenant_id: platform
roles:
  - PLTF
  - IAM
  - VEN
secret_authority:
  mode: dedicated
  openbao_ref: openbao-platform
  namespace: /
iam_authority:
  mode: platform-root
  realm: platform
mfa:
  provider: privacyidea
  scope: platform-root

This prevents the downstream mess later because every service can resolve:

tenant_id -> tenant role set -> IAM realm/context -> OpenBao authority -> namespace/path

Even before you build a full “federated OpenBao” layer, you have the metadata model ready.

8. My recommended bootstrap sequence

I would sequence it like this:

1. Create the PLTF management zone first Dedicated OpenBao, dedicated seal/recovery process, minimal admin set, strong audit.

2. Store only platform-bootstrap and control-plane secrets there Do not let ordinary app secrets accumulate in PLTF OpenBao.

3. Create the shared tenant OpenBao next Namespace-based model for IAM/VEN/CUS tenants.

4. Define tenant role metadata outside OpenBao YAML, GitOps repo, or small registry. Do not let namespace layout become the only source of truth.

5. Create the first IAM tenant and first VEN/CUS tenant as namespace tenants Keep them operationally boring.

6. Add stronger isolation later as an isolation tier Do not redesign the consumer-facing app model when adding this.

9. Compact architecture rule set

I would write the initial rules like this:

R1: PLTF is a security authority, not merely a tenant namespace.

R2: PLTF secrets must be stored in a dedicated OpenBao authority.

R3: Shared tenant OpenBao may store IAM/VEN/CUS tenant secrets using namespaces.

R4: Tenant namespace isolation is an authorization and administration boundary, not a vendor-proof cryptographic boundary.

R5: Tenant role membership is independent of isolation tier.

R6: All services must resolve tenant secret access through a tenant authority registry, not hard-coded OpenBao URLs.

R7: The PLTF authority may provision and recover tenant authorities; tenant authorities must not be required to recover PLTF.

That gives you a clean current architecture and a clean migration path.

My practical assessment: do not try to solve cryptographic isolation for every tenant now. Do solve it for PLTF now. That creates a sound management zone from which the rest of the infrastructure can safely evolve.

Closing Remarks

Establishing a consistently managable IT-Security Environment as discussed above will provide a sound foundation for an open-source monetization platform spanning ideation to implementation to monetization. The setup is non trivial but feels doable and can provide utility and a case for the development and monetization model in itself.

xxx