Skip to main content

Security model

Due to the nature of OpenBao and the confidentiality of data it manages, the OpenBao security model is very critical. The overall goal of OpenBao's security model is to provide confidentiality, integrity, availability, accountability, authentication.

This means that data at rest and in transit must be secure from eavesdropping or tampering. Clients must be appropriately authenticated and authorized to access data or modify policies. All interactions must be auditable and traced uniquely back to the origin entity, and the system must be robust against intentional attempts to bypass any of its access controls.

Threat model

The following are the various parts of the OpenBao threat model:

  • Eavesdropping on any OpenBao communication. Client communication with OpenBao should be secure from eavesdropping as well as communication from OpenBao to its storage backend or between OpenBao cluster nodes.

  • Tampering with data at rest or in transit. Any tampering should be detectable and cause OpenBao to abort processing of the transaction.

  • Access to data or controls without authentication or authorization. All requests must be proceeded by the applicable security policies.

  • Access to data or controls without accountability. If audit logging is enabled, requests and responses must be logged before the client receives any secret material.

  • Confidentiality of stored secrets. Any data that leaves OpenBao to rest in the storage backend must be safe from eavesdropping. In practice, this means all data at rest must be encrypted.

  • Availability of secret material in the face of failure. OpenBao supports running in a highly available configuration to avoid loss of availability.

The following are not considered part of the OpenBao threat model:

  • Protecting against arbitrary control of the storage backend. An attacker that can perform arbitrary operations against the storage backend can undermine security in any number of ways that are difficult or impossible to protect against. As an example, an attacker could delete or corrupt all the contents of the storage backend causing total data loss for OpenBao. The ability to control reads would allow an attacker to snapshot in a well-known state and rollback state changes if that would be beneficial to them.

  • Protecting against the leakage of the existence of secret material. An attacker that can read from the storage backend may observe that secret material exists and is stored, even if it is kept confidential.

  • Protecting against memory analysis of a running OpenBao. If an attacker is able to inspect the memory state of a running OpenBao instance, then the confidentiality of data may be compromised.

  • Protecting against flaws in external systems or services used by OpenBao. Some authentication methods or secrets engines delegate sensitive operations to systems external to OpenBao. If an attacker can compromise credentials or otherwise exploit a vulnerability in these external systems, then the confidentiality or integrity of data may be compromised.

  • Protecting against malicious plugins or code execution on the underlying host. If an attacker can gain code execution or write privileges to the underlying host, then the confidentiality or the integrity of data may be compromised.

  • Protecting against flaws in clients or systems that access OpenBao. If an attacker can compromise an OpenBao client (e.g., system, browser) and obtain this client’s OpenBao credentials, they can access OpenBao with the level of privilege associated with this client.

  • Protecting against OpenBao administrators supplying vulnerable or malicious configuration data. Any data provided as configuration values to OpenBao's administrative endpoints (e.g. secret engines configurations), or OpenBao's configuration files should be validated. If an attacker can write to OpenBao's configuration, then the confidentiality or integrity of data can be compromised.

External threat overview

OpenBao architecture compromises of three distinct systems:

  • Client: Speaks to OpenBao over an API.
  • Server: Provides an API and serves requests.
  • Storage backend: Utilized by the server to read and write data.

There is no mutual trust between the OpenBao client and server. Clients use TLS to verify the identity of the server and to establish a secure communication channel. Servers require that a client provides a client token for every request which is used to identify the client. A client that does not provide their token is only permitted to make login requests.

All server-to-server traffic between OpenBao instances within a cluster uses mutually-authenticated TLS to ensure the confidentiality and integrity of data in transit. Nodes are authenticated prior to joining the cluster by an unseal challenge.

The storage backends used by OpenBao are also untrusted by design. OpenBao uses a security barrier for all requests made to the backend. The security barrier automatically encrypts all data leaving OpenBao using a 256-bit Advanced Encryption Standard (AES) cipher in the Galois Counter Mode (GCM) with 96-bit nonces. The nonce is randomly generated for every encrypted object. When data is read from the security barrier, the GCM authentication tag is verified during the decryption process to detect any tampering.

Depending on the backend used, OpenBao may communicate with the backend over TLS to provide an added layer of security. In some cases, such as a file backend, this is not applicable. Because storage backends are untrusted, an eavesdropper would only gain access to encrypted data even if communication with the backend was intercepted.

Internal threat overview

Within the OpenBao system, a critical security concern is an attacker attempting to gain access to secret material they are not authorized to. This is an internal threat if the attacker is already permitted to some level of access to OpenBao, and is able to authenticate.

When a client first authenticates with OpenBao, an auth method is used to verify the identity of the client and to return a list of associated ACL policies. This association is configured by operators of OpenBao ahead of time. For example, GitHub users in the "engineering" team may be mapped to the "engineering" and "ops" OpenBao policies. OpenBao then generates a client token which is a randomly generated, serialized value and maps it to the policy list. This client token is then returned to the client.

On each request, a client provides this token. OpenBao then uses it to check that the token is valid and has not been revoked or expired, and generates an ACL based on the associated policies. OpenBao uses a strict default deny enforcement strategy. This means unless an associated policy allows for a given action, it will be denied. Each policy specifies a level of access granted to a path in OpenBao. When the policies are merged (if multiple policies are associated with a client), the highest access level permitted is used. For example, if the "engineering" policy permits read/update access to the "eng/" path, and the "ops" policy permits read access to the "ops/" path, then the user gets the union of those. Policy is matched using the most specific defined policy, which may be an exact match or the longest-prefix match glob pattern. See Policy Syntax for more details.

Certain operations are only permitted by "root" users, which is a distinguished policy built into OpenBao. This is similar to the concept of a root user on a Unix system or an administrator on Windows. In cases where clients are provided with root tokens or associated with the root policy, OpenBao supports the notion of "sudo" privilege. As part of a policy, users may be granted "sudo" privileges to certain paths, so that they can still perform security sensitive operations without being granted global root access to OpenBao.

Lastly, OpenBao supports using a Two-person rule for unsealing using Shamir's Secret Sharing technique. When OpenBao is started, it starts in a sealed state. This means that the encryption key needed to read and write from the storage backend is not yet known. The process of unsealing requires providing the root key so that the encryption key can be retrieved. The risk of distributing the root key is that a single malicious attacker with access to it can decrypt the entire OpenBao. Instead, Shamir's technique allows us to split the root key into multiple shares or parts. The number of shares and the threshold needed is configurable, but by default OpenBao generates 5 shares, any 3 of which must be provided to reconstruct the root key.

By using a secret sharing technique, we avoid the need to place absolute trust in the holder of the root key, and avoid storing the root key at all. The root key is only retrievable by reconstructing the shares. The shares are not useful for making any requests to OpenBao, and can only be used for unsealing. Once unsealed the standard ACL mechanisms are used for all requests.

To make an analogy, a bank puts security deposit boxes inside of a vault. Each security deposit box has a key, while the vault door has both a combination and a key. The vault is encased in steel and concrete so that the door is the only practical entrance. The analogy to OpenBao is that the cryptosystem is the steel and concrete protecting the data. While you could tunnel through the concrete or brute force the encryption keys, it would be prohibitively time consuming. Opening the bank vault requires two-factors: the key and the combination. Similarly, OpenBao requires multiple shares be provided to reconstruct the root key. Once unsealed, each security deposit boxes still requires that the owner provide a key, and similarly the OpenBao ACL system protects all the secrets stored.