Skip to content

Beacon Relay Trust Model

The beacon relay is customer-deployed infrastructure. You run the beacon process; it sits in your tenancy, under your legal control, on your network. The design exists to serve one compliance-and-security property: no inbound ingress on either side -- no public secret-store listener, no cluster LoadBalancer, no VPN. A vendor sitting in the TCP path would defeat that property by reintroducing third-party exposure at the metadata layer; cloudtaser does not operate any beacon in your data path.

This page exists so you can answer, with evidence, the question every serious security reviewer will ask:

"What does the beacon see, and what can it possibly disclose?"

Since the beacon is yours, the answer is about what the architecture can technically reveal to anyone who runs a beacon process -- not about what some vendor holds. TLS terminates at the bridge and at the operator broker. The relay forwards ciphertext bytes. It holds no keys, no plaintext, no configuration state.

This page is a companion to the Sovereign Deployment Decision Guide -- which covers where your secret store 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. See Preview Status & Roadmap for the honest state of audits, SOC 2 timelines, and reference customers. This page describes the trust model, which is architectural and does not depend on preview/GA status.

Public demo beacon: live demo / quick-look pilots only

cloudtaser operates a public demo relay at beacon.cloudtaser.io to support the live demo at cloudtaser.io/demo-lab and quick-look pilots. It is not for production use; using it places connection metadata on infrastructure you do not operate, which defeats the architectural point of the beacon pattern. Every production deployment runs its own beacon. The Beacon Relay page has the Helm chart and standalone binary instructions.

TLS trust for beacon.cloudtaser.io: As of operator v0.9.2 and CLI v0.17.14, the operator and CLI validate beacon.cloudtaser.io using x509.SystemCertPool() — the OS trust store. The beacon serves an ACME-issued (Let's Encrypt) certificate; no manual cert pinning or CA bundle is needed when targeting the public demo beacon. Self-hosted beacons continue to support explicit cert pinning via Helm values.

Why customer-operated is the only architecturally coherent posture

The compliance-and-security property the beacon pattern delivers is zero inbound ingress on both the secret store and the cluster. That eliminates a whole class of attack surface (unauthenticated reachability, NAT-traversal complexity, provider-specific LoadBalancer quirks, the operational cost of keeping a publicly-reachable Vault endpoint patched) and makes the network security story the same on every substrate -- Hetzner, OVH, GKE, EKS, AKS, on-prem.

If a vendor operates the relay in your production data path, the property still holds technically (the relay sees ciphertext) but the metadata disclosure layer reintroduces third-party exposure:

  • "Cluster X at IP-range A is paired with secret store Y at IP-range B" is non-trivial intelligence for an M&A scenario, a sanctions-compliance audit, or a nation-state adversary.
  • Any regulated-deployment DPIA that would otherwise say "no third party sits between my secret store and my cluster" has to now argue "...except the beacon vendor, and here is why their jurisdictional posture and retention policy are acceptable." That's a conversation you don't have to have if the beacon is yours.
  • Any contractual requirement for EU sovereignty (SecNumCloud-qualified, BSI-C5 full-scope, ANSSI Essential) becomes incompatible with a vendor-operated relay regardless of what the vendor can or cannot see.

The design intent is therefore unambiguous: customer-deployed is the default and the only production-supported pattern. The public demo relay at beacon.cloudtaser.io exists to support quick-look evaluations and the live demo at cloudtaser.io/demo-lab; both are pre-procurement contexts where the metadata disclosure is acceptable by construction.

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 whoever runs the beacon process (i.e., you)

Data category Why it's visible Retention
Source/destination IP addresses TCP socket metadata Whatever your log policy says
Connection timestamps (open/close) Relay pairing log Whatever your log policy says
Byte counts per connection Rate-limiting, abuse detection Whatever your log policy says
info_hash (SHA-256 of bridge CA) Required for pairing Whatever your log policy says
Heartbeat cadence TCP keepalive interval Not logged by the beacon binary
TLS handshake size/timing Observable in TCP stream Not logged by the beacon binary

The defaults in the Helm chart store nothing at all beyond the current in-memory connection map; operators can add structured logs with their chosen retention policy if their audit regime requires them.

Explicitly NOT visible to anyone running a beacon

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 a beacon cannot produce under any compulsion

Irrespective of who operates a beacon, the process cannot produce what it does not hold. The complete list of what any beacon operator (you, in a production deployment) could ever disclose is bounded by the first table above:

  1. Source/destination IPs and timestamps from the connection log.
  2. Byte-count aggregates.
  3. info_hash values (opaque SHA-256 digests, not reversible to CA content).
  4. Whatever operational records the operator chooses to retain.

The 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.

In a customer-operated production deployment, items 1–4 never leave your tenancy. Your data controller defines retention; your legal team handles any lawful-access request; no third party is in the picture.

Operating your own beacon

You deploy and operate the beacon. The code and Helm chart are public; the binary is bit-for-bit reproducible from source; cosign signatures and SBOMs are published per release.

What you get

  • 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. For the production pattern (customer-operated beacon), the row is straightforward:

DPIA field Value
Controller Your organisation
Processor None (beacon is customer-operated infrastructure)
Categories of personal data disclosed to third parties None -- the beacon process runs in your tenancy
Lawful basis Not applicable (no third-party processing)
Data retention You define (source/destination IPs, timestamps, byte counts are operational metadata, retained per your policy)
Cross-border transfer None (keep your beacon instance on EU-sovereign substrate per the Sovereign Deployment Decision Guide)

If you use the public demo beacon for a pilot (pre-procurement, not covered by your production DPIA), the processor row changes to reflect cloudtaser's temporary role as the demo relay operator; by that point you should already be planning a customer-deployed beacon for the production cutover, so this is a pilot-only consideration rather than an ongoing DPIA artefact.

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 (your deployed beacon) Whatever issuer you pick (Let's Encrypt or internal CA). For self-hosted beacons you pin the cert via Helm values; for beacon.cloudtaser.io the operator and CLI use x509.SystemCertPool() and validate the ACME-issued cert against the OS trust store — no manual pinning needed openssl s_client -connect beacon.your-company.example: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 your secret store 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.

Compelled disclosure: where it lands in this architecture

In a production (customer-operated) deployment, cloudtaser is not in your data path and not in your metadata path. A lawful-access instrument against cloudtaser cannot produce your beacon connection logs, because cloudtaser doesn't hold them -- you do. A lawful-access instrument against your beacon operator (you) produces the four categories in the first table above, bounded by your own retention policy.

For the public demo beacon (used by the live demo at cloudtaser.io/demo-lab and quick-look pilots only), the temporary operator is cloudtaser. If a valid legal instrument were served, the scope is still bounded by the same architecture:

  1. Verify the legal instrument through counsel.
  2. Where the instrument permits notification, notify the affected pilot user.
  3. Produce only the connection metadata described above. No cryptographic material, no content, no tunnel interior -- the architecture does not hold any of that.
  4. Publish an aggregated Transparency Report annually (starting for reporting year 2026) covering the demo relay's activity -- following the model of Cloudflare and Mullvad.

The architectural invariant is the same in both cases: the relay cannot produce what it cannot see. Customer-operated removes any third-party exposure to even the connection-metadata layer; the demo beacon exists to lower the evaluation barrier for new users and is scoped accordingly.