Files
threshold/website/content/docs/configuration/worker.mdx
T
Hugo Vieira 1576af70cc feat(config): Add env and file support to Worker Tags
This feature allows the user to set the `tags` field to a string
that points to either an environment variable or file.
We then dynamically pull out the value and parse it into the config.

This can also be done at the keys level, where you set your keys
directly in Boundary's config file, but point the values to env/file.
2021-12-07 19:21:04 +00:00

114 lines
3.5 KiB
Plaintext

---
layout: docs
page_title: Worker - Configuration
description: |-
The worker stanza configures worker-specific parameters.
---
# `worker` Stanza
The `worker` stanza configures Boundary worker-specific parameters.
```hcl
worker {
name = "example-worker"
description = "An example worker"
public_addr = "5.1.23.198"
}
```
- `name` - Specifies a unique name of this worker within the Boundary
cluster. This value can be a direct name string, can refer to a file on disk
(file://) from which an name will be read; or an env var (env://) from which
the name will be read.
- `description` - Specifies a friendly description of this worker.
- `public_addr` - Specifies the public host or IP address (and optionally port)
at which the worker can be reached _by clients for proxying_. This defaults to
the address of the listener marked for `proxy` purpose. This is especially
useful for cloud environments that do not bind a publicly accessible IP to a NIC
on the host directly, such as an Amazon EIP. This value can be a direct address string,
can refer to a file on disk (file://) from which an address will be read;
an env var (env://) from which the address will be read;
or a [go-sockaddr template](https://godoc.org/github.com/hashicorp/go-sockaddr/template).
- `controllers` - A list of hosts/IP addresses and optionally ports for reaching
controllers. The port will default to :9201 if not specified.
- `tags` - A map of key-value pairs where values are an array of strings. Most
commonly used for [filtering](/docs/concepts/filtering) targets a worker can
proxy via [worker tags](/docs/concepts/filtering/worker-tags). On `SIGHUP`, the
tags set here will be re-parsed and new values used. It can also be a string
referring to a file on disk (file://) or an env var (env://).
## KMS Configuration
Workers require a KMS block designated for `worker-auth`. This is the KMS configuration for
authentication between the workers and controllers and must be present. Example (not safe for production!):
```hcl
kms "aead" {
purpose = "worker-auth"
aead_type = "aes-gcm"
key = "8fZBjCUfN0TzjEGLQldGY4+iE9AkOvCfjh7+p0GtRBQ="
key_id = "global_worker-auth"
}
```
This configuration must be the same for the worker-auth configuration for the controller if you're
running the controller and worker as separate servers.
And optionally, a KMS stanza for configuration encryption purpose:
```hcl
# Configuration encryption block: decrypts sensitive values in the
# configuration file. See `boundary config [encrypt|decrypt] -h`.
kms "aead" {
purpose = "config"`
aead_type = "aes-gcm"
key = "7xtkEoS5EXPbgynwd+dDLHopaCqK8cq0Rpep4eooaTs="
}
```
Boundary supports many kinds of KMS integrations. For a complete guide to all available
KMS types, see our [KMS documentation](/docs/configuration/kms).
# Complete Configuration Example
```hcl
listener "tcp" {
purpose = "proxy"
tls_disable = true
address = "127.0.0.1"
}
worker {
# Name attr must be unique across workers
name = "demo-worker-1"
description = "A default worker created demonstration"
# Workers must be able to reach controllers on :9201
controllers = [
"10.0.0.1",
"10.0.0.2",
"10.0.0.3",
]
public_addr = "myhost.mycompany.com"
tags {
type = ["prod", "webservers"]
region = ["us-east-1"]
}
}
# must be same key as used on controller config
kms "aead" {
purpose = "worker-auth"
aead_type = "aes-gcm"
key = "8fZBjCUfN0TzjEGLQldGY4+iE9AkOvCfjh7+p0GtRBQ="
key_id = "global_worker-auth"
}
```