pod-cert-signer — ein Signer für Pod-Zertifikate, der CA-Schlüssel bleibt in KMS.

Warum ein eigener Signer

Kubernetes 1.37 hat Pod-Zertifikate stabil gemacht, aber keinen Signer mitgeliefert. Die Unterstützung in cert-manager ist seit Januar offen (cert-manager#8378). Ich brauchte Zertifikate für die CrowdSec-Agenten in meinem Cluster, die aus fremden Namensräumen mit der zentralen LAPI sprechen, und keine weitere geteilte CA im Cluster. Wie die Umstellung lief, mit allen Hindernissen, steht im Praxisbericht.

Der Signer ist klein gehalten, weil er die privilegierteste Komponente ist. Die Kubernetes-API spricht er mit ein paar hundert Zeilen auf der Standardbibliothek statt mit client-go. Das AWS-SDK nutzt er nur für Credentials und KMS: Authentifizierung schreibt man nicht selbst. Getestet wird gegen einen Fake-API-Server, der das Watch-Protokoll spricht und die Zeitregeln der API durchsetzt. Ein Mutationslauf entfernt zehn Regeln einzeln, und jede Mutante muss rot werden.

So bekommt ein Pod sein Zertifikat

Das CA-Zertifikat erzeugt der Signer einmal selbst, mit dem Schlüssel in KMS. Es trägt kritische Name-Constraints: nur .svc, .svc.cluster.local und die eigene Trust-Domain.

KMS_KEY_ID=alias/pod-cert-signer pod-cert-signer init \
  -cn "Example workload CA" -trust-domain example.com > ca.crt

Ein Pod fordert sein Zertifikat mit einem Volume an:

volumes:
  - name: tls
    projected:
      sources:
        - podCertificate:
            signerName: example.com/workload
            keyType: ECDSAP256
            keyPath: tls.key
            certificateChainPath: tls.crt
        - clusterTrustBundle:
            signerName: example.com/workload
            labelSelector: {}
            path: ca.crt

Der Pod startet erst, wenn das Zertifikat ausgestellt ist. Wer was bekommt, steht in einer JSON-Policy, gemountet aus einer ConfigMap:

{"namespace": "team-a", "serviceAccount": "api", "usage": "server",
 "dnsNames": ["api.team-a.svc", "api.team-a.svc.cluster.local"]}

Alles, was nicht gewährt ist, wird abgelehnt, mit einem von vier Gründen: NoGrant, UnsupportedKeyType, DNSNameNotGranted, InvalidStubPKCS10Request. Selbst ein umgangener Policy-Check kann wegen der Name-Constraints kein Zertifikat für einen öffentlichen Namen ausstellen.