Beacon Relay Installation¶
Published customer release
The EU OpenBao + Port procedure records measured delivery from an EU store through Linux host Port and a customer relay to a US cluster. Use chart 1.0.359 and its matched signed components. Use released CLI v0.19.176. Hosted enrollment is not currently available; follow the procedure's release and support limits.
The beacon connects the outbound EU Port and target-cluster broker connections. Application payloads remain encrypted between their endpoints. The relay sees connection metadata and holds registration authentication material; do not interpret “relay” as an absence of private keys or operational state.
When you need a beacon¶
Use it when EU OpenBao/Port and the target cluster have no direct network path. Both sides need outbound TCP 443 to a reachable, verified relay; neither needs a new inbound listener for the other side. The EU management host separately needs the Kubernetes API for installation and private runtime introduction.
Deployment options¶
Hosted relay: customer enrollment unavailable¶
Hosted customer and pilot enrollment is not currently available. The existing
CloudTaser-hosted fleet serves its demo boundary only. Do not request or wait for
a hosted tenant, reuse the demo identity, or use beacon.cloudtaser.io in this
customer procedure. The hosted demo is not an installation service.
Customer path: self-hosted relay¶
Deploy a relay you control in the EU, with verified TLS and outbound reach from both the EU Port and target cluster. The full customer procedure uses that relay exclusively. A qualified signed binary and an approved tenant-key consumer/restart-custody procedure are prerequisites, not hosted handoffs.
Self-hosted relay setup¶
This standalone path uses the matched signed beacon binary and a separate
strict service. It does not use the legacy CLI installer's shared-key unit.
Install the verified binary as /usr/local/bin/cloudtaser-beacon first, and
install the matched cloudtaser-cli on this relay host (the enrollment helper
invokes it). Follow fetch and verify the matched host release
on this relay host: the CLI block and beacon block provide the actual URLs,
pinned-key signature checks, binary digest checks and install commands.
The commands below start after those checks. Run the
following preparation in root Bash on the relay host; issuance also requires
verified HTTPS access to your source after its cloudtaser KV-v2 mount exists.
set +x
umask 077
id cloudtaser-beacon >/dev/null 2>&1 || useradd --system --no-create-home --shell /usr/sbin/nologin cloudtaser-beacon
install -d -o root -g root -m 0700 /run/cloudtaser-beacon-keys
mount -t tmpfs -o size=1m,mode=0700,nodev,nosuid,noexec tmpfs /run/cloudtaser-beacon-keys
test "$(wc -l < /proc/swaps)" -eq 1
findmnt -n -o FSTYPE,OPTIONS -T /run/cloudtaser-beacon-keys
Run the mount once on a fresh directory, not over an existing map. This is the
swap-disabled-host profile: /proc/swaps must have only its header, and host
policy must prevent enabling swap while private material exists. Plain tmpfs is
swappable on a swap-enabled host. This profile works on Debian 12's older
kernels, where mount -o noswap is unavailable; it does not claim that plain
tmpfs acquired the kernel's noswap property. Disable core dumps and payload
tracing throughout the ceremony. Reboot loses the map; your private custody
must restore the same key before restarting, never mint a replacement key.
Download and review the version of
beacon-relay-enroll.py shipped with
these docs, then install it root-owned at
/usr/local/libexec/cloudtaser-relay-enroll.py (0755). The helper validates a
bounded duplicate-free two-field record and exact expected tenant ID, converts
it into {ID:BASE64_KEY}, and creates the final root-owned 0400 map without
intermediate records or overwrite. It creates separate anonymous pipes for the
CLI issuer and source consumer, preserves the independent root-token FD, applies
a 60-second deadline and requires both child exit statuses. It prints public
receipts only. Python/CLI heap copies are not a complete-erasure guarantee.
Obtain and review the helper before installing it. For offline docs, set
DOCS_ARTIFACT_DIR to the local reviewed built-site directory on this relay host:
if test -n "${DOCS_ARTIFACT_DIR:-}"; then
cp "$DOCS_ARTIFACT_DIR/assets/scripts/beacon-relay-enroll.py" beacon-relay-enroll.py
else
curl --fail --silent --show-error --proto '=https' \
https://docs.cloudtaser.io/assets/scripts/beacon-relay-enroll.py -o beacon-relay-enroll.py
fi
# Review the downloaded helper before installing it.
install -D -o root -g root -m 0755 ./beacon-relay-enroll.py /usr/local/libexec/cloudtaser-relay-enroll.py
After source bootstrap, run this on the relay host in root Bash. For separate
relay/source hosts, SOURCE_ORIGIN must use a source address reachable from the
relay and covered by its verified certificate; 127.0.0.1 applies only when they
are co-located. Set the actual
canonical ID, source origin and source CA; customer-root-token is your private
credential producer from the customer guide.
python3 /usr/local/libexec/cloudtaser-relay-enroll.py \
--tenant-id "$BEACON_TENANT_ID" --source "$SOURCE_ORIGIN" \
--source-ca "$SOURCE_CA" --admin-token-fd 3 \
--key-map /run/cloudtaser-beacon-keys/tenant-auth-keys.json \
3< <(customer-root-token)
The relay map and source write are not atomic. Any failure or lost receipt is uncertain: keep both states private, stop activation and reconcile them before an authorized retry. Do not delete a map and reissue after a partial source commit. The source consumer's CAS-zero refusal protects existing pairing.
Prepare your actual relay TLS certificate/key. Give the service account read
access to them (for example root:cloudtaser-beacon 0640 for the private key with
searchable private parent directories). Create this standalone unit at
/etc/systemd/system/cloudtaser-beacon-strict.service:
[Unit]
Description=Customer strict Wire v2 beacon
After=network-online.target
Wants=network-online.target
[Service]
User=cloudtaser-beacon
Group=cloudtaser-beacon
UnsetEnvironment=CLOUDTASER_BEACON_AUTH_KEY CLOUDTASER_BEACON_AUTH_KEY_FILE CLOUDTASER_BEACON_PREVIOUS_AUTH_KEY_FILE CLOUDTASER_BEACON_AUTH_KEY_OVERLAP_UNTIL
LoadCredential=tenant-auth-keys.json:/run/cloudtaser-beacon-keys/tenant-auth-keys.json
ExecStartPre=/usr/bin/python3 -c "assert len(open('/proc/swaps').readlines()) == 1"
ExecStart=/usr/local/bin/cloudtaser-beacon --addr :443 --health-addr 127.0.0.1:8080 --tls-cert /etc/cloudtaser-beacon/tls/server.crt --tls-key /etc/cloudtaser-beacon/tls/server.key --tenant-auth-keys-file=%d/tenant-auth-keys.json --single-tenant --strict-wire-v2
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
LimitCORE=0
Restart=no
[Install]
WantedBy=multi-user.target
LoadCredential lets systemd read the root-only source map and deliver a private
service-readable copy. Do not loosen the source directory or map permissions to
make the account read it. This unit has no shared AUTH_KEY/AUTH_KEY_FILE, no
legacy environment file and no legacy fallback. If you previously ran the CLI's
shared-key service, stop/disable it before starting this one to free port 443;
do not layer this unit over its shared-key environment.
systemctl daemon-reload
systemctl start cloudtaser-beacon-strict.service
systemctl is-active cloudtaser-beacon-strict.service
Automatic boot startup is deliberately absent until your approved custody
restores the same runtime map. Keep TLS renewal, firewall and lifecycle in the
host policy. The measured runs used an IP-literal relay with a private CA,
IP SAN and no SNI allowlist. DNS-named and public-CA relays were not tested.
Use the same explicit private CA on Port and the operator; never bypass TLS.
Do not use shared-key or --tenant-mode=multi installation as a shortcut.
Confirm both private consumers' persistence receipts, the enabled customer ID and the actual TLS listener before Port launch. Partial issuance requires reconciliation, not a second issuance. Keep only public ID/version/status receipts. See tenant isolation and the relay architecture.
TLS certificates¶
Verify the relay's actual address against its public CA or approved private CA. Provide the public CA bundle to the Port launch and the matched operator values. Do not skip certificate checks or use a bare SPKI copied from an untrusted connection as enrollment evidence. Certificate rotation and tenant-key rotation are separate operational changes requiring their approved rollout procedures.
ACME or your own certificate¶
The relay operator owns certificate issuance, renewal and trust distribution. An externally supplied certificate is not automatically renewed by this customer procedure. The application customer should obtain a current trust receipt rather than deploying a second competing relay during pairing.
Auth key¶
Self-hosted managed registration uses the enrolled tenant key and independent source salt. They are private inputs, not Helm values, Kubernetes Secrets or printed ctb1 tokens. The complete registered operator introduction is delivered through the private runtime receiver as described in the customer procedure.
After deployment¶
Continue with EU host and Port installation. Installing the production cluster profile follows the source/authority/finite-Port steps; it does not call the obsolete flag-only Port startup or the legacy ctb1 pairing examples. Test the protected application, rotation, relay loss and recovery before treating the topology as qualified.
Network requirements¶
| Side | Direction | Destination | Port |
|---|---|---|---|
| EU Port | Outbound | Enrolled beacon | TCP 443/TLS |
| Cluster broker | Outbound | Same beacon | TCP 443/TLS |
| Relay | Inbound | Port and broker | TCP 443/TLS |
| EU management session | Outbound | Target Kubernetes API | Actual verified API port |
High availability¶
Relay HA, admission HA and finite Port-process supervision are separate concerns. Use the relay owner's qualified topology and maintenance policy. A production values file alone does not prove any of them. Follow the matched release's HA qualification gates rather than increasing replica counts independently.