Skip to content

Beacon Relay Trust Model

The beacon relay is the default connectivity layer between your EU-hosted OpenBao and your US-managed Kubernetes cluster. A third party -- CloudTaser, the company -- sits in the TCP path between your secrets and your workloads when you use the operated beacon. This page exists so you can answer, with evidence, the question every serious security reviewer will ask:

"What does the beacon operator see, and what can it be compelled to disclose?"

This page is a companion to the Sovereign Deployment Decision Guide -- which covers where OpenBao and compute are hosted -- and the Beacon Relay architecture page -- which covers how the relay works. Read those first if you haven't.

Preview status

CloudTaser is in Preview. The operated beacon relay has no published SLA and no third-party audit. See Preview Status & Roadmap for the honest picture and what's on the path to GA.

On company jurisdiction

CloudTaser's company jurisdiction and lawful-intercept posture are disclosed to customers during contractual review; they are not a substitute for running your own beacon. For the strongest sovereignty posture, self-host the beacon (see below). This page focuses on what the relay can technically see or not see -- which is independent of who operates it.

What the relay sees vs doesn't see

The beacon is a stateless TCP relay. It accepts two outbound TLS connections -- one from the bridge (running alongside your OpenBao) and one from the operator broker (running in your cluster) -- matches them by a SHA-256 info_hash, and forwards bytes bidirectionally between them. TLS terminates at the bridge on one side and at the broker on the other. The relay never holds a private key for either endpoint.

Explicitly visible to the beacon operator

Data category Why it's visible Retention (operated beacon)
Source/destination IP addresses TCP socket metadata 7 days (connection log)
Connection timestamps (open/close) Relay pairing log 7 days
Byte counts per connection Rate-limiting, abuse detection 30 days (aggregated)
info_hash (SHA-256 of bridge CA) Required for pairing 7 days (connection log)
Heartbeat cadence TCP keepalive interval Not logged; in-memory only
TLS handshake size/timing Observable in TCP stream Not logged

Explicitly NOT visible to the beacon operator

Data category Why it's invisible
Secret content TLS terminates at bridge and broker, not relay
Vault/OpenBao paths Inside the mTLS tunnel
Pod names, namespaces, cluster identifiers Inside the mTLS tunnel
Service account tokens, JWTs Inside the mTLS tunnel
Any plaintext above the TLS layer End-to-end mTLS is enforced
Which secret a given pod requested Request bodies are encrypted
OpenBao root keys or unseal shares Never traverse the relay

The relay cannot lie about this

The TLS certificates at each end are pinned via the info hash exchanged during self-bootstrap. A beacon operator attempting to MITM would have to present a cert signed by a CA whose hash matches the one already pinned at both endpoints -- which requires compromising the OpenBao-side bridge CA material. See the self-bootstrap protocol for the pinning chain.

What the operated beacon cannot produce under any compulsion

Irrespective of the legal instrument or jurisdiction, the operated beacon cannot produce what it does not hold. The complete list of what a beacon operator could ever disclose is bounded by the first table above:

  1. Source/destination IPs and timestamps from the connection log (7-day retention).
  2. Byte-count aggregates from the abuse-detection log (30-day retention).
  3. info_hash values (opaque SHA-256 digests, not reversible to CA content).
  4. Billing/contract records held at the company level.

The operated beacon cannot produce: secret content, vault paths, pod identities, session keys, TLS private keys for the bridge or broker, or any data inside the mTLS tunnel. That invariant is enforced by the relay architecture (TLS terminates at bridge and broker, never at the relay), not by policy.

If your threat model treats connection metadata (the four categories above) as unacceptable in a third party's hands, self-host the beacon. The code and Helm chart are in the open, the feature is first-class, and running it is the intended escape hatch.

Self-hosting the beacon

Running your own beacon is a first-class, supported configuration -- not an afterthought. For customers where even connection metadata in a third party's hands is unacceptable (EU-sovereignty-hard sectors, government, defence), self-hosting is the intended path.

What you get by self-hosting

  • No third-party visibility into connection metadata.
  • Logs live entirely within your tenancy, under your data-controller control.
  • You configure retention, access controls, and disclosure policy.
  • Your legal team is the only legal team in the picture.

What you take on

  • Operating a stateless TCP relay on port 443 (minimal -- the beacon is ~2 MB of Go, no database, no persistence).
  • HA topology (recommended: 3 replicas across availability zones with gossip for connection state).
  • TLS cert management for the relay endpoint (Let's Encrypt or your internal CA).
  • Monitoring, capacity planning, incident response for the relay itself.

Helm values

# Install your own beacon (in any EU cluster or EU VM)
beacon:
  enabled: true
  replicas: 3
  ingress:
    host: beacon.your-company.example
    tls:
      issuer: letsencrypt-prod
  # No secrets to configure -- the beacon is stateless.

Point your bridge and operator at your own beacon:

# cloudtaser-onprem (bridge side)
bridge:
  beacon:
    address: beacon.your-company.example:443

# cloudtaser (operator side)
operator:
  broker:
    beacon:
      address: beacon.your-company.example:443

See cloudtaser-beacon for the source, Helm chart, and release binaries. The info_hash exchange is unchanged: your bridge and operator compute SHA-256 over the same bridge CA you've already generated; the beacon matches them regardless of who operates it.

Beacon code is the same

The binary you self-host is bit-for-bit identical to the operated beacon. Cosign signatures and SBOMs are published per release so you can verify what you deploy is what was audited. See Supply-Chain Evidence for the verification path.

DPIA checklist

If you're writing a Data Protection Impact Assessment that covers CloudTaser, the beacon relay is a distinct processing activity that deserves its own row. Copy the relevant block:

If you use the CloudTaser-operated beacon

DPIA field Value
Controller Your organisation
Processor CloudTaser (company jurisdiction and lawful-intercept posture disclosed during contractual review)
Categories of personal data disclosed Connection metadata only -- source/destination IPs, timestamps, byte counts, and info_hash (an opaque SHA-256 digest). No content.
Lawful basis Contract (Art. 6(1)(b) GDPR) -- performance of the CloudTaser beacon service
Data retention 7 days (connection log), 30 days (aggregated byte counts)
Cross-border transfer Disclosed during contractual review; sub-processor list and adequacy posture published in the DPA
Data processor agreement Standard CloudTaser DPA, Art. 28 GDPR compliant
Sub-processors EU infrastructure providers (list published and kept current)
Data subject rights Exercisable via CloudTaser; connection metadata is tied to your installation, not end users

If you self-host the beacon

DPIA field Value
Controller Your organisation
Processor None (self-hosted)
Categories of personal data disclosed to third parties None
Lawful basis Not applicable (no third-party processing)
Data retention You define
Cross-border transfer None

Cryptographic evidence for pinning

The trust root in a CloudTaser deployment is a small set of public keys and hashes. Each is pinnable; each can be verified independently by your security team.

Artifact Where it lives How to obtain the hash
OpenBao public TLS certificate EU-hosted OpenBao instance you operate openssl s_client -connect vault.example:8200 \| openssl x509 -fingerprint -sha256
Bridge CA public cert Generated during cloudtaser-cli source register, stored in OpenBao at cloudtaser/bridge/ca bao kv get -field=ca cloudtaser/bridge and openssl x509 -fingerprint -sha256
Operator broker public cert Minted by bridge during self-bootstrap, visible to cluster operators kubectl get secret cloudtaser-operator-broker-tls -n cloudtaser-system -o jsonpath='{.data.tls\.crt}' \| base64 -d \| openssl x509 -fingerprint -sha256
Beacon TLS cert (operated beacon) Let's Encrypt signed, pinned hash published in release notes openssl s_client -connect beacon.cloudtaser.io:443 \| openssl x509 -fingerprint -sha256
Beacon binary Signed with cosign; SBOM published per release cosign verify ghcr.io/cloudtaser/cloudtaser-beacon:vX.Y.Z
Operator container image Signed with cosign; supply-chain details in Operational Readiness cosign verify ghcr.io/cloudtaser/cloudtaser-operator:vX.Y.Z

Attestation path (when on confidential compute)

When you host OpenBao on AWS Nitro Enclaves or Azure DCsv5, the trust root extends further: key release from KMS is gated on a measured-state attestation quote. See the Sovereign Deployment Decision Guide for the provider-specific attestation chains and the evidence an auditor expects to see.

Honest statement of what we'd do under compulsion

If CloudTaser receives a valid legal instrument targeting a specific customer, we would:

  1. Verify the legal instrument through counsel.
  2. Where the instrument permits notification, notify the affected customer (transparency report).
  3. Produce only the connection metadata described above. We cannot produce content we do not hold.
  4. Publish an aggregated Transparency Report annually (starting for reporting year 2026), listing number of requests received, number complied with, and jurisdictions of origin -- following the model of Cloudflare and Mullvad.

Specific lawful-intercept instruments that apply to the operated beacon are disclosed during contractual review. Regardless of the instrument, the relay's architecture bounds what can be disclosed -- the operator does not hold cryptographic material, secret content, or anything inside the mTLS tunnel. If the residual exposure of connection metadata is unacceptable for your deployment, self-host the beacon. The code and Helm chart are in the open, the feature is first-class, and running it is the intended escape hatch.