Secret backend

[tmihoc (Teodora Mihoc)]

Secret > Secret backend

See also: How to manage secret backends

A secret backend is a service that is used to store sensitive content which Juju manages as secrets.

Secret backends are per model.

A secret backend is identified by a name and a type, and admits various configuration options, some of them generic and some backend-type-specific.

Contents:

• Name
• Type
• Configuration options

Name

The name of a secret backend can be:

• auto (i.e., internal for machine models and local for Kubernetes models)
• internal
• <some custom name>

The name is set via the secret-backend model configuration key.

See more: List of model configuration keys

Type

The type of a secret backend can be:

• controller
• kubernetes
• vault

For production use, we recommend Vault.

controller

The controller backend is the Juju model database.

It is the default secret backend for machine (VM) models.

kubernetes

The kubernetes backend is the model’s Kubernetes namespace.

It is the default secret backend for container (Kubernetes) models.

Available starting with Juju 3.1.

vault

The vault backend refers to the Hashicorp Vault.

It is available as an opt-in to both machine (VM) and container (Kubernetes) models.

Available starting with Juju 3.1.

Configuration options

• Generic
• Backend-specific

Generic

The generic configuration keys currently include just the following:

token-rotate	The maximum period for which an access token is valid for. Some time prior to the token expiring Juju will generate a new one. Possible values: standard Go duration (e.g., 2h, 7d). The minimum is 1h.

The vault backend is the only one that supports it for now.

Backend-specific

The vault backend is the only one that supports specific configuration keys. These are:

ca-cert	The path to a PEM-encoded CA certificate file on the local disk. This file is used to verify the Vault server’s SSL certificate.
client-cert	The path to a PEM-encoded client certificate on the local disk. This file is used for TLS communication with the Vault server.
client-key	The path to an unencrypted, PEM-encoded private key on disk which corresponds to the matching client certificate.
endpoint
namespace	The namespace to use for the command. Setting this is not necessary but allows using relative paths.
tls-server-name	The name to use as the SNI host when connecting via TLS.
token	The vault authentication token.

See more: Vault | vault server, Hashicorp | Vault commands.
(You will see more options there as we currently support only support a subset.)

A minimum configuration must include the endpoint and token. However, just that would not be insecure, as it wouldn’t establish an encrypted TLS connection to Vault. For production you should configure your Vault securely, following recommendations in the upstream Vault documentation.