bbyoc anywhere
IV
commandment IV

Identity Over Secrets

Prove both ends of every connection with cryptographic identity, and mint every credential on demand from that proof.

 proof on every connection, expiry on every credential
EVERY CONNECTION: MUTUAL PROOFagentclient certCN = cell-idcontrol planeserver cert +verified client identitymTLS · TLS 1.3 · both ends verifiedrouting + authority keyed to the certificate, never the network addressEVERY CREDENTIAL: MINTED, NOT STOREDworkload tokenOIDC JWTcloud STSAssumeRoleWith​WebIdentitytemp credentialsTTL ≈ 1 hourtrust policy pins issuer + audience + exact service account;a stolen token buys minutes in one cell, not tenancyno static keys, ever

In BYOC your control plane and the customer's account share no network perimeter, so network position proves nothing about who is calling. Require cryptographic proof of both parties on every connection that crosses the account boundary: mutual TLS with a modern protocol floor such as TLS 1.3, client certificate required and verified on both ends. Make the identity specific. Embed the deployment cell's identity in the certificate itself, and have the control plane route work and scope authority by the identity the certificate asserts. The path a request arrived on, whether VPN, peering, or a private endpoint, grants nothing.

Enforce this at both ends. The agent fails closed: without a valid certificate naming its cell, it refuses to start. Hold operator access to the same standard. Admit a kubectl session brokered through the control plane only when it presents a client certificate naming the target cell, so an operator credentialed for one cell has no path into another.

Reach the customer's cloud APIs through workload identity federation, never through a static access key handed over during onboarding. A static key is a standing secret: it sits in a database, leaks into logs, and works from anywhere for as long as it exists. Under federation, your workloads prove who they are with identity tokens issued by their own runtime, such as a Kubernetes service-account JWT over OIDC, and the customer's cloud exchanges that proof for short-lived credentials: AssumeRoleWithWebIdentity with IRSA on AWS, Workload Identity Federation on GCP, Workload Identity on Azure. The credentials expire quickly and the cloud SDK rotates them automatically. Your control plane creates, transmits, and stores no cloud keys in either direction, which leaves nothing to vault, nothing to rotate by hand, and nothing to revoke during an incident.

Federation composes with conditions, and the conditions belong in the customer's account, written into an IAM trust policy the customer can read, audit, and revoke. Pin that policy to an exact workload: tokens must come from a named OIDC issuer, carry the required audience, and identify an exact service account in an exact namespace. A stolen token then buys minutes of narrowly scoped access before it expires, and Commandment I narrows that scope to a single cell.