vault Block
Placement | vault |
The vault
block configures Nomad's integration with HashiCorp's
Vault. When configured, tasks can use workload
identities to receive Vault ACL tokens automatically.
Alternatively, Nomad servers may be configured with a high-privileged Vault token that is used to derive fine-grained tokens for tasks. Refer to Token-based Authentication for configuration details. This workflow is deprecated and will be removed in a future version of Nomad. Using using workload identities is strongly recommended as it is easier to manage and more secure.
Refer to the Nomad and Vault Integration page for more information about the Vault integration.
In Nomad Enterprise, you may specify multiple vault
blocks to configure access
to multiple Vault clusters. Each Vault cluster must have a different value for
the name
field.
vault
Parameters
Some parameters are expected to be specified in the configuration file of Nomad agents running as clients, servers, or in all agents. Parameters are safely ignored if placed in a configuration file where they are not expected to be defined.
The placement also depends on the authentication strategy used. This section describes the parameter organization for workload identity authentication. Refer to the Token-based Authentication section if using Vault tokens directly.
Parameters for Nomad Clients and Servers
These parameters should be defined in the configuration file of all Nomad agents.
name
(string: "default")
Enterprise - Specifies a name for the cluster so it can be referred to by job submitters in the job specification'svault.cluster
field. In Nomad Community Edition, only the"default"
cluster will be used, so this field should be omitted.enabled
(bool: false)
- Specifies if the Vault integration should be activated.create_from_role
(string: "")
- Specifies the role to create tokens from.When using workload identities this field defines the role used to derive task tokens when the job does not define a value for
vault.role
. If empty, the default Vault cluster role is used.For token-based authentication, the Nomad servers derive tokens using this role. The token given to Nomad does not have to be created from this role but must have
update
capability onauth/token/create/<create_from_role>
path in Vault. If this value is unset and the token is created from a role, the value is defaulted to the role the token is from.Note: This used to be a server-only field, but it is client-only when using workload identities. It should be set in both while transitioning from token-based authentication to workload identities.
Parameters for Nomad Clients
These parameters should only be defined in the configuration file of Nomad
agents with client.enabled
set to true
.
namespace
(string: "")
- Specifies the Vault namespace used by the Vault integration. If non-empty, this namespace will be used on all Vault API calls.address
-(string: "https://vault.service.consul:8200")
- Specifies the address to the Vault server. This must include the protocol, host/ip, and port given in the formatprotocol://host:port
. If your Vault installation is behind a load balancer, this should be the address of the load balancer.ca_file
(string: "")
- Specifies an optional path to the CA certificate used for Vault communication. If unspecified, this will fallback to the default system CA bundle, which varies by OS and version.ca_path
(string: "")
- Specifies an optional path to a folder containing CA certificates to be used for Vault communication. If unspecified, this will fallback to the default system CA bundle, which varies by OS and version.cert_file
(string: "")
- Specifies the path to the certificate used for Vault communication. This must be set if tls_require_and_verify_client_cert is enabled in Vault.key_file
(string: "")
- Specifies the path to the private key used for Vault communication. If this is set then you need to also setcert_file
. This must be set if tls_require_and_verify_client_cert is enabled in Vault.tls_server_name
(string: "")
- Specifies an optional string used to set the SNI host when connecting to Vault via TLS.tls_skip_verify
(bool: false)
- Specifies if SSL peer validation should be enforced.It is strongly discouraged to disable SSL verification. Instead, you should install a custom CA bundle and validate against it. Disabling SSL verification can allow an attacker to easily compromise your cluster.
Parameters for Nomad Servers
These parameters should only be defined in the configuration file of Nomad
agents with server.enabled
set to true
.
use_identity
(bool: false)
- If set totrue
, Nomad uses workload identities to generate Vault ACL tokens. Iffalse
the deprecated token-based flow is used.default_identity
(Identity: nil)
- Specifies the default workload identity configuration to use when a task with avault
block does not specify anidentity
block namedvault
.
Deprecated Parameters
These parameters are used by the deprecated token-based authentication flow and will be removed in a future release.
allow_unauthenticated
(bool: true)
- Specifies if users submitting jobs to the Nomad server should be required to provide their own Vault token, proving they have access to the policies listed in the job. This option should be disabled in an untrusted environment.task_token_ttl
(string: "72h")
- Specifies the TTL of created tokens when using a root token. This is specified using a label suffix like "30s" or "1h".token
(string: "")
- Specifies the parent Vault token to use to derive child tokens for jobs requesting tokens. Only required on Nomad servers. Nomad client agents use the allocation's token when contacting Vault. Visit the Vault Integration Guide to see how to generate an appropriate token in Vault.It is strongly discouraged to place the token as a configuration parameter like this, since the token could be checked into source control accidentally. Users should set the
VAULT_TOKEN
environment variable when starting the agent instead.
default_identity
Parameters
aud
(array<string>: [])
- List of valid recipients for this workload identity. This value must match thebound_audiences
configuration in the Vault JWT auth method. It is recommended to provide one, and only one, audience to minimize where the identity may be used.env
(bool: false)
- If true the workload identity will be available in the task'sNOMAD_TOKEN_vault
environment variable.file
(bool: false)
- If true the workload identity will be available in the task's filesystem via the pathsecrets/nomad_vault.jwt
. If thetask.user
parameter is set, the token file will only be readable by that user. Otherwise the file is readable by everyone but is protected by parent directory permissions.ttl
(string: "")
- Specifies for how long the workload identity should be considered as valid before expiring.
Token-based Authentication
Warning: The token-based authentication flow is deprecated and will be removed in a future release. It is highly recommended to migrate and use the workload identity flow instead.
When using token-based authentication the vault
block parameters should be
defined as below.
Parameters for Nomad Clients and Servers
Parameters for Nomad Servers
vault
Examples
The following examples only show the vault
blocks. Remember that the
vault
block is only valid in the placements listed above.
Nomad Server
This example shows a Vault configuration for a Nomad server using the workload identity authentication flow.
This example shows a Vault configuration for a Nomad server using the deprecated token-based authentication flow.
Nomad Client
This example shows a Vault configuration for a Nomad client.
vault
Configuration Reloads
The Vault configuration can be reloaded on servers. This can be useful if a new
token needs to be given to the servers without having to restart them. A reload
can be accomplished by sending the process a SIGHUP
signal.