---
layout: "docs"
page_title: "Configuration"
sidebar_current: "docs-agent-config"
description: |-
The agent has various configuration options that can be specified via the command-line or via configuration files. All of the configuration options are completely optional. Defaults are specified with their descriptions.
---
# Configuration
The agent has various configuration options that can be specified via
the command-line or via configuration files. All of the configuration
options are completely optional. Defaults are specified with their
descriptions.
Configuration precedence is evaluated in the following order:
1. Command line arguments
2. Environment Variables
3. Configuration files
When loading configuration, Consul loads the configuration from files and
directories in lexical order. For example, configuration file
`basic_config.json` will be processed before `extra_config.json`. Configuration
can be in either [HCL](https://github.com/hashicorp/hcl#syntax) or JSON format.
Available in Consul 1.0 and later, the HCL support now requires an `.hcl` or
`.json` extension on all configuration files in order to specify their format.
Configuration specified later will be merged into configuration specified
earlier. In most cases, "merge" means that the later version will override the
earlier. In some cases, such as event handlers, merging appends the handlers to
the existing configuration. The exact merging behavior is specified for each
option below.
Consul also supports reloading configuration when it receives the
SIGHUP signal. Not all changes are respected, but those that are
documented below in the
[Reloadable Configuration](#reloadable-configuration) section. The
[reload command](/docs/commands/reload.html) can also be used to trigger a
configuration reload.
You can test the following configuration options by following the [Getting Started](https://learn.hashicorp.com/consul/getting-started/install?utm_source=consul.io&utm_medium=docs) guides to install a local agent.
## Command-line Options
The options below are all specified on the command-line.
* `-advertise` - The
advertise address is used to change the address that we advertise to other
nodes in the cluster. By default, the [`-bind`](#_bind) address is advertised.
However, in some cases, there may be a routable address that cannot be bound.
This flag enables gossiping a different address to support this. If this
address is not routable, the node will be in a constant flapping state as
other nodes will treat the non-routability as a failure. In Consul 1.0 and
later this can be set to a
[go-sockaddr](https://godoc.org/github.com/hashicorp/go-sockaddr/template)
template.
* `-advertise-wan` - The
advertise WAN address is used to change the address that we advertise to server nodes
joining through the WAN. This can also be set on client agents when used in combination
with the `translate_wan_addrs` configuration
option. By default, the [`-advertise`](#_advertise) address is advertised. However, in some
cases all members of all datacenters cannot be on the same physical or virtual network,
especially on hybrid setups mixing cloud and private datacenters. This flag enables server
nodes gossiping through the public network for the WAN while using private VLANs for gossiping
to each other and their client agents, and it allows client agents to be reached at this
address when being accessed from a remote datacenter if the remote datacenter is configured
with `translate_wan_addrs`. In Consul 1.0 and
later this can be set to a
[go-sockaddr](https://godoc.org/github.com/hashicorp/go-sockaddr/template)
template
* `-bootstrap` - This flag is used to control if a
server is in "bootstrap" mode. It is important that
no more than one server *per* datacenter be running in this mode. Technically, a server in bootstrap mode
is allowed to self-elect as the Raft leader. It is important that only a single node is in this mode;
otherwise, consistency cannot be guaranteed as multiple nodes are able to self-elect.
It is not recommended to use this flag after a cluster has been bootstrapped.
* `-bootstrap-expect` - This flag
provides the number of expected servers in the datacenter.
Either this value should not be provided or the value must agree with other servers in
the cluster. When provided, Consul waits until the specified number of servers are
available and then bootstraps the cluster. This allows an initial leader to be elected
automatically. This cannot be used in conjunction with the legacy [`-bootstrap`](#_bootstrap) flag.
This flag requires [`-server`](#_server) mode.
* `-bind` - The address that should be bound to
for internal cluster communications.
This is an IP address that should be reachable by all other nodes in the cluster.
By default, this is "0.0.0.0", meaning Consul will bind to all addresses on
the local machine and will [advertise](/docs/agent/options.html#_advertise)
the private IPv4 address to the rest of the cluster. If there
are multiple private IPv4 addresses available, Consul will exit with an error
at startup. If you specify "[::]", Consul will [advertise](/docs/agent/options.html#_advertise)
the public IPv6 address.
If there are multiple public IPv6 addresses available, Consul will exit with an error at startup.
Consul uses both TCP and UDP and the same port for both. If you have any firewalls,
be sure to allow both protocols. In Consul 1.0 and later this can be set to a
[go-sockaddr](https://godoc.org/github.com/hashicorp/go-sockaddr/template)
template that needs to resolve to a single address. Some example templates:
```sh
# Using address within a specific CIDR
$ consul agent -bind '{{ GetPrivateInterfaces | include "network" "10.0.0.0/8" | attr "address" }}'
```
```sh
# Using a static network interface name
$ consul agent -bind '{{ GetInterfaceIP "eth0" }}'
```
```sh
# Using regular expression matching for network interface name that is forwardable and up
$ consul agent -bind '{{ GetAllInterfaces | include "name" "^eth" | include "flags" "forwardable|up" | attr "address" }}'
```
* `-serf-wan-bind` -
The address that should be bound to for Serf WAN gossip communications. By
default, the value follows the same rules as [`-bind` command-line
flag](#_bind), and if this is not specified, the `-bind` option is used. This
is available in Consul 0.7.1 and later. In Consul 1.0 and later this can be
set to a
[go-sockaddr](https://godoc.org/github.com/hashicorp/go-sockaddr/template)
template
* `-serf-lan-bind` -
The address that should be bound to for Serf LAN gossip communications. This
is an IP address that should be reachable by all other LAN nodes in the
cluster. By default, the value follows the same rules as [`-bind` command-line
flag](#_bind), and if this is not specified, the `-bind` option is used. This
is available in Consul 0.7.1 and later. In Consul 1.0 and later this can be
set to a
[go-sockaddr](https://godoc.org/github.com/hashicorp/go-sockaddr/template)
template
* `-check_output_max_size` -
Override the default limit of 4k for maximum size of checks, this is a positive
value.
By limiting this size, it allows to put less pressure on Consul servers when
many checks are having a very large output in their checks.
In order to completely disable check output capture, it is possible to
use `discard_check_output`.
* `-client` - The address to which
Consul will bind client interfaces, including the HTTP and DNS servers. By
default, this is "127.0.0.1", allowing only loopback connections. In Consul
1.0 and later this can be set to a space-separated list of addresses to bind
to, or a
[go-sockaddr](https://godoc.org/github.com/hashicorp/go-sockaddr/template)
template that can potentially resolve to multiple addresses.
* `-config-file` - A configuration file
to load. For more information on
the format of this file, read the [Configuration Files](#configuration_files) section.
This option can be specified multiple times to load multiple configuration
files. If it is specified multiple times, configuration files loaded later
will merge with configuration files loaded earlier. During a config merge,
single-value keys (string, int, bool) will simply have their values replaced
while list types will be appended together.
* `-config-dir` - A directory of
configuration files to load. Consul will
load all files in this directory with the suffix ".json" or ".hcl". The load order
is alphabetical, and the the same merge routine is used as with the
[`config-file`](#_config_file) option above. This option can be specified multiple times
to load multiple directories. Sub-directories of the config directory are not loaded.
For more information on the format of the configuration files, see the
[Configuration Files](#configuration_files) section.
* `-config-format` - The format
of the configuration files to load. Normally, Consul detects the format of the
config files from the ".json" or ".hcl" extension. Setting this option to
either "json" or "hcl" forces Consul to interpret any file with or without
extension to be interpreted in that format.
* `-data-dir` - This flag
provides a data directory for the agent to store state. This is required for
all agents. The directory should be durable across reboots. This is especially
critical for agents that are running in server mode as they must be able to
persist cluster state. Additionally, the directory must support the use of
filesystem locking, meaning some types of mounted folders (e.g. VirtualBox
shared folders) may not be suitable. **Note:** both server and non-server
agents may store ACL tokens in the state in this directory so read access may
grant access to any tokens on servers and to any tokens used during service
registration on non-servers. On Unix-based platforms the files are written
with 0600 permissions so you should ensure only trusted processes can execute
as the same user as Consul. On Windows, you should ensure the directory has
suitable permissions configured as these will be inherited.
* `-datacenter` - This flag controls the datacenter in
which the agent is running. If not provided,
it defaults to "dc1". Consul has first-class support for multiple datacenters, but
it relies on proper configuration. Nodes in the same datacenter should be on a single
LAN.
* `-dev` - Enable development server
mode. This is useful for quickly starting a Consul agent with all persistence
options turned off, enabling an in-memory server which can be used for rapid
prototyping or developing against the API. In this mode, [Connect is
enabled](/docs/connect/configuration.html) and will by default create a new
root CA certificate on startup. This mode is **not** intended for production
use as it does not write any data to disk. The gRPC port is also defaulted to
`8502` in this mode.
* `-disable-host-node-id` - Setting
this to true will prevent Consul from using information from the host to generate a deterministic node ID,
and will instead generate a random node ID which will be persisted in the data directory. This is useful
when running multiple Consul agents on the same host for testing. This defaults to false in Consul prior
to version 0.8.5 and in 0.8.5 and later defaults to true, so you must opt-in for host-based IDs. Host-based
IDs are generated using https://github.com/shirou/gopsutil/tree/master/host, which is shared with HashiCorp's
[Nomad](https://www.nomadproject.io/), so if you opt-in to host-based IDs then Consul and Nomad will use
information on the host to automatically assign the same ID in both systems.
* `-disable-keyring-file` - If set,
the keyring will not be persisted to a file. Any installed keys will be lost on shutdown, and only the given
`-encrypt` key will be available on startup. This defaults to false.
* `-dns-port` - the DNS port to listen on.
This overrides the default port 8600. This is available in Consul 0.7 and later.
* `-domain` - By default, Consul responds to DNS queries
in the "consul." domain. This flag can be used to change that domain. All queries in this domain
are assumed to be handled by Consul and will not be recursively resolved.
* `-alt-domain` - This flag allows Consul to respond to
DNS queries in an alternate domain, in addition to the primary domain. If unset, no alternate domain is used.
* `-enable-script-checks` This controls
whether [health checks that execute scripts](/docs/agent/checks.html) are
enabled on this agent, and defaults to `false` so operators must opt-in to
allowing these. This was added in Consul 0.9.0.
~> **Security Warning:** Enabling script checks in some configurations may
introduce a remote execution vulnerability which is known to be targeted by
malware. We strongly recommend `-enable-local-script-checks` instead. See [this
blog post](https://www.hashicorp.com/blog/protecting-consul-from-rce-risk-in-specific-configurations)
for more details.
* `-enable-local-script-checks`
Like [`enable_script_checks`](#_enable_script_checks), but only enable them when they are defined in the local
configuration files. Script checks defined in HTTP API registrations will still not be allowed.
* `-encrypt` - Specifies the secret key to
use for encryption of Consul
network traffic. This key must be 32-bytes that are Base64-encoded. The
easiest way to create an encryption key is to use
[`consul keygen`](/docs/commands/keygen.html). All
nodes within a cluster must share the same encryption key to communicate.
The provided key is automatically persisted to the data directory and loaded
automatically whenever the agent is restarted. This means that to encrypt
Consul's gossip protocol, this option only needs to be provided once on each
agent's initial startup sequence. If it is provided after Consul has been
initialized with an encryption key, then the provided key is ignored and
a warning will be displayed.
* `-grpc-port` - the gRPC API
port to listen on. Default -1 (gRPC disabled). See [ports](#ports)
documentation for more detail.
* `-hcl` - A HCL configuration fragment.
This HCL configuration fragment is appended to the configuration and allows
to specify the full range of options of a config file on the command line.
This option can be specified multiple times. This was added in Consul 1.0.
* `-http-port` - the HTTP API port to listen on.
This overrides the default port 8500. This option is very useful when deploying Consul
to an environment which communicates the HTTP port through the environment e.g. PaaS like CloudFoundry, allowing
you to set the port directly via a Procfile.
* `-log-file` - to redirect all the Consul agent log messages to a file. This can be specified with the complete path along with the name of the log. In case the path doesn't have the filename, the filename defaults to `consul-{timestamp}.log`. Can be combined with -log-rotate-bytes and -log-rotate-duration for a fine-grained log rotation experience.
* `-log-rotate-bytes` - to specify the number of bytes that should be written to a log before it needs to be rotated. Unless specified, there is no limit to the number of bytes that can be written to a log file.
* `-log-rotate-duration` - to specify the maximum duration a log should be written to before it needs to be rotated. Must be a duration value such as 30s. Defaults to 24h.
* `-log-rotate-max-files` - to specify the maximum number of older log file archives to keep. Defaults to 0 (no files are ever deleted). Set to -1 to disable rotation and discard all log files.
* `-join` - Address of another agent
to join upon starting up. This can be
specified multiple times to specify multiple agents to join. If Consul is
unable to join with any of the specified addresses, agent startup will
fail. By default, the agent won't join any nodes when it starts up.
Note that using
`retry_join` could be more appropriate to help
mitigate node startup race conditions when automating a Consul cluster
deployment.
In Consul 1.1.0 and later this can be set to a
[go-sockaddr](https://godoc.org/github.com/hashicorp/go-sockaddr/template)
template
* `-retry-join` - Similar to [`-join`](#_join) but allows retrying a join if the
first attempt fails. This is useful for cases where you know the address will
eventually be available. The list can contain IPv4, IPv6, or DNS addresses. In
Consul 1.1.0 and later this can be set to a
[go-sockaddr](https://godoc.org/github.com/hashicorp/go-sockaddr/template)
template. If Consul is running on the non-default Serf LAN port, this must be
specified as well. IPv6 must use the "bracketed" syntax. If multiple values
are given, they are tried and retried in the order listed until the first
succeeds. Here are some examples:
```sh
# Using a DNS entry
$ consul agent -retry-join "consul.domain.internal"
```
```sh
# Using IPv4
$ consul agent -retry-join "10.0.4.67"
```
```sh
# Using IPv6
$ consul agent -retry-join "[::1]:8301"
```
### Cloud Auto-Joining
As of Consul 0.9.1, `retry-join` accepts a unified interface using the
[go-discover](https://github.com/hashicorp/go-discover) library for doing
automatic cluster joining using cloud metadata. For more information, see
the [Cloud Auto-join page](/docs/agent/cloud-auto-join.html).
```sh
# Using Cloud Auto-Joining
$ consul agent -retry-join "provider=aws tag_key=..."
```
* `-retry-interval` - Time
to wait between join attempts. Defaults to 30s.
* `-retry-max` - The maximum number
of [`-join`](#_join) attempts to be made before exiting
with return code 1. By default, this is set to 0 which is interpreted as infinite
retries.
* `-join-wan` - Address of
another wan agent to join upon starting up. This can be specified multiple
times to specify multiple WAN agents to join. If Consul is unable to join with
any of the specified addresses, agent startup will fail. By default, the agent
won't [`-join-wan`](#_join_wan) any nodes when it starts up.
In Consul 1.1.0 and later this can be set to a
[go-sockaddr](https://godoc.org/github.com/hashicorp/go-sockaddr/template)
template.
* `-retry-join-wan` - Similar
to [`retry-join`](#_retry_join) but allows retrying a wan join if the first attempt fails.
This is useful for cases where we know the address will become available eventually.
As of Consul 0.9.3 [Cloud Auto-Joining](#cloud-auto-joining) is supported as well.
In Consul 1.1.0 and later this can be set to a
[go-sockaddr](https://godoc.org/github.com/hashicorp/go-sockaddr/template)
template
* `-retry-interval-wan` - Time
to wait between [`-join-wan`](#_join_wan) attempts.
Defaults to 30s.
* `-retry-max-wan` - The maximum
number of [`-join-wan`](#_join_wan) attempts to be made before exiting with return code 1.
By default, this is set to 0 which is interpreted as infinite retries.
* `-log-level` - The level of logging to
show after the Consul agent has started. This defaults to "info". The available log levels are
"trace", "debug", "info", "warn", and "err". You can always connect to an
agent via [`consul monitor`](/docs/commands/monitor.html) and use any log level. Also, the
log level can be changed during a config reload.
* `-node` - The name of this node in the cluster.
This must be unique within the cluster. By default this is the hostname of the machine.
* `-node-id` - Available in Consul 0.7.3 and later, this
is a unique identifier for this node across all time, even if the name of the node or address
changes. This must be in the form of a hex string, 36 characters long, such as
`adf4238a-882b-9ddc-4a9d-5b6758e4159e`. If this isn't supplied, which is the most common case, then
the agent will generate an identifier at startup and persist it in the data directory
so that it will remain the same across agent restarts. Information from the host will be used to
generate a deterministic node ID if possible, unless [`-disable-host-node-id`](#_disable_host_node_id) is
set to true.
* `-node-meta` - Available in Consul 0.7.3 and later,
this specifies an arbitrary metadata key/value pair to associate with the node, of the form `key:value`.
This can be specified multiple times. Node metadata pairs have the following restrictions:
- A maximum of 64 key/value pairs can be registered per node.
- Metadata keys must be between 1 and 128 characters (inclusive) in length
- Metadata keys must contain only alphanumeric, `-`, and `_` characters.
- Metadata keys must not begin with the `consul-` prefix; that is reserved for internal use by Consul.
- Metadata values must be between 0 and 512 (inclusive) characters in length.
- Metadata values for keys beginning with `rfc1035-` are encoded verbatim in DNS TXT requests, otherwise
the metadata kv-pair is encoded according [RFC1464](https://www.ietf.org/rfc/rfc1464.txt).
* `-pid-file` - This flag provides the file
path for the agent to store its PID. This is useful for sending signals (for example, `SIGINT`
to close the agent or `SIGHUP` to update check definite
* `-protocol` - The Consul protocol version to
use. This defaults to the latest version. This should be set only when [upgrading](/docs/upgrading.html).
You can view the protocol versions supported by Consul by running `consul -v`.
* `-raft-protocol` - This controls the internal
version of the Raft consensus protocol used for server communications. This must be set to 3 in order to
gain access to Autopilot features, with the exception of [`cleanup_dead_servers`](#cleanup_dead_servers).
Defaults to 3 in Consul 1.0.0 and later (defaulted to 2 previously). See
[Raft Protocol Version Compatibility](/docs/upgrade-specific.html#raft-protocol-version-compatibility)
for more details.
* `-recursor` - Specifies the address of an upstream DNS
server. This option may be provided multiple times, and is functionally
equivalent to the [`recursors` configuration option](#recursors).
* `-rejoin` - When provided, Consul will ignore a
previous leave and attempt to rejoin the cluster when starting. By default, Consul treats leave
as a permanent intent and does not attempt to join the cluster again when starting. This flag
allows the previous state to be used to rejoin the cluster.
* `-segment` - (Enterprise-only) This flag is used to set
the name of the network segment the agent belongs to. An agent can only join and communicate with other agents
within its network segment. See the [Network Segments Guide](https://learn.hashicorp.com/consul/day-2-operations/network-segments) for more details.
By default, this is an empty string, which is the default network segment.
* `-serf-lan-port` - the Serf LAN port to listen on.
This overrides the default Serf LAN port 8301. This is available in Consul 1.2.2 and later.
* `-serf-wan-port` - the Serf WAN port to listen on.
This overrides the default Serf WAN port 8302. This is available in Consul 1.2.2 and later.
* `-server` - This flag is used to control if an
agent is in server or client mode. When provided,
an agent will act as a Consul server. Each Consul cluster must have at least one server and ideally
no more than 5 per datacenter. All servers participate in the Raft consensus algorithm to ensure that
transactions occur in a consistent, linearizable manner. Transactions modify cluster state, which
is maintained on all server nodes to ensure availability in the case of node failure. Server nodes also
participate in a WAN gossip pool with server nodes in other datacenters. Servers act as gateways
to other datacenters and forward traffic as appropriate.
* `-server-port` - the server RPC port to listen on.
This overrides the default server RPC port 8300. This is available in Consul 1.2.2 and later.
* `-non-voting-server` - (Enterprise-only)
This flag is used to make the server not participate in the Raft quorum, and have it only receive the data
replication stream. This can be used to add read scalability to a cluster in cases where a high volume of
reads to servers are needed.
* `-syslog` - This flag enables logging to syslog. This
is only supported on Linux and OSX. It will result in an error if provided on Windows.
* `-ui` - Enables the built-in web UI
server and the required HTTP routes. This eliminates the need to maintain the
Consul web UI files separately from the binary.
* `-ui-dir` - This flag provides the directory containing
the Web UI resources for Consul. This will automatically enable the Web UI. The directory must be
readable to the agent. Starting with Consul version 0.7.0 and later, the Web UI assets are included in the binary so this flag is no longer necessary; specifying only the `-ui` flag is enough to enable the Web UI. Specifying both the '-ui' and '-ui-dir' flags will result in an error.
* `-ui-content-path` - This flag provides the option to change the path the Consul UI loads from and will be displayed in the browser. By default, the path is `/ui/`, for example `http://localhost:8500/ui/`. Only alphanumerics, `-`, and `_` are allowed in a custom path. `/v1/` is not allowed as it would overwrite the API endpoint.
## Configuration Files
In addition to the command-line options, configuration can be put into
files. This may be easier in certain situations, for example when Consul is
being configured using a configuration management system.
The configuration files are JSON formatted, making them easily readable
and editable by both humans and computers. The configuration is formatted
as a single JSON object with configuration within it.
Configuration files are used for more than just setting up the agent,
they are also used to provide check and service definitions. These are used
to announce the availability of system servers to the rest of the cluster.
They are documented separately under [check configuration](/docs/agent/checks.html) and
[service configuration](/docs/agent/services.html) respectively. The service and check
definitions support being updated during a reload.
#### Example Configuration File
```javascript
{
"datacenter": "east-aws",
"data_dir": "/opt/consul",
"log_level": "INFO",
"node_name": "foobar",
"server": true,
"watches": [
{
"type": "checks",
"handler": "/usr/bin/health-check-handler.sh"
}
],
"telemetry": {
"statsite_address": "127.0.0.1:2180"
}
}
```
#### Example Configuration File, with TLS
```javascript
{
"datacenter": "east-aws",
"data_dir": "/opt/consul",
"log_level": "INFO",
"node_name": "foobar",
"server": true,
"addresses": {
"https": "0.0.0.0"
},
"ports": {
"https": 8501
},
"key_file": "/etc/pki/tls/private/my.key",
"cert_file": "/etc/pki/tls/certs/my.crt",
"ca_file": "/etc/pki/tls/certs/ca-bundle.crt"
}
```
See, especially, the use of the `ports` setting:
```javascript
"ports": {
"https": 8501
}
```
Consul will not enable TLS for the HTTP API unless the `https` port has been
assigned a port number `> 0`. We recommend using `8501` for `https` as this
default will automatically work with some tooling.
#### Configuration Key Reference
* `acl` - This object allows a number
of sub-keys to be set which controls the ACL system. Configuring the
ACL system within the ACL stanza was added in Consul 1.4.0
The following sub-keys are available:
* `enabled` - Enables ACLs.
* `policy_ttl` - Used to control
Time-To-Live caching of ACL policies. By default, this is 30 seconds. This setting has a
major performance impact: reducing it will cause more frequent refreshes while increasing
it reduces the number of refreshes. However, because the caches are not actively invalidated,
ACL policy may be stale up to the TTL value.
* `role_ttl` - Used to control
Time-To-Live caching of ACL roles. By default, this is 30 seconds. This setting has a
major performance impact: reducing it will cause more frequent refreshes while increasing
it reduces the number of refreshes. However, because the caches are not actively invalidated,
ACL role may be stale up to the TTL value.
* `token_ttl` - Used to control
Time-To-Live caching of ACL tokens. By default, this is 30 seconds. This setting has a
major performance impact: reducing it will cause more frequent refreshes while increasing
it reduces the number of refreshes. However, because the caches are not actively invalidated,
ACL token may be stale up to the TTL value.
* `down_policy` - Either
"allow", "deny", "extend-cache" or "async-cache"; "extend-cache" is the default. In the case that a
policy or token cannot be read from the [`primary_datacenter`](#primary_datacenter) or leader
node, the down policy is applied. In "allow" mode, all actions are permitted, "deny" restricts
all operations, and "extend-cache" allows any cached objects to be used, ignoring their TTL
values. If a non-cached ACL is used, "extend-cache" acts like "deny".
The value "async-cache" acts the same way as "extend-cache" but performs updates
asynchronously when ACL is present but its TTL is expired, thus, if latency is bad between
the primary and secondary datacenters, latency of operations is not impacted.
* `default_policy` - Either
"allow" or "deny"; defaults to "allow" but this will be changed in a future major release.
The default policy controls the behavior of a token when there is no matching rule. In "allow" mode,
ACLs are a blacklist: any operation not specifically prohibited is allowed. In "deny" mode, ACLs are
a whitelist: any operation not specifically allowed is blocked. *Note*: this will not take effect until
you've enabled ACLs.
* `enable_key_list_policy` - Either "enabled" or "disabled", defaults to "disabled". When enabled, the `list` permission will be required on the prefix being recursively read from the KV store. Regardless of being enabled, the full set of KV entries under the prefix will be filtered to remove any entries that the request's ACL token does not grant at least read permissions. This option is only available in Consul 1.0 and newer.
* `enable_token_replication` - By
default secondary Consul datacenters will perform replication of only ACL policies and roles.
Setting this configuration will will enable ACL token replication and
allow for the creation of both [local tokens](/api/acl/tokens.html#local)
and [auth methods](/docs/acl/acl-auth-methods.html) in connected secondary
datacenters.
* `enable_token_persistence` - Either
`true` or `false`. When `true` tokens set using the API will be persisted to disk and reloaded when an agent restarts.
* `tokens` - This object holds
all of the configured ACL tokens for the agents usage.
* `master` - Only used
for servers in the [`primary_datacenter`](#primary_datacenter). This token will be created with management-level
permissions if it does not exist. It allows operators to bootstrap the ACL system
with a token Secret ID that is well-known.
The `master` token is only installed when a server acquires cluster leadership. If
you would like to install or change the `acl_master_token`, set the new value for `master`
in the configuration for all servers. Once this is done, restart the current leader to force a
leader election. If the `master` token is not supplied, then the servers do not create a master
token. When you provide a value, it should be a UUID. To maintain backwards compatibility
and an upgrade path this restriction is not currently enforced but will be in a future major
Consul release.
* `default` - When provided,
the agent will use this token when making requests to the Consul servers. Clients can
override this token on a per-request basis by providing the "?token" query parameter.
When not provided, the empty token, which maps to the 'anonymous' ACL token, is used.
* `agent` - Used for clients
and servers to perform internal operations. If this isn't specified, then the
`default` will be used.
This token must at least have write access to the node name it will register as in order to set any
of the node-level information in the catalog such as metadata, or the node's tagged addresses.
* `agent_master` -
Used to access agent endpoints that require agent read
or write privileges, or node read privileges, even if Consul servers aren't present to validate
any tokens. This should only be used by operators during outages, regular ACL tokens should normally
be used by applications.
* `replication` -
The ACL token used to authorize secondary datacenters with the primary datacenter for replication
operations. This token is required for servers outside the [`primary_datacenter`](#primary_datacenter) when
ACLs are enabled. This token may be provided later using the [agent token API](/api/agent.html#update-acl-tokens)
on each server. This token must have at least "read" permissions on ACL data but if ACL
token replication is enabled then it must have "write" permissions. This also enables
Connect replication, for which the token will require both operator
"write" and intention "read" permissions for replicating CA and Intention data.
* `acl_datacenter` - **This field is
deprecated in Consul 1.4.0. See the [`primary_datacenter`](#primary_datacenter) field instead.**
This designates the datacenter which is authoritative for ACL information. It must be provided to enable ACLs. All servers and datacenters must agree on the ACL datacenter. Setting it on the servers is all you need for cluster-level enforcement, but for the APIs to forward properly from the clients,
it must be set on them too. In Consul 0.8 and later, this also enables agent-level enforcement
of ACLs. Please see the [ACL Guide](https://learn.hashicorp.com/consul/security-networking/production-acls) for more details.
* `acl_default_policy` - **Deprecated in Consul 1.4.0.
See the [`acl.default_policy`](#acl_default_policy) field instead.** Either
"allow" or "deny"; defaults to "allow". The default policy controls the behavior of a token when
there is no matching rule. In "allow" mode, ACLs are a blacklist: any operation not specifically
prohibited is allowed. In "deny" mode, ACLs are a whitelist: any operation not
specifically allowed is blocked. *Note*: this will not take effect until you've set `primary_datacenter`
to enable ACL support.
* `acl_down_policy` - **Deprecated in Consul 1.4.0.
See the [`acl.down_policy`](#acl_down_policy) field instead.**Either
"allow", "deny", "extend-cache" or "async-cache"; "extend-cache" is the default. In the case that the
policy for a token cannot be read from the [`primary_datacenter`](#primary_datacenter) or leader
node, the down policy is applied. In "allow" mode, all actions are permitted, "deny" restricts
all operations, and "extend-cache" allows any cached ACLs to be used, ignoring their TTL
values. If a non-cached ACL is used, "extend-cache" acts like "deny".
The value "async-cache" acts the same way as "extend-cache" but performs updates
asynchronously when ACL is present but its TTL is expired, thus, if latency is bad between
ACL authoritative and other datacenters, latency of operations is not impacted.
* `acl_agent_master_token` -
**Deprecated in Consul 1.4.0. See the [`acl.tokens.agent_master`](#acl_tokens_agent_master) field instead.**
Used to access agent endpoints that require agent read
or write privileges, or node read privileges, even if Consul servers aren't present to validate
any tokens. This should only be used by operators during outages, regular ACL tokens should normally
be used by applications. This was added in Consul 0.7.2 and is only used when
`acl_enforce_version_8` is set to true.
* `acl_agent_token` -
**Deprecated in Consul 1.4.0. See the [`acl.tokens.agent`](#acl_tokens_agent) field instead.**
Used for clients and servers to perform internal operations. If this isn't specified, then the
`acl_token` will be used. This was added in Consul 0.7.2.
This token must at least have write access to the node name it will register as in order to set any
of the node-level information in the catalog such as metadata, or the node's tagged addresses.
* `acl_enforce_version_8` -
**Deprecated in Consul 1.4.0**
Used for clients and servers to determine if enforcement should occur for new ACL policies being
previewed before Consul 0.8. Added in Consul 0.7.2, this defaults to false in versions of
Consul prior to 0.8, and defaults to true in Consul 0.8 and later. This helps ease the
transition to the new ACL features by allowing policies to be in place before enforcement begins.
* `acl_master_token` -
**Deprecated in Consul 1.4.0. See the [`acl.tokens.master`](#acl_tokens_master) field instead.** Only used
for servers in the [`primary_datacenter`](#primary_datacenter). This token will be created with management-level
permissions if it does not exist. It allows operators to bootstrap the ACL system
with a token ID that is well-known.
The `acl_master_token` is only installed when a server acquires cluster leadership. If
you would like to install or change the `acl_master_token`, set the new value for `acl_master_token`
in the configuration for all servers. Once this is done, restart the current leader to force a
leader election. If the `acl_master_token` is not supplied, then the servers do not create a master
token. When you provide a value, it can be any string value. Using a UUID would ensure that it looks
the same as the other tokens, but isn't strictly necessary.
* `acl_replication_token` -
**Deprecated in Consul 1.4.0. See the [`acl.tokens.replication`](#acl_tokens_replication) field instead.**
Only used for servers outside the [`primary_datacenter`](#primary_datacenter) running Consul 0.7 or later.
When provided, this will enable [ACL replication](https://learn.hashicorp.com/consul/day-2-operations/acl-replication) using this
ACL replication using this
token to retrieve and replicate the ACLs to the non-authoritative local datacenter. In Consul 0.9.1
and later you can enable ACL replication using [`enable_acl_replication`](#enable_acl_replication)
and then set the token later using the [agent token API](/api/agent.html#update-acl-tokens) on each
server. If the `acl_replication_token` is set in the config, it will automatically set
[`enable_acl_replication`](#enable_acl_replication) to true for backward compatibility.
If there's a partition or other outage affecting the authoritative datacenter, and the
[`acl_down_policy`](/docs/agent/options.html#acl_down_policy) is set to "extend-cache", tokens not
in the cache can be resolved during the outage using the replicated set of ACLs.
* `acl_token` -
**Deprecated in Consul 1.4.0. See the [`acl.tokens.default`](#acl_tokens_default) field instead.**
When provided, the agent will use this
token when making requests to the Consul servers. Clients can override this token on a per-request
basis by providing the "?token" query parameter. When not provided, the empty token, which maps to
the 'anonymous' ACL policy, is used.
* `acl_ttl` -
**Deprecated in Consul 1.4.0. See the [`acl.token_ttl`](#acl_token_ttl) field instead.**Used to control Time-To-Live caching of ACLs.
By default, this is 30 seconds. This setting has a major performance impact: reducing it will cause
more frequent refreshes while increasing it reduces the number of refreshes. However, because the caches
are not actively invalidated, ACL policy may be stale up to the TTL value.
* `addresses` - This is a nested object that allows
setting bind addresses. In Consul 1.0 and later these can be set to a space-separated list of
addresses to bind to, or a [go-sockaddr](https://godoc.org/github.com/hashicorp/go-sockaddr/template)
template that can potentially resolve to multiple addresses.
`http`, `https` and `grpc` all support binding to a Unix domain socket. A
socket can be specified in the form `unix:///path/to/socket`. A new domain
socket will be created at the given path. If the specified file path already
exists, Consul will attempt to clear the file and create the domain socket
in its place. The permissions of the socket file are tunable via the
[`unix_sockets` config construct](#unix_sockets).
When running Consul agent commands against Unix socket interfaces, use the
`-http-addr` argument to specify the path to the socket. You can also place
the desired values in the `CONSUL_HTTP_ADDR` environment variable.
For TCP addresses, the environment variable value should be an IP address
_with the port_. For example: `10.0.0.1:8500` and not `10.0.0.1`. However,
ports are set separately in the `ports` structure when
defining them in a configuration file.
The following keys are valid:
- `dns` - The DNS server. Defaults to `client_addr`
- `http` - The HTTP API. Defaults to `client_addr`
- `https` - The HTTPS API. Defaults to `client_addr`
- `grpc` - The gRPC API. Defaults to `client_addr`
* `advertise_addr` Equivalent to
the [`-advertise` command-line flag](#_advertise).
* `serf_wan` Equivalent to
the [`-serf-wan-bind` command-line flag](#_serf_wan_bind).
* `serf_lan` Equivalent to
the [`-serf-lan-bind` command-line flag](#_serf_lan_bind).
* `advertise_addr_wan` Equivalent to
the [`-advertise-wan` command-line flag](#_advertise-wan).
* `autopilot` Added in Consul 0.8, this object
allows a number of sub-keys to be set which can configure operator-friendly settings for Consul servers.
When these keys are provided as configuration, they will only be respected on bootstrapping. If they are not
provided, the defaults will be used. In order to change the value of these options after bootstrapping, you will
need to use the [Consul Operator Autopilot](https://www.consul.io/docs/commands/operator/autopilot.html) command.
For more information about Autopilot, see the [Autopilot Guide](https://learn.hashicorp.com/consul/day-2-operations/autopilot).
The following sub-keys are available:
* `cleanup_dead_servers` - This controls
the automatic removal of dead server nodes periodically and whenever a new server is added to the cluster.
Defaults to `true`.
* `last_contact_threshold` - Controls
the maximum amount of time a server can go without contact from the leader before being considered unhealthy.
Must be a duration value such as `10s`. Defaults to `200ms`.
* `max_trailing_logs` - Controls
the maximum number of log entries that a server can trail the leader by before being considered unhealthy. Defaults
to 250.
* `server_stabilization_time` -
Controls the minimum amount of time a server must be stable in the 'healthy' state before being added to the
cluster. Only takes effect if all servers are running Raft protocol version 3 or higher. Must be a duration value
such as `30s`. Defaults to `10s`.
* `redundancy_zone_tag` - (Enterprise-only)
This controls the [`-node-meta`](#_node_meta) key to use when Autopilot is separating servers into zones for
redundancy. Only one server in each zone can be a voting member at one time. If left blank (the default), this
feature will be disabled.
* `disable_upgrade_migration` - (Enterprise-only)
If set to `true`, this setting will disable Autopilot's upgrade migration strategy in Consul Enterprise of waiting
until enough newer-versioned servers have been added to the cluster before promoting any of them to voters. Defaults
to `false`.
* `upgrade_version_tag` - (Enterprise-only)
The node_meta tag to use for version info when performing upgrade migrations. If this is not set, the Consul
version will be used.
* `auto_encrypt`
This object allows setting options for the `auto_encrypt` feature.
The following sub-keys are available:
* `allow_tls` (Defaults to `false`) This option enables `auto_encrypt` on the servers and allows them to automatically distribute certificates from the Connect CA to the clients. If enabled, the server can accept incoming connections from both the built-in CA and the Connect CA, as well as their certificates. Note, the server will only present the built-in CA and certificate, which the client can verify using the CA it received from `auto_encrypt` endpoint. If disabled, a client configured with `auto_encrypt.tls` will be unable to start.
* `tls` (Defaults to `false`) Allows the client to request the Connect CA and certificates from the servers, for encrypting RPC communication. The client will make the request to any servers listed in the `-join` or `-retry-join` option. This requires that every server to have `auto_encrypt.allow_tls` enabled. When both `auto_encrypt` options are used, it allows clients to receive certificates that are generated on the servers. If the `-server-port` is not the default one, it has to be provided to the client as well. Usually this is discovered through LAN gossip, but `auto_encrypt` provision happens before the information can be distributed through gossip. The most secure `auto_encrypt` setup is when the client is provided with the built-in CA, `verify_server_hostname` is turned on, and when an ACL token with `node.write` permissions is setup. It is also possible to use `auto_encrypt` with a CA and ACL, but without `verify_server_hostname`, or only with a ACL enabled, or only with CA and `verify_server_hostname`, or only with a CA, or finally without a CA and without ACL enabled. In any case, the communication to the `auto_encrypt` endpoint is always TLS encrypted.
* `bootstrap` Equivalent to the
[`-bootstrap` command-line flag](#_bootstrap).
* `bootstrap_expect` Equivalent
to the [`-bootstrap-expect` command-line flag](#_bootstrap_expect).
* `bind_addr` Equivalent to the
[`-bind` command-line flag](#_bind).
* `ca_file` This provides a file path to a PEM-encoded
certificate authority. The certificate authority is used to check the authenticity of client and
server connections with the appropriate [`verify_incoming`](#verify_incoming) or
[`verify_outgoing`](#verify_outgoing) flags.
* `ca_path` This provides a path to a directory of PEM-encoded
certificate authority files. These certificate authorities are used to check the authenticity of client and
server connections with the appropriate [`verify_incoming`](#verify_incoming) or
[`verify_outgoing`](#verify_outgoing) flags.
* `cert_file` This provides a file path to a
PEM-encoded certificate. The certificate is provided to clients or servers to verify the agent's
authenticity. It must be provided along with [`key_file`](#key_file).
* `check_update_interval`
This interval controls how often check output from
checks in a steady state is synchronized with the server. By default, this is
set to 5 minutes ("5m"). Many checks which are in a steady state produce
slightly different output per run (timestamps, etc) which cause constant writes.
This configuration allows deferring the sync of check output for a given interval to
reduce write pressure. If a check ever changes state, the new state and associated
output is synchronized immediately. To disable this behavior, set the value to "0s".
* `client_addr` Equivalent to the
[`-client` command-line flag](#_client).
* `config_entries`
This object allows setting options for centralized config entries.
The following sub-keys are available:
* `bootstrap`
This is a list of inlined config entries to insert into the state store when the Consul server
gains leadership. This option is only applicable to server nodes. Each bootstrap
entry will be created only if it does not exist. When reloading, any new entries
that have been added to the configuration will be processed. See the
[configuration entry docs](/docs/agent/config_entries.html) for more details about the
contents of each entry.
* `connect`
This object allows setting options for the Connect feature.
The following sub-keys are available:
* `enabled` Controls whether
Connect features are enabled on this agent. Should be enabled on all clients and
servers in the cluster in order for Connect to function properly. Defaults to false.
* `ca_provider` Controls
which CA provider to use for Connect's CA. Currently only the `consul` and `vault` providers
are supported. This is only used when initially bootstrapping the cluster. For an existing
cluster, use the [Update CA Configuration Endpoint](/api/connect/ca.html#update-ca-configuration).
* `ca_config` An object which
allows setting different config options based on the CA provider chosen. This is only
used when initially bootstrapping the cluster. For an existing cluster, use the [Update CA
Configuration Endpoint](/api/connect/ca.html#update-ca-configuration).
The following providers are supported:
#### Consul CA Provider (`ca_provider = "consul"`)
* `private_key` The
PEM contents of the private key to use for the CA.
* `root_cert` The
PEM contents of the root certificate to use for the CA.
#### Vault CA Provider (`ca_provider = "vault"`)
* `address` The address of the Vault
server to connect to.
* `token` The Vault token to use.
* `root_pki_path` The
path to use for the root CA pki backend in Vault. This can be an existing backend with a CA already
configured, or a blank/unmounted backend in which case Connect will automatically mount/generate the CA.
The Vault token given above must have `sudo` access to this backend, as well as permission to mount
the backend at this path if it is not already mounted.
* `intermediate_pki_path`
The path to use for the temporary intermediate CA pki backend in Vault. *Connect will overwrite any data
at this path in order to generate a temporary intermediate CA*. The Vault token given above must have
`write` access to this backend, as well as permission to mount the backend at this path if it is not
already mounted.
#### Common CA Config Options
There are also a number of common configuration options supported by all providers:
* `leaf_cert_ttl` The upper bound on the lease duration of a leaf certificate issued for a service. In most cases a new leaf certificate will be requested by a proxy before this limit is reached. This is also the effective limit on how long a server outage can last (with no leader) before network connections will start being rejected, and as a result the defaults is `72h` to last through a weekend without intervention. This value cannot be lower than 1 hour or higher than 1 year. This value is also used when rotating out old root certificates from the cluster. When a root certificate has been inactive (rotated out) for more than twice the *current* `leaf_cert_ttl`, it will be removed from the trusted list. * `csr_max_per_second` Sets a rate limit on the maximum number of Certificate Signing Requests (CSRs) the servers will accept. This is used to prevent CA rotation from causing unbounded CPU usage on servers. It defaults to 50 which is conservative - a 2017 Macbook can process about 100 per second using only ~40% of one CPU core - but sufficient for deployments up to ~1500 service instances before the time it takes to rotate is impacted. For larger deployments we recommend increasing this based on the expected number of server instances and server resources, or use `csr_max_concurrent` instead if servers have more than one core. Setting this to zero disables rate limiting. Added in 1.4.1. * `csr_max_concurrent` Sets a limit on how many Certificate Signing Requests will be processed concurrently. Defaults to 0 (disabled). This is useful when you have more than one or two cores available to the server. For example on an 8 core server, setting this to 1 will ensure that even during a CA rotation no more than one server core on the leader will be consumed at a time with generating new certificates. Setting this is recommended _instead_ of `csr_max_per_second` where you know there are multiple cores available since it is simpler to reason about limiting CSR resources this way without artificially slowing down rotations. Added in 1.4.1. * `datacenter` Equivalent to the [`-datacenter` command-line flag](#_datacenter). * `data_dir` Equivalent to the [`-data-dir` command-line flag](#_data_dir). * `disable_anonymous_signature` Disables providing an anonymous signature for de-duplication with the update check. See [`disable_update_check`](#disable_update_check). * `disable_host_node_id` Equivalent to the [`-disable-host-node-id` command-line flag](#_disable_host_node_id). * `disable_http_unprintable_char_filter` Defaults to false. Consul 1.0.3 fixed a potential security vulnerability where malicious users could craft KV keys with unprintable chars that would confuse operators using the CLI or UI into taking wrong actions. Users who had data written in older versions of Consul that did not have this restriction will be unable to delete those values by default in 1.0.3 or later. This setting enables those users to _temporarily_ disable the filter such that delete operations can work on those keys again to get back to a healthy state. It is strongly recommended that this filter is not disabled permanently as it exposes the original security vulnerability. * `disable_remote_exec` Disables support for remote execution. When set to true, the agent will ignore any incoming remote exec requests. In versions of Consul prior to 0.8, this defaulted to false. In Consul 0.8 the default was changed to true, to make remote exec opt-in instead of opt-out. * `disable_update_check` Disables automatic checking for security bulletins and new version releases. This is disabled in Consul Enterprise. * `discard_check_output` Discards the output of health checks before storing them. This reduces the number of writes to the Consul raft log in environments where health checks have volatile output like timestamps, process ids, ... * `discovery_max_stale` - Enables stale requests for all service discovery HTTP endpoints. This is equivalent to the [`max_stale`](#max_stale) configuration for DNS requests. If this value is zero (default), all service discovery HTTP endpoints are forwarded to the leader. If this value is greater than zero, any Consul server can handle the service discovery request. If a Consul server is behind the leader by more than `discovery_max_stale`, the query will be re-evaluated on the leader to get more up-to-date results. Consul agents also add a new `X-Consul-Effective-Consistency` response header which indicates if the agent did a stale read. `discover-max-stale` was introduced in Consul 1.0.7 as a way for Consul operators to force stale requests from clients at the agent level, and defaults to zero which matches default consistency behavior in earlier Consul versions. * `dns_config` This object allows a number of sub-keys to be set which can tune how DNS queries are serviced. See this guide on [DNS caching](https://learn.hashicorp.com/consul/security-networking/dns-caching) for more detail. The following sub-keys are available: * `allow_stale` - Enables a stale query for DNS information. This allows any Consul server, rather than only the leader, to service the request. The advantage of this is you get linear read scalability with Consul servers. In versions of Consul prior to 0.7, this defaulted to false, meaning all requests are serviced by the leader, providing stronger consistency but less throughput and higher latency. In Consul 0.7 and later, this defaults to true for better utilization of available servers. * `max_stale` - When [`allow_stale`](#allow_stale) is specified, this is used to limit how stale results are allowed to be. If a Consul server is behind the leader by more than `max_stale`, the query will be re-evaluated on the leader to get more up-to-date results. Prior to Consul 0.7.1 this defaulted to 5 seconds; in Consul 0.7.1 and later this defaults to 10 years ("87600h") which effectively allows DNS queries to be answered by any server, no matter how stale. In practice, servers are usually only milliseconds behind the leader, so this lets Consul continue serving requests in long outage scenarios where no leader can be elected. * `node_ttl` - By default, this is "0s", so all node lookups are served with a 0 TTL value. DNS caching for node lookups can be enabled by setting this value. This should be specified with the "s" suffix for second or "m" for minute. * `service_ttl` - This is a sub-object which allows for setting a TTL on service lookups with a per-service policy. The "*" wildcard service can be used when there is no specific policy available for a service. By default, all services are served with a 0 TTL value. DNS caching for service lookups can be enabled by setting this value. * `enable_truncate` - If set to true, a UDP DNS query that would return more than 3 records, or more than would fit into a valid UDP response, will set the truncated flag, indicating to clients that they should re-query using TCP to get the full set of records. * `only_passing` - If set to true, any nodes whose health checks are warning or critical will be excluded from DNS results. If false, the default, only nodes whose healthchecks are failing as critical will be excluded. For service lookups, the health checks of the node itself, as well as the service-specific checks are considered. For example, if a node has a health check that is critical then all services on that node will be excluded because they are also considered critical. * `recursor_timeout` - Timeout used by Consul when recursively querying an upstream DNS server. See `recursors` for more details. Default is 2s. This is available in Consul 0.7 and later. * `disable_compression` - If set to true, DNS responses will not be compressed. Compression was added and enabled by default in Consul 0.7. * `udp_answer_limit` - Limit the number of resource records contained in the answer section of a UDP-based DNS response. This parameter applies only to UDP DNS queries that are less than 512 bytes. This setting is deprecated and replaced in Consul 1.0.7 by `a_record_limit`. * `a_record_limit` - Limit the number of resource records contained in the answer section of a A, AAAA or ANY DNS response (both TCP and UDP). When answering a question, Consul will use the complete list of matching hosts, shuffle the list randomly, and then limit the number of answers to `a_record_limit` (default: no limit). This limit does not apply to SRV records. In environments where [RFC 3484 Section 6](https://tools.ietf.org/html/rfc3484#section-6) Rule 9 is implemented and enforced (i.e. DNS answers are always sorted and therefore never random), clients may need to set this value to `1` to preserve the expected randomized distribution behavior (note: [RFC 3484](https://tools.ietf.org/html/rfc3484) has been obsoleted by [RFC 6724](https://tools.ietf.org/html/rfc6724) and as a result it should be increasingly uncommon to need to change this value with modern resolvers). * `enable_additional_node_meta_txt` - When set to true, Consul will add TXT records for Node metadata into the Additional section of the DNS responses for several query types such as SRV queries. When set to false those records are not emitted. This does not impact the behavior of those same TXT records when they would be added to the Answer section of the response like when querying with type TXT or ANY. This defaults to true. * `soa` Allow to tune the setting set up in SOA. Non specified values fallback to their default values, all values are integers and expressed as seconds.