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 port and at the operator broker. The relay forwards ciphertext bytes. The relay has outer-TLS private keys, tenant authentication material and configuration. It does not hold the inner tunnel's private keys or decrypt its payload.

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.

Explicit relay choice; demo only

Customers choose their relay and control its TLS trust, tenant enrollment and restart custody. beacon.cloudtaser.io serves the hosted demo only. The chart and CLI P2P address default to that fleet unless overridden. Customer and pilot enrollment are unavailable; do not reuse demo identities or keys. See Beacon Installation for the customer path.

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: customers must select and configure their own relay for the customer path. The shipped chart and CLI P2P address default is beacon.cloudtaser.io:443; leaving it unset targets the demo fleet, so override it explicitly. The public relay at beacon.cloudtaser.io is demo only. Its metadata boundary does not authorize customer or pilot use.

What the relay sees vs doesn't see

The beacon is a stateful TCP relay. It accepts two outbound TLS connections -- one from the port (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 port 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 port 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

Inspect the chosen relay's actual logs and configuration; define metadata retention explicitly. No chart default is evidence of a zero-retention deployment.

Explicitly NOT visible to anyone running a beacon

Data category Why it's invisible
Secret content TLS terminates at port 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 port 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 port or broker, or any data inside the mTLS tunnel. That invariant is enforced by the relay architecture (TLS terminates at port 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 release binaries are public. Verify signatures and inspect SBOM availability for the selected 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 stateful TCP relay on port 443 (minimal -- the beacon is ~2 MB of Go, no database, optional ACME 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.

Deployment and retained state

The relay holds tenant registration keys, nonce replay caches, rate-limit and pairing/registry state, plus its outer TLS and gossip material. Optional ACME storage persists to the configured cache directory; without that directory ACME state is in memory. These are separate from endpoint mTLS private keys and application plaintext, which the relay does not receive. Memory state is scoped to process lifetime and configured expiry; disk retention and backups belong to the relay operator.

Published server and limiter state fields (inferred): acmeCacheProbe, activation, activeConns, activeRelays, addr, allowedSNISet, audit, authKeyMu, beforeParkCommit, certCache, certFile, certSwapper, cfg, closePublicListener, counters, expectedMembers, forwardClient, forwardServer, haAttachMu, handshakeSem, infoHashLimiter, keepaliveApplier, keyFile, lastMatchAt, lastRelayDurationNanos, lifecycleMu, limit, listenerFactory, logger, lru, maxEntries, membership, metrics, mu, nearMiss, noTenantNonceCaches, noTenantNonceEntries, nonceCache, nonceExpirations, nonceLimits, nonceMu, now, nowFunc, parkedConnsBySource, pendingConns, pendingConnsBySource, pendingRegistry, pendingSourceMu, preListenHook, preQuorum, rateLimiter, readyzFailing, relayAdmissionMu, relayWg, resumptionGrace, ring, sealed, serveCtx, serving, stopCleanup, stopCleanupOnce, tenantKeyCache, tenantNonceCaches, tlsConfigOverride, tlsHandshakeTimeout, totalBytesRelayed, totalConnRejected, totalConnRejectedPerSource, totalConnected, totalErrors, totalForwardAttempts, totalForwardDialFailed, totalForwardHeaderFail, totalForwardLoops, totalForwardMTLSFailed, totalForwardOversized, totalForwardSuccess, totalHMACCompatAccepts, totalHandshakeTimeouts, totalMatches, totalNonceCacheCapHits, totalPanicsRecovered, totalPreviousAuthKeyAccepts, totalRateLimited, totalRateLimitedInfoHash, totalRelayCompletions, totalRelayDurationNanos, totalSNIRejected, totalTimeouts, unsealCallback, version, waiting, window.

Use the beacon installation procedure. The unified chart does not have a top-level beacon deployment block. Configure relay registration keys, TLS and retention explicitly.

Configure the Linux host Port and cluster operator through the host-Port installation procedure. It specifies the released cohort, relay trust and registration inputs, source authority and private Port/broker introduction. A relay address alone does not establish that identity or start an authorized Port session. Kubernetes Port deployment remains planned for this customer path; do not use legacy Port-chart values as a host installer.

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)

This table assumes a customer-operated relay. If someone else operates your chosen relay, assess that operator's metadata processing, jurisdiction and retention explicitly. The CloudTaser demo fleet is not available for customer or pilot enrollment.

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
Port CA public cert Generated during cloudtaser-cli source register, stored in OpenBao at cloudtaser/port/ca bao kv get -field=ca cloudtaser/port and openssl x509 -fingerprint -sha256
Operator broker public cert Minted by port 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 checksum manifest; SBOM not available at the beacon v0.6.23 release URL Follow the matched binary verification with the pinned release key.
Operator container image Cosign key signature; transparency-log inclusion is not established Follow the image digest/signature verification example, which is untested for this matched release set.

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 only by the hosted demo, offline until beta), 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, follow the demo operator's applicable notification obligations.
  3. Produce only the connection metadata described above. The relay cannot decrypt the inner tunnel. Outer-TLS and tenant keys are separate relay assets; their custody must be assessed.
  4. Document the actual demo metadata retention and disclosure process; no reporting commitment is established here.

The payload boundary is the same in both cases: the relay does not hold the inner tunnel keys. 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.