Namespace-Scoped Certificate Rotation Without a Cluster-Wide CA

Most service meshes centralize trust in a cluster-wide CA. That simplifies bootstrapping and complicates everything else: rotation requires cluster-admin, a compromised intermediate can impersonate any workload, and upgrades touch every namespace at once. MeshAtom inverts the model — each secured namespace carries its own trust domain.

Trust domain = namespace

• Issuing CA (or intermediate) lives in the MeshAtom agent’s namespace-local secret store — never as a cluster-scoped resource other teams can read
• Workload identities are bound to namespace + ServiceAccount (or pod identity) and verified in eBPF before packets leave the host path
• Cross-namespace traffic is denied by default unless an explicit federated trust pin is configured between two namespaces

Rotation lifecycle

1. Bootstrap: On first enable, the agent generates a namespace CA (or accepts a customer-provided intermediate) and stores it in a namespace-scoped Secret owned by the MeshAtom service account.
2. Issue: Short-lived leaf certificates are minted for each workload identity and pushed into eBPF maps (SPIFFE-style URIs or MeshAtom identity keys).
3. Overlap: Before expiry, the agent issues a successor leaf and installs both old and new verification material in the kernel maps (dual-key window).
4. Cutover: New connections prefer the successor; in-flight flows continue on the predecessor until natural close.
5. Retire: After the overlap TTL, predecessor keys are removed from eBPF maps and the Secret is updated. No pod restart required for rotation itself.
6. CA rollover: Namespace CA rotation follows the same dual-trust window, scoped only to that namespace’s agents and maps.

t0  issue leaf-A → install verify(A) in eBPF map
t1  issue leaf-B → install verify(A,B)   ← overlap window
t2  workloads present leaf-B on new handshakes
t3  remove verify(A) after overlap TTL
    (namespace B's maps are untouched throughout)

Configuring rotation policy

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  annotations:
    meshatom.io/network-mode: "strict-mtls"
    # Leaf lifetime and overlap (seconds)
    meshatom.io/cert-ttl: "3600"
    meshatom.io/cert-overlap: "300"
    # Namespace CA rollover cadence (days)
    meshatom.io/ca-ttl-days: "30"
    # Optional: bring your own intermediate (Secret in this namespace)
    meshatom.io/ca-secret: "meshatom-ns-ca"

What you deliberately do not get

• No cluster-wide CA Secret readable by every controller
• No requirement for cluster-admin to rotate certificates in one team’s namespace
• No single control-plane outage that freezes identity issuance for the whole cluster