Skip to content

Beacon Relay Installation

The beacon relay is a stateless TCP relay that enables outbound-only connectivity between your EU-hosted secret store and your Kubernetes cluster. Both sides connect outbound to the beacon on TCP 443; the beacon matches them cryptographically and forwards encrypted mTLS bytes between them. It stores no secrets, no keys, and no configuration state.

No inbound ports required

Neither the secret store nor the cluster needs to expose an inbound port. Both sides initiate outbound TCP 443 connections to the beacon. This eliminates the need for VPN, IPsec, or SSH tunnels.

When you need a beacon

Beacon relay is the default connectivity mode. You need a beacon when:

  • Your secret store and cluster have no direct network path
  • Both sides are behind NAT or firewalls
  • You only allow outbound TCP 443 traffic
  • You want zero-config connectivity without VPN or tunnel infrastructure

For other connectivity modes, see Beacon Relay Architecture.

Deployment options

Option A: SaaS beacon (pilots only)

A public demo relay at beacon.cloudtaser.io:443 exists for the live demo and quick-look pilots. It is not for production use:

  • No production support SLA
  • Can be taken offline for maintenance at any time
  • Places connection metadata on infrastructure you do not operate

For production deployments, regulated workloads, or any deployment under a DPIA, deploy your own beacon (Option B).

Option B: Self-hosted (production)

Deploy the beacon on infrastructure you control -- a small VM, a bare-metal host, or a Kubernetes cluster. The beacon needs a public IP or DNS name reachable from both the secret-store side and the cluster side on TCP 443. It requires no access to either your secret store or your cluster.

Installation

The CLI provides cloudtaser beacon install with three deployment targets.

Systemd (VM or bare metal)

Install the beacon as a systemd service on a Linux host. Requires root.

sudo cloudtaser-cli beacon install \
  --type systemd \
  --advertise-addr beacon.example.com:443 \
  --public-cert-file /etc/letsencrypt/live/beacon.example.com/fullchain.pem \
  --public-key-file  /etc/letsencrypt/live/beacon.example.com/privkey.pem

This downloads the beacon binary, creates a systemd unit, and starts the service.

Audit before applying

Pass --dry-run to print the install script, systemd unit, and environment file to stdout without modifying the host:

cloudtaser-cli beacon install \
  --type systemd \
  --advertise-addr beacon.example.com:443 \
  --dry-run

Docker Compose

Generate a docker-compose.yaml for single-host deployments:

cloudtaser-cli beacon install \
  --type docker \
  --advertise-addr beacon.example.com:443 \
  --public-cert-file ./cert.pem \
  --public-key-file  ./key.pem

Kubernetes (Helm)

Deploy via the cloudtaser-beacon Helm chart:

helm repo add cloudtaser https://charts.cloudtaser.io
helm repo update

helm install cloudtaser-beacon cloudtaser/cloudtaser-beacon \
  --namespace cloudtaser-beacon \
  --create-namespace \
  --set service.type=LoadBalancer \
  --set tls.existingSecret=beacon-tls

For HA deployments with 3 or more replicas:

cloudtaser-cli beacon install \
  --type kubernetes \
  --replicas 3 \
  --namespace cloudtaser-beacon \
  --bootstrap-from beacon.example.com \
  --existing-gossip-secret beacon-gossip \
  --existing-ca-secret     beacon-internal-ca \
  --existing-tls-secret    beacon-public-tls

Two-node clusters are refused

A 2-node beacon cluster has no tiebreaker and strictly adds a failure mode over a single instance. Use --replicas=1 or --replicas=3 (or higher odd numbers).

TLS certificates

The beacon requires a TLS certificate for its public listener on port 443. Use a certificate from your PKI or a provider such as Let's Encrypt.

Flag Purpose
--public-cert-file Path to the TLS certificate (PEM) for the public listener
--public-key-file Path to the corresponding private key (PEM)

For Kubernetes deployments, provide the certificate via a TLS Secret referenced with --set tls.existingSecret=<name>.

Auth key

The beacon uses an HMAC auth key to authenticate port and broker registrations. The key is auto-generated during cloudtaser-cli beacon install and stored in your secret store if --vault-addr and --vault-token are provided. The port reads it from the secret store at startup.

Secure key loading

Use --auth-key-file (not --auth-key) to avoid exposing the key in process listings. The Helm chart handles this automatically when deploying on Kubernetes.

After deployment

  1. Save the ctb1 token printed by beacon install, for example by copying the ctb1... value into ./beacon.token. You will use it with source install port on the secret-store side and target install on the cluster side. source register is only for optional advanced pre-registration.

  2. Verify the beacon is running:

    cloudtaser-cli beacon status --address beacon.example.com:443

  3. Proceed to Secret Store & Port Installation to deploy the port that connects your secret store to the beacon.

Network requirements

Side Direction Destination Port Protocol
Secret store (port) Outbound Beacon 443 TCP/TLS
Cluster (broker) Outbound Beacon 443 TCP/TLS
Beacon Inbound From port and broker 443 TCP/TLS

High availability

For production deployments, run 3 or more beacon instances. HA requires:

  • A gossip encryption key (--gossip-key-file)
  • Internal mTLS certificates for inter-beacon communication (--internal-ca-cert-file, --internal-cert-file, etc.)
  • Either --bootstrap-from (DNS-based discovery) or --peers (explicit seed list)

HA is supported only on Kubernetes (--type=kubernetes). Systemd and Docker modes are single-instance.

See Beacon Relay Architecture for the full HA design including consistent-hash ring and inner-hop mTLS forwarding.