71 lines
3.0 KiB
Plaintext
71 lines
3.0 KiB
Plaintext
|
---
|
|||
|
|
layout: docs
|
|||
|
|
page_title: Server Configuration
|
|||
|
|
sidebar_title: Configuration
|
|||
|
|
description: Boundary configuration reference.
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Configuration
|
|||
|
|
|
|||
|
|
[listener]: /docs/configuration/listener
|
|||
|
|
[telemetry]: /docs/configuration/telemetry
|
|||
|
|
[controller]: /docs/configuration/controller
|
|||
|
|
[worker]: /docs/configuration/worker
|
|||
|
|
[kms]: /docs/configuration/kms
|
|||
|
|
|
|||
|
|
Outside of development mode, Boundary controllers and workers are configured using a file.
|
|||
|
|
The format of this file is [HCL](https://github.com/hashicorp/hcl). In this section you'll find
|
|||
|
|
configuration block examples for Boundary controllers and workers.
|
|||
|
|
|
|||
|
|
After the configuration is written, use the `-config` flag to specify a local path to the file.
|
|||
|
|
|
|||
|
|
## Parameters
|
|||
|
|
|
|||
|
|
- `controller` <tt>([Controller][controller]: \<required\>)</tt> - Controller specific configuration. Only required when running a `boundary controller`.
|
|||
|
|
|
|||
|
|
- `worker` <tt>([Worker][worker]: \<required\>)</tt> - Worker specific configuration. Only required when running a `boundary worker`.
|
|||
|
|
|
|||
|
|
- `listener` <tt>([Listener][listener]: \<required\>)</tt> – Configures the Boundary server
|
|||
|
|
options for controllers and workers.
|
|||
|
|
|
|||
|
|
Controllers will have two listener blocks, one for the API server and the other for the data-plane
|
|||
|
|
server. By default, controller API server runs on :9200 and the data-plane (which is used for
|
|||
|
|
worker communication) uses :9201.
|
|||
|
|
|
|||
|
|
Workers will have only one listener.
|
|||
|
|
|
|||
|
|
- `kms` <tt>([KMS][kms]: \<required\>)</tt> – Configures KMS blocks for root, worker authentication, and recovery keys.
|
|||
|
|
|
|||
|
|
- `disable_mlock` `(bool: false)` – Disables the server from executing the
|
|||
|
|
`mlock` syscall. `mlock` prevents memory from being swapped to disk. Disabling
|
|||
|
|
`mlock` is not recommended in production, but is fine for local development
|
|||
|
|
and testing.
|
|||
|
|
|
|||
|
|
Disabling `mlock` is not recommended unless the systems running Vault only
|
|||
|
|
use encrypted swap or do not use swap at all. Boundary only supports memory
|
|||
|
|
locking on UNIX-like systems that support the mlock() syscall (Linux, FreeBSD, etc).
|
|||
|
|
Non UNIX-like systems (e.g. Windows, NaCL, Android) lack the primitives to keep a
|
|||
|
|
process's entire memory address space from spilling to disk and is therefore
|
|||
|
|
automatically disabled on unsupported platforms.
|
|||
|
|
|
|||
|
|
On Linux, to give the Boundary executable the ability to use the `mlock`
|
|||
|
|
syscall without running the process as root, run:
|
|||
|
|
|
|||
|
|
```shell
|
|||
|
|
sudo setcap cap_ipc_lock=+ep $(readlink -f $(which vault))
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
If you use a Linux distribution with a modern version of systemd, you can add
|
|||
|
|
the following directive to the "[Service]" configuration section:
|
|||
|
|
|
|||
|
|
```ini
|
|||
|
|
LimitMEMLOCK=infinity
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
- `telemetry` <tt>([Telemetry][telemetry]: <none>)</tt> – Not yet implemented.
|
|||
|
|
|
|||
|
|
- `log_level` `(string: "")` – Specifies the log level to use; overridden by
|
|||
|
|
CLI and env var parameters. Supported log levels: Trace, Debug, Error, Warn, Info.
|
|||
|
|
|
|||
|
|
- `log_format` `(string: "")` – Specifies the log format to use; overridden by
|
|||
|
|
CLI and env var parameters. Supported log formats: "standard", "json".
|