Security

We do our best with OpenBao Charms to ensure that security is a consideration at every level, and prevent common pitfalls. By default, OpenBao Charms enables TLS communication and uses restricted policies to limit the access of the Charm and the credentials it generates to the necessary privileges.

This document will cover the security implications of using OpenBao Charms, and how to mitigate them. However, it is not a comprehensive security guide for OpenBao.

Since OpenBao Charms is built on top of OpenBao, many of the security considerations are inherited from OpenBao itself, and you should refer to the OpenBao documentation for further details outside of what is discussed here.

OpenBao Charms Built-in Security Features

  • Built using a bare-bones, distroless OpenBao ROCK image which is regularly built and scanned for vulnerabilities

  • TLS 1.3 encrypted communication amongst the OpenBao units, and any communication channels between clients the OpenBao server

  • Policies that restrict the access of the Charm to only the essential operations

  • Policies that restrict the access of credentials generated by the charm to the minimum set of operations needed.

  • Canonical Observability Stack integration

  • Audit logging

  • Short-lived token TTLs

Some Best Practices to be Aware of

Authorize the Charm with a short lived token

During initial configuration of the Charm, you will need to provide the Charm with a token that has broad permissions, so that the charm can properly configure itself. This token should be short-lived, and can be revoked as soon as the Charm is configured. The Charm will generate its own credentials with limited permissions, which will be used for all subsequent operations.

The token must be passed using Juju secrets, which ensures that the transfer of this token to the Charm is secure.

openbao token create -ttl=5m
juju add-secret one-time-token token=$token
juju grant-secret one-time-token openbao
juju run openbao/leader authorize-charm secret-id=$juju_secret_id
juju remove-secret one-time-token

Handling Unseal Keys

Ensure that the unseal keys are not a single source of failure or loss. Due to the overhead of unsealing, you may wish to use auto-unseal in enterprise environments.

When to use Auto-unseal

Auto-unseal is a feature of OpenBao that allows you to automatically unseal the OpenBao using another OpenBao. While this may initially seem redundant, it is a useful feature for enterprise environments where the overhead of unsealing is too high for each individual instance, but there is access to a secure, trusted, and highly available OpenBao managed by a dedicated team.

This option may be the right choice if the “auto-unsealer” OpenBao:

  1. Is fully trusted to handle the decryption keys of your OpenBao

  2. Has minimal downtime

  3. Has processes in place to ensure that new nodes can be unsealed promptly when necessary

For example, you may have a corporate OpenBao that is tightly monitored and maintained 24/7. In this case, your OpenBao may “piggy-back” off this corporate OpenBao’s existing availability and security and trust it to manage the unseal keys. Auto-unseal will allow your OpenBao to be unsealed automatically, provided it can communicate with the corporate OpenBao and has the appropriate credentials.

On machine deployments, PKCS#11 HSM auto-unseal is an alternative that keeps unseal material in hardware. That configuration is also one-way: you cannot return to Shamir after OpenBao has been initialized with PKCS#11.