Zero trust
“Zero trust” is easy to claim and hard to check. The useful version of the idea is narrow: being inside the perimeter grants nothing. A pod on the cluster network cannot reach another pod because it is on the network; an application cannot reach a cloud API because it is running in the right account.
What makes that real is whether each grant is enforced somewhere a reader can go and inspect.
Where trust is denied by default
The network. Every workload that runs a pod is expected to carry a
CiliumNetworkPolicy: default-deny, with explicit allows. The
constitution
requires it, and the App composition emits one so that applications get it
without asking.
Identity. Workloads reach AWS through EKS Pod Identity, never IRSA and
never static keys — the reasoning is in
ADR-0002.
Policies are scoped to xplane-* resources, and Crossplane holds no
deletion permissions for stateful services, so a compromised controller
cannot destroy a database or an S3 bucket.
Secrets. Nothing sensitive is committed. External Secrets Operator pulls from AWS Secrets Manager and OpenBao into Kubernetes Secrets at runtime.
Ingress. The cluster API endpoint is private. Platform services are reachable only over Tailscale, and the two private gateways are separated by ACL tag so that admin-only services are not merely unlisted but unreachable for non-admins.
Certificates. A private PKI issues every internal certificate through cert-manager, so TLS is not something applications opt into.
Enforced, not documented
The distinction that matters is between a rule written down and a rule that fails a build. In this repository:
- Kyverno rejects non-compliant workloads at admission
./scripts/validate-manifests.shaudits the rendered bundle for privilege escalation, capabilities and image tags before anything merges- the
Appcomposition emits the security context rather than trusting each author to include it
A rule that lives only in a document is a hope. Each of the above turns one into a gate.
Where the platform is honest about its gaps
A zero-trust claim is only worth reading if it also says where the model is relaxed. Two examples this repository documents rather than hides:
- The root CA private key is present in the live OpenBao mount, because the intermediate is signed inside OpenBao to keep the deploy unattended. Accepted for a reference platform; explicitly not to be carried into a deployment where the root CA matters. See PKI and secrets.
- Network policy coverage is uneven. The constitution requires a CiliumNetworkPolicy on every pod-running workload; the observability stack does not yet meet that bar. See Observability.
Both are the kind of thing a security page is tempted to omit. Omitting them would make the page less useful, not more convincing — a reader evaluating this platform needs to know which properties are enforced and which are aspirations with a known exception.
Reading on
- Security — the PKI chain, secret flow and policy engine as implemented
- Networking — how traffic reaches an application, and what stops it