rules-boundary

RISK: Boundary 'dev' mode starts with a root-level admin token printed to stdout and TLS disabled — never use it outside a local laptop. Any config file with 'dev = true' would expose the controller with zero authentication if deployed. FIX: Remove 'dev = true' and configure a proper KMS stanza plus TLS listener for all non-development environments.

RISK: Hardcoded KMS recovery or root key material in an HCL config — once committed to VCS the key is permanently compromised, enabling full controller takeover. FIX: Store the key in an external KMS (HashiCorp Vault transit, AWS KMS, Azure Key Vault) and reference it via the 'kms' stanza with a key_id/purpose, never inline.

RISK: Boundary controller/worker listener bound to 0.0.0.0 is reachable from all network interfaces, including untrusted ones. FIX: Bind the cluster and ops listeners to a private interface IP unless the public-facing 'api' listener specifically requires broad access, and use a load balancer in front.

RISK: 'tls_disable = true' in a Boundary listener configuration exposes all session traffic (tokens, credentials, commands) in plaintext. FIX: Remove 'tls_disable' and configure 'tls_cert_file' / 'tls_key_file' or use a KMS-backed TLS terminator.

RISK: Boundary wildcard grant (ids=*;type=*;actions=*) gives a role complete read/write/delete over every resource in the scope — effectively a superadmin. FIX: Follow least-privilege: specify the exact resource type, IDs, and actions this role needs (e.g., 'ids=*;type=target;actions=read,authorize-session').

RISK: Boundary worker 'initial_upstreams' pointing to a controller without TLS config in the same file may establish the worker-to-controller channel unencrypted. FIX: Ensure the controller listener for worker traffic has TLS enabled and verify the worker's 'tls_*' options are configured to validate the controller certificate.