Necessary storage
Your selected language is stored for twelve months. This setting and the choice made here are used only to operate this website.
Tools · Secrets & identity infrastructure
OpenBao
Manages, stores and distributes secrets, certificates, keys and time-bounded credentials through identity- and policy-bound access. Applications obtain sensitive values under control at runtime instead of from images or source code.
Tools · Orthevs
OpenBao as an integrable tool
This technology may become part of a Factory. The Factory defines the domain tool function; scope, version, permissions, target environment and outputs must be evaluated for each integration.
Technical purpose
OpenBao
OpenBao provides a central API for sensitive data and cryptographic services. Authenticated clients receive only the paths and operations permitted by their policies; secrets can be stored statically or generated dynamically by suitable secrets engines. Leases, renewal and revocation limit the lifetime of issued credentials, while encryption as a service can protect data without keeping it permanently in plaintext in the calling system. Centralization creates control but also makes the service itself a particularly sensitive operational dependency.
Technology profile
Technology profile
- Category
- Secrets management, key and certificate infrastructure
- Operating model
- Authentication establishes identity; policies constrain paths and operations
- Data model
- Secrets, tokens, leases, policies, auth methods and secrets engines
- Storage
- Sensitive values are encrypted before persistent storage; seal and key management remain separate responsibilities
- Project governance
- Community project under the Linux Foundation OpenSSF
- Source license
- MPL-2.0
Integration in Orthevs
Orthevs Ecosystem
Platform Core provides shared, controlled access to OpenBao. Labs, Factories and services authenticate with narrowly scoped identities; secret paths, policies, lifetimes and permitted operations are bound to their capability contracts. Applications receive values only at runtime and must not copy them into artifacts, logs or long-lived configuration. Audit references, rotation, recovery and the handling of expired or revoked credentials are documented as part of the operating model.
Relevant capabilities
Relevant capabilities
- Encrypted storage of static key-value secrets with controlled API access
- Dynamic, time-bounded credentials through supported secrets engines
- Leases, renewal and targeted revocation of individual secrets or entire access trees
- Identity-bound authentication and ACL policies following least privilege
- Central encryption operations for data stored outside OpenBao
- Auditable access events as a basis for evidence, analysis and controlled rotation
Operating boundaries
Operating boundaries
OpenBao is itself a critical security, availability and recovery dependency. Seal, storage, backup, restoration and emergency access require a validated operating model.
A central secrets service does not replace least-privilege design. Overly broad policies or long-lived tokens merely relocate the risk.
Clients must not cache, log or copy issued secrets into artifacts without control; revocation must remain effective through to the actual consumer.
Audit data can itself contain sensitive information and requires defined filtering, access, retention and export rules.
SEC · Orthevs
Shape the target model together.
The content will be deepened step by step with concrete concepts, contracts, maturity levels and verifiable evidence.