Security in Charmed Vault

We do our best with Charmed Vault to ensure that security is a consideration at every level, and prevent common pitfalls. By default, Charmed Vault 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 Charmed Vault, and how to mitigate them. However, it is not a comprehensive security guide for Vault.

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

Charmed Vault Built-in Security Features

• Built using a bare-bones, distroless Vault ROCK image which is regularly built and scanned for vulnerabilities
• TLS 1.3 encrypted communication amongst the Vault units, and any communication channels between clients the Vault 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.

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

Handling Unseal Keys

We recommended you follow HashiCorp’s guidance on unseal keys. Specifically, 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 Vault that allows you to automatically unseal the Vault using another Vault. 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 Vault managed by a dedicated team.

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

1. Is fully trusted to handle the decryption keys of your Vault
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 Vault that is tightly monitored and maintained 24/7. In this case, your Vault may “piggy-back” off this corporate Vault’s existing availability and security and trust it to manage the unseal keys. Auto-unseal will allow your Vault to be unsealed automatically, provided it can communicate with the corporate Vault and has the appropriate credentials.