PKIaaS für interne Entwicklerplattformen

Plattformentwicklungsteams werden immer wieder mit denselben Anforderungen in unterschiedlichen Formen konfrontiert. Entwickler benötigen TLS-Zertifikate für ihre Dienste. CI/CD-Pipelines benötigen Anmeldeinformationen, die keine fest codierten API-Schlüssel sind. Kubernetes-Workloads benötigen mTLS-Identitäten. Das Sicherheitsteam erwartet, dass all dies mit einheitlichen Richtlinien, nachvollziehbarer Zertifikatsausstellung und ohne manuelle PKI-Eingriffe bei jeder Anfrage umgesetzt wird. Die übliche Lösung des Plattformteams ist ein Dienstkonto, ein gemeinsam genutztes Zertifikat oder ein selbstsigniertes Zertifikatsskript, das im Repository hinterlegt wird. Keine dieser Lösungen ist optimal.

Die richtige Antwort ist PKIaaS als Plattformfunktion: Das Plattformteam integriert eine verwaltete Zertifizierungsstelle einmalig in den Identitätsanbieter (IDP), stellt sie über ACME, cert-manager und eine API bereit, und Entwickler erhalten eine Self-Service-Zertifikatsausstellung, die die Sicherheitsrichtlinien des Teams automatisch durchsetzt, ohne dass der Entwickler wissen muss, was ein Zertifikatsprofil ist. Dieser Beitrag erklärt, wie diese Funktion implementiert wird.

Kurzantwort: Wie sieht PKIaaS als IDP-Funktion aus?

PKIaaS wird zu einer IDP-Funktion, sobald das Plattformteam das PKIaaS-CA-Backend konfiguriert, Zertifikatsprofile für jeden Workload-Typ definiert und diese Profile über die Standardschnittstellen der Plattform bereitstellt: einen cert-manager ClusterIssuer für Kubernetes-Workloads, einen ACME-Endpunkt mit OIDC-Authentifizierung für CI/CD-Pipeline-Jobs, ein Terraform-Provider-Modul für Infrastructure-as-Code-Nutzer und eine Backstage-Servicekatalogvorlage für Teams, die einen UI-basierten Anfrageprozess bevorzugen. Entwickler fordern Zertifikate über die ihnen bereits vertraute Schnittstelle an. Die PKIaaS-CA setzt die Zertifikatsrichtlinie des Plattformteams ohne zusätzliche Komplexität für Entwickler durch. Die CLM-Schicht ermöglicht dem Sicherheitsteam die Überprüfung des gesamten Zertifikatbestands über alle Plattform-Tenants hinweg.

Wichtige Erkenntnisse

• Die Plattformteams sind für die Richtlinien zur Zertifikatsausstellung verantwortlich, nicht die Anwendungsentwickler. Das Plattformteam legt die Rahmenbedingungen einmalig fest (gültige Zertifikatsprofile, Namensbeschränkungen, Gültigkeitsdauer, Mindestanforderungen an den Schlüsselalgorithmus). Entwickler fordern Zertifikate innerhalb dieser Rahmenbedingungen an, ohne deren Existenz zu kennen. Dieses bewährte Modell wenden Plattformteams auch auf Container-Basis-Images, Terraform-Module und Observability-Konfigurationen an.
• cert-manager ist die Kubernetes-Schnittstelle zwischen Entwickler-Workloads und der PKIaaS-Zertifizierungsstelle. Das Plattformteam stellt cert-manager bereit und konfiguriert einen ClusterIssuer, der auf den PKIaaS-ACME-Endpunkt verweist. Entwickler deklarieren Zertifikatsressourcen in ihren Kubernetes-Manifesten; cert-manager übernimmt die Ausstellung, Speicherung als Kubernetes Secrets und die automatische Verlängerung. Nach der ersten Deklaration ist keine weitere Interaktion seitens der Entwickler erforderlich.
• Der Austausch von OIDC-Tokens ermöglicht CI/CD-Pipeline-Zertifikate ohne vorab geteilte Geheimnisse. Moderne CI/CD-Plattformen (GitHub Actions, GitLab CI, CircleCI) stellen OIDC-Tokens für Pipeline-Jobs aus, die über den ACME External Account Binding-Mechanismus gegen kurzlebige PKIaaS-Zertifikate eingetauscht werden können. Das Zertifikat des Pipeline-Jobs ist nur für die Dauer des Jobs gültig und läuft automatisch ab. Eine Rotation der Geheimnisse ist nicht erforderlich.
• Zertifikatsanforderungsvorlagen vereinfachen die Anforderung an Entwickler, Zertifikate anzufordern. Die Vorlagen definieren gültige Subjektnamensmuster, SAN-Typen, Gültigkeitszeiträume und die Schlüsselverwendung für jede Zertifikatskategorie. Entwickler wählen eine Vorlage aus; die Plattform setzt die Vorgaben der Vorlage durch. Entwickler müssen weder wissen, was eine Extended Key Usage OID ist, noch was die Baseline Requirements des CA/B Forums zur SAN-Formatierung aussagen.
• Die im CA/B Forum SC-081v3 festgelegte maximale Gültigkeitsdauer von 47 Tagen (gültig ab 15. März 2029) schreibt die automatische Erneuerung aller öffentlichen TLS-Zertifikate vor. Plattformteams, die die PKIaaS-gestützte automatische Erneuerung in ihren Identitätsanbieter integrieren, entwickeln daher bereits jetzt die Compliance-Lösung vor Ablauf der Frist und müssen nicht mehr in letzter Minute die Automatisierung in einen manuell verwalteten Zertifikatsbestand einbauen.

Das Plattform-Engineering-Problem mit Zertifikaten

Plattformteams stehen vor einer spezifischen Variante des Zertifikatsmanagementproblems, die sich von dem unternehmensweiten Problem der Zertifikatsverwaltung für Sicherheitsteams unterscheidet. Sicherheitsteams kümmern sich um den gesamten Zertifikatsbestand: Ermittlung, Inventarisierung, Richtlinienkonformität und Ablaufüberwachung aller Zertifikate aus allen Quellen. Plattformteams hingegen beschäftigen sich mit einem enger gefassten, aber operativ dringlicheren Problem: Wie erhalten Entwickler Zertifikate für ihre Workloads, ohne eine Warteschlange beim PKI-Team zu verursachen, ohne Geheimnisse in Repositories zu speichern und ohne einen Zertifikatsbestand zu erzeugen, der in großem Umfang nicht mehr zu verwalten ist?

Die von Plattformteams verwendeten Muster, wenn PKIaaS nicht verfügbar ist, weisen alle denselben Fehler auf: Sie optimieren den Entwicklerkomfort auf Kosten der Sicherheit und der operativen Verwaltbarkeit. Wildcard-Zertifikate, die von mehreren Diensten gemeinsam genutzt werden, eliminieren zwar die dienstspezifische Zertifikatsverwaltung, heben aber auch die dienstspezifische Isolation auf: Ein kompromittierter Dienst kann die Wildcard verwenden, um sich als jeder andere auszugeben. Selbstsignierte Zertifikate beseitigen zwar den Engpass im PKI-Team, zerstören aber auch die Vertrauenskette, die mTLS erst sinnvoll macht. Langlebige Dienstkonto-Anmeldeinformationen bieten zwar eine praktikable Übergangslösung, stellen aber eine technische Schuld dar: Sie erfordern Rotationsereignisse, die in einer großen Entwicklerorganisation schwer zu koordinieren sind.

PKIaaS als IDP-Funktion beseitigt diese Kompromisse. Entwickler profitieren von der benutzerfreundlichen Self-Service-Schnittstelle (Zertifikatsressource im cert-manager, Terraform-Modulaufruf, Backstage-Vorlage). Die Zertifikatssicherheit wird durch die PKIaaS-CA gewährleistet (FIPS 140-3 Level 3 HSM-basierte Schlüssel, richtliniengesteuerte Ausstellung, automatischer Ablauf). Die operative Verwaltung erfolgt über die CLM-Schicht (einheitliches Inventar, automatische Verlängerung, Überwachung der Richtlinienkonformität). Das Plattformteam konfiguriert die Integration einmalig; Entwickler nutzen sie dauerhaft.

Kubernetes-Integration: cert-manager als IDP-Schnittstelle

Für Plattformteams, die Kubernetes-basierte Identitätsanbieter (IDPs) betreiben, ist cert-manager die Standardschnittstelle zwischen Entwickler-Workloads und der PKIaaS-Zertifizierungsstelle. Die Integrationsarchitektur besteht aus drei Schichten, die vom Plattformteam einmalig konfiguriert werden.

ClusterIssuer-Konfiguration

Das Plattformteam installiert cert-manager in jedem Cluster und erstellt einen ClusterIssuer (oder mehrere Namespace-bezogene Issuer für Multi-Tenant-Cluster mit unterschiedlichen Zertifikatsrichtlinien pro Mandant), der auf den PKIaaS-ACME-Endpunkt verweist. Die ClusterIssuer-Konfiguration legt die ACME-Server-URL, die EAB-Schlüssel-ID (External Account Binding) und das HMAC-Geheimnis fest, die von der PKIaaS-CA für diesen Cluster ausgestellt wurden, sowie die DNS- oder HTTP-Challenge-Konfiguration zur Domänenvalidierung. Für interne Dienste, die privates DNS verwenden (was in einer Enterprise-Kubernetes-Umgebung typisch ist), ist die DNS-01-Challenge gegen den internen DNS-Anbieter der Organisation der geeignete Challenge-Typ.

Sobald der ClusterIssuer konfiguriert und validiert ist, kann jede Zertifikatsressource in jedem Namespace ihn als Aussteller referenzieren. Das Plattformteam steuert über die CertificateRequestPolicy (die Richtliniengenehmigungskomponente von cert-manager) in Kombination mit Kubernetes RBAC, welche Namespaces welche Aussteller verwenden dürfen. Ein Anwendungsnamespace kann beispielsweise nur Zertifikate mit SANs anfordern, die dem zugewiesenen Domänenmuster des Namespaces entsprechen; ein Systemnamespace kann hingegen Zugriff auf einen anderen Aussteller haben, der infrastrukturspezifische Zertifikatstypen zulässt.

Entwicklerorientierte Zertifikatsressourcen

Aus Entwicklersicht sieht die Anforderung eines Zertifikats im Kubernetes-Identitätsanbieter (IDP) folgendermaßen aus: Im Helm-Chart oder Kustomize-Overlay des Dienstes wird eine Zertifikatsressource deklariert, die den gewünschten Betreff und die SANs angibt. Anschließend wird der vom Anbieter bereitgestellte ClusterIssuer referenziert und die Anwendung bereitgestellt. cert-manager erstellt eine Zertifikatsanforderung (CertificateRequest), übermittelt die CSR an den PKIaaS-ACME-Endpunkt, führt die Domänenvalidierung durch, ruft das signierte Zertifikat ab und speichert es als Kubernetes-Secret. Die Anwendung referenziert das Secret in ihrer Pod-Spezifikation als Volume-Mount oder Umgebungsvariable. Das Zertifikat ist innerhalb weniger Sekunden nach Anwendung der Zertifikatsressource im laufenden Pod verfügbar.

Wenn das Zertifikat sich dem Ablaufdatum nähert (standardmäßig erneuert cert-manager es, sobald zwei Drittel der Gültigkeitsdauer verstrichen sind), fordert cert-manager automatisch eine Erneuerung vom PKIaaS ACME-Endpunkt an. Das erneuerte Zertifikat ersetzt das ablaufende Zertifikat im Kubernetes-Secret. Anwendungen, die das Secret als Volume einbinden, erhalten das neue Zertifikat beim nächsten Dateisystem-Sync ohne Pod-Neustart. Anwendungen, die den Zertifikatswert beim Start zwischenspeichern, benötigen einen Rolling Restart, den cert-manager bei entsprechender Konfiguration automatisch auslösen kann. Entwickler müssen weder die Ablaufdaten von Zertifikaten überwachen noch die Erneuerung manuell initiieren.

Richtlinien-Schutzmechanismen über CertificateRequestPolicy

Der Richtliniengenehmiger von cert-manager fügt die Durchsetzungsebene hinzu, die den ACME-basierten cert-manager von einem praktischen Zertifikatstool in eine Plattform mit geregelten Funktionen verwandelt. CertificateRequestPolicy-Ressourcen definieren, welche Zertifikatsanforderungen für jeden Namespace oder Anforderer zulässig sind. Eine Richtlinie könnte beispielsweise SANs zulassen, die dem Muster entsprechen. *.namespace-name.svc.cluster.localDie Schlüssellänge muss mindestens RSA-2048 oder ECDSA-256 betragen, die Zertifikatsgültigkeit maximal 90 Tage. Die erweiterte Schlüsselverwendung ist ausschließlich für die TLS-Serverauthentifizierung und die TLS-Clientauthentifizierung zulässig. Jede Zertifikatsanforderung, die keiner genehmigten Richtlinie entspricht, wird abgelehnt, bevor die CSR die PKIaaS-CA erreicht. Die Ablehnung wird protokolliert, ist für das Plattformteam im cert-manager-Audit-Log sichtbar und wird im CLM-Inventar als Richtlinienverstoß angezeigt.

Dies bietet dem Plattformteam die notwendigen Schutzmechanismen für sichere Self-Service-Anwendungen: Entwickler können jedes Zertifikat anfordern, das den Richtlinien entspricht, ohne Genehmigungswarteschlange oder manuelle Prüfung. Anfragen, die nicht den Richtlinien entsprechen, werden automatisch mit einer Fehlermeldung abgelehnt, die dem Entwickler die verletzte Richtlinie und das korrekte Vorgehen erläutert. Das Sicherheitsteam definiert die Richtlinien; die Plattform setzt sie automatisch durch; Entwickler können reibungslos innerhalb dieser Richtlinien arbeiten.

Ausstellung von CI/CD-Pipeline-Zertifikaten

CI/CD-Pipeline-Jobs benötigen Anmeldeinformationen aus einem anderen Grund als laufende Dienste: Sie müssen sich während des Build-Prozesses bei Bereitstellungszielen, Container-Registries, Artefaktspeichern und dem PKIaaS-Codesignaturdienst authentifizieren. Die Zertifikatsberechtigung für einen CI/CD-Job sollte nur für die Dauer dieses spezifischen Joblaufs gültig sein, nicht unbegrenzt.

OIDC-Token-Tausch gegen Pipeline-Zertifikate

Moderne CI/CD-Plattformen stellen OIDC-Token für Pipeline-Jobs aus, die die Identität des Jobs kodieren: Repository, Branch, Workflow-Name und Umgebung. Diese Token sind kurzlebig und werden vom OIDC-Anbieter der CI/CD-Plattform signiert. Das Plattformteam konfiguriert den PKIaaS ACME-Endpunkt so, dass er diese OIDC-Token als EAB-Anmeldeinformationen (External Account Binding) über einen Token-Austauschprozess akzeptiert: Der Pipeline-Job präsentiert sein OIDC-Token an einen konfigurierten Austauschendpunkt, der das Token anhand des JWKS-Endpunkts der CI/CD-Plattform validiert und eine EAB-Anmeldeinformation ausstellt. Mit dieser EAB-Anmeldeinformation fordert der Pipeline-Job ein Zertifikat vom PKIaaS ACME-Endpunkt an.

Das resultierende Zertifikat ist für das konfigurierte Pipeline-Zertifikatprofil gültig (typischerweise 1 bis 4 Stunden, entsprechend der maximal erwarteten Pipeline-Laufzeit). Das Zertifikat kodiert die Identität der Pipeline im Betreff (Repository und Workflow im CN- oder SAN-URI-Feld). Wenn der Pipeline-Job dieses Zertifikat zur Authentifizierung bei Bereitstellungszielen oder Signaturdiensten verwendet, können diese Systeme die Identität der Pipeline anhand des Zertifikats überprüfen und Autorisierungsentscheidungen basierend auf dem ausgeführten Repository und Workflow treffen. Das Zertifikat läuft automatisch ab, sobald der Job beendet ist. Eine Rotation der Geheimnisse ist nicht erforderlich, da keine langlebigen Anmeldeinformationen ausgestellt werden und daher keine solchen rotiert werden müssen.

Code-Signaturzertifikate für Pipeline-Artefakte

Dieselbe PKIaaS-Zertifizierungsstelle, die Service- und Pipeline-Identitätszertifikate ausstellt, kann auch Codesignaturzertifikate für die Signierung von Container-Images, Binärdateien, Paketen und Bereitstellungsmanifesten ausstellen, die von der CI/CD-Pipeline erzeugt werden. Das Plattformteam konfiguriert ein separates Codesignaturzertifikatprofil in der PKIaaS-Zertifizierungsstelle (mit der Code Signing Extended Key Usage OID 1.3.6.1.5.7.3.3) und stellt es über die PKIaaS-REST-API oder einen dedizierten Signaturdienst bereit. Pipeline-Jobs, die Artefakte erzeugen, fordern über dieses Profil ein Signaturzertifikat an, signieren ihre Artefakte, und das Zertifikat läuft nach Beendigung des Jobs ab. Kubernetes-Zulassungscontroller (Sigstores Policy Controller, OPA/Gatekeeper mit Image-Verifizierungsrichtlinien) können Container-Image-Signaturen anhand der PKIaaS-Zertifizierungsstelle überprüfen, bevor sie die Bereitstellung zulassen. Dadurch wird sichergestellt, dass nur von autorisierten Pipeline-Jobs signierte Images im Cluster zugelassen werden.

Infrastructure-as-Code-Integration

Nicht alle Workloads in einem Enterprise-IDP laufen in Kubernetes. Virtuelle Maschinen, Bare-Metal-Services, Serverless Functions und Netzwerkgeräte benötigen Zertifikate, und ihre Plattformteams verwalten die Infrastruktur häufig mit Terraform, Pulumi oder Ansible anstatt mit Kubernetes-Manifesten. PKIaaS stellt eine REST-API bereit, die Infrastructure-as-Code-Tools direkt nutzen können.

Für Terraform-basierte Identitätsanbieter (IDPs) kann die HashiCorp Vault PKI-Secrets-Engine so konfiguriert werden, dass sie PKIaaS als Upstream-CA verwendet. Dadurch wird ein Vault-PKI-Mount bereitgestellt, den Terraform-Ressourcen über den Vault-Terraform-Provider nutzen. Das Plattformteam verwaltet die Vault-Konfiguration und die PKIaaS-CA-Integration. Die von Anwendungsteams entwickelten Terraform-Module nutzen den Vault-PKI-Mount, ohne die zugrunde liegende PKIaaS-CA zu kennen. Die Zertifikatsausstellung erfolgt im Rahmen der Terraform-Anwendung: Die Ressourcendefinition legt die gewünschten Zertifikatsparameter fest, Vault stellt das Zertifikat von seinem PKIaaS-basierten PKI-Mount aus, und das Zertifikat wird im Vault-Secret-Speicher abgelegt. Der Terraform-Status verweist auf den Vault-Secret-Pfad; der eigentliche private Schlüssel des Zertifikats wird niemals im Terraform-Status oder in einem Versionskontrollsystem gespeichert.

Für die Ansible-basierte Bereitstellung kann die PKIaaS REST-API direkt aus Ansible-Tasks aufgerufen werden. uri Die Verwaltung von ACME-Zertifikaten erfolgt entweder über ein Modul oder über von der Community entwickelte Ansible-Module. Das Plattformteam stellt eine standardisierte Ansible-Rolle bereit, die die PKIaaS-API zur Zertifikatsausstellung kapselt und die Schlüsselerzeugung, die CSR-Erstellung, die Übermittlung und die Zertifikatsspeicherung in einem Standardpfad auf dem bereitgestellten Host übernimmt. Anwendungsteams binden die Rolle mit Parametern, die den gewünschten Zertifikatstyp (entsprechend einem PKIaaS-Zertifikatsprofil) angeben, in ihre Playbooks ein; die Rolle kümmert sich um alles Weitere.

Backstage- und Servicekatalogintegration

Viele etablierte Plattformteams nutzen ein Entwicklerportal (Backstage ist die am weitesten verbreitete Open-Source-Lösung) als Frontend-Schnittstelle zum Identitätsanbieter. Für Entwicklungsteams, die einen UI-gesteuerten Anfrageprozess dem Schreiben von Kubernetes-Manifesten oder Terraform-Code vorziehen, kann die PKIaaS-Zertifikatsausstellungsfunktion als Softwarevorlage im Servicekatalog bereitgestellt werden.

Eine Backstage-Softwarevorlage für die Zertifikatsausstellung stellt dem Entwickler ein Formular zur Verfügung: Er wählt den Zertifikatstyp (aus einer Auswahlliste genehmigter Vorlagen) aus, gibt den Dienstnamen ein (der CN und DNS-SAN gemäß der Namensrichtlinie des Teams automatisch ausfüllt) und wählt die Bereitstellungsumgebung (die die ausstellende Zertifizierungsstelle und die Gültigkeitsdauer bestimmt). Durch das Absenden des Formulars wird eine Gerüstaktion ausgelöst, die die cert-manager-Zertifikatsressource (oder die Terraform-Variablendatei bzw. den Ansible-Playbook-Aufruf) über einen Pull Request im GitOps-Repository des Teams erstellt. Der Entwickler genehmigt den Pull Request; die GitOps-Pipeline stellt die Zertifikatsressource bereit; cert-manager stellt das Zertifikat von PKIaaS aus. Die Interaktion des Entwicklers mit PKI beschränkt sich auf das Ausfüllen eines zweiminütigen Formulars. Die Plattform setzt die Zertifikatsrichtlinie des Sicherheitsteams im Hintergrund durch.

Der Backstage-Servicekatalog kann auch Informationen zum Zertifikatsstatus der darin registrierten Dienste anzeigen. Ein mit der CLM-Ebene verbundenes Backstage-Plugin zeigt auf der Backstage-Entitätsseite jedes Dienstes dessen Zertifikatsbestand, aktuelle Ablaufdaten, Verlängerungsstatus und etwaige Richtlinienverstöße an. Entwickler erhalten Einblick in den Zertifikatsstatus ihrer Dienste direkt im Entwicklerportal, und das Sicherheitsteam erhält dieselben Informationen über das zentrale Dashboard der CLM-Plattform, ohne die Entwickler nach ihrem Zertifikatsstatus fragen zu müssen.

Gestaltung von Zertifikatvorlagen für Plattformteams

Die Gestaltung der Zertifikatsvorlage ist die wichtigste Sicherheitsentscheidung im Rahmen der PKIaaS-Integration des Plattformteams. Vorlagen legen fest, welche Zertifikate die Plattform ausstellt; Richtlinien bestimmen, welche nicht. Ein gut konzipierter Vorlagensatz für einen Enterprise-Identitätsanbieter (IDP) umfasst typischerweise die folgenden Kategorien:

Internes TLS-Zertifikat. Wird für HTTPS-Endpunkte interner Dienste verwendet, die von externen Clients nicht als vertrauenswürdig eingestuft werden müssen. Betreff-CN: service-name.namespace.svc.cluster.localSANs: DNS-SAN, das dem DNS-Namen des Kubernetes-Dienstes entspricht, optional die IP-Adresse des Pods als IP-SAN. Schlüssel: ECDSA P-256 oder RSA-2048. Gültigkeit: 90 Tage. EKU: TLS-Serverauthentifizierung. Automatische Verlängerung durch cert-manager.

mTLS-Clientzertifikat (Dienstidentität). Wird von Diensten verwendet, die ausgehende Aufrufe an andere Dienste mit gegenseitiger TLS-Authentifizierung durchführen. Subjekt-CN: Der Identitätsname des Dienstes. URI SAN: SPIFFE-ID, falls SPIFFE verwendet wird. Schlüssel: ECDSA P-256. Gültigkeit: 24 bis 48 Stunden (kurzfristig, angepasst an den Container-Lebenszyklus). EKU: TLS-Clientauthentifizierung. Automatische Erneuerung durch cert-manager oder SPIRE.

CI/CD-Pipeline-Jobzertifikat. Wird von Pipeline-Jobs zur Authentifizierung gegenüber Bereitstellungszielen und Signaturdiensten verwendet. Subjekt-CN: Repository- und Workflow-Kennung. URI-SAN: OIDC-Subjektanspruch des Pipeline-Jobs. Schlüssel: ECDSA P-256. Gültigkeit: 1 bis 4 Stunden. EKU: TLS-Client-Authentifizierung. Wird beim Start der Pipeline per OIDC-Token-Austausch ausgestellt und läuft beim Pipeline-Ende ab.

TLS-Zertifikat für den Internetzugang. Wird für Dienste verwendet, die von externen Clients als vertrauenswürdig eingestuft werden müssen. Subjekt-CN: der öffentliche Domänenname. SANs: alle zutreffenden öffentlichen Domänennamen. Schlüssel: ECDSA P-256 oder RSA-2048. Gültigkeit: gemäß CA/B Forum SC-081v3 (200 Tage bis zum 15. März 2026; 100 Tage bis zum 15. März 2027; 47 Tage ab dem 15. März 2029). EKU: TLS-Serverauthentifizierung. Automatische Erneuerung durch cert-manager. Diese Vorlage erfordert entweder eine öffentlich vertrauenswürdige ausstellende Zertifizierungsstelle (CA) oder eine Kreuzzertifizierung mit einer öffentlichen Stammzertifizierungsstelle, da Zertifikate privater CAs von öffentlichen Browsern nicht als vertrauenswürdig eingestuft werden.

Codesignaturzertifikat. Wird von Pipeline-Jobs zum Signieren von Container-Images, Binärdateien und Bereitstellungsmanifesten verwendet. Subjekt-CN: Die Pipeline- oder Team-Identität. Schlüssel: RSA-4096 oder ECDSA P-384 (höhere Sicherheit als Servicezertifikate). Gültigkeit: 1 bis 4 Stunden. EKU: Codesignierung (OID 1.3.6.1.5.7.3.3). Zugriff beschränkt auf autorisierte Signatur-Pipelines gemäß CertificateRequestPolicy.

Audit-Transparenz und Integration des Sicherheitsteams

Die Selbstbedienungs-Zertifikatsausstellung wirft die Frage nach der Nachvollziehbarkeit auf: Wenn jeder Entwickler über die Plattform ein Zertifikat anfordern kann, wie kann das Sicherheitsteam feststellen, welche Zertifikate ausgestellt wurden und ob die Ausstellung den Richtlinien entsprach? Die Antwort liegt in der CLM-Schicht, die mit der PKIaaS-CA verbunden ist.

Jedes Zertifikatsausstellungsereignis über die auf der Plattform bereitgestellten PKIaaS-Endpunkte wird im PKIaaS-Audit-Log mit der ausstellenden Zertifizierungsstelle (CA), dem Zertifikatssubjekt und den SANs, der anfragenden Identität (dem cert-manager-Dienstkonto, dem Pipeline-OIDC-Subjekt oder dem Terraform-Workspace) und dem Zeitstempel protokolliert. Die mit der PKIaaS-CA verbundene CLM-Plattform bietet dem Sicherheitsteam eine einheitliche Übersicht über alle Zertifikate aller Plattform-Tenants: welche Dienste über Zertifikate verfügen, wie deren Ablaufprofile aussehen, welche Zertifikate demnächst erneuert werden und welche Zertifikatsanfragen aufgrund von Richtlinien abgelehnt wurden.

Für das Sicherheitsteam ist dies deutlich besser als die Alternative (keine Transparenz der vom Entwickler ausgestellten Zertifikate, Abhängigkeit von Netzwerkscans, um die tatsächlich eingesetzte Infrastruktur zu ermitteln). Für das Plattformteam liefert es die Nachweisgrundlage für Compliance-Audits: Jedes Zertifikat in der Umgebung lässt sich auf eine authentifizierte Ausstellungsanfrage über die Plattform zurückführen und ist somit nicht mehr unbekannter Herkunft.

Die SIEM-Integration der CLM-Plattform speist Ereignisse des Zertifikatslebenszyklus (Ausstellung, Verlängerung, Ablaufwarnungen, Richtlinienverstöße, Widerruf) zusammen mit anderen Infrastrukturereignissen in die Sicherheitsüberwachung ein. Eine Ablaufwarnung für ein Dienstzertifikat erscheint im selben SIEM-Dashboard wie ein fehlgeschlagener Anmeldeversuch oder eine anomale Netzwerkverbindung. Dadurch erhält das Sicherheitsteam einen kontextbezogenen Überblick über das Zertifikatsrisiko, ohne dass eine separate Zertifikatsverwaltungskonsole erforderlich ist.

Multi-Cluster- und Multi-Umgebungs-Design

Enterprise-IDPs erstrecken sich typischerweise über mehrere Kubernetes-Cluster (Entwicklung, Staging, Produktion, regionsspezifische Cluster) und verschiedene Bereitstellungsumgebungen (öffentliche Cloud, On-Premises, Edge). Das Design der PKIaaS-CA-Hierarchie muss diese Topologie berücksichtigen.

Das empfohlene Design verwendet eine einzige PKIaaS-Root-CA mit umgebungsspezifischen ausstellenden CAs: eine Entwicklungs-CA für alle Entwicklungscluster, eine Staging-CA für alle Staging-Cluster und eine oder mehrere Produktions-CAs für Produktionscluster (gegebenenfalls regionsspezifische CAs aufgrund von Datenresidenzanforderungen). Jede ausstellende CA verfügt über ein eigenes, auf die jeweilige Umgebung abgestimmtes Zertifikatsprofil. Die Entwicklungsumgebungs-CA erlaubt längere Gültigkeitsdauern und weniger strenge Namenskonventionen, da ein Zertifikatsablauf in der Entwicklungsumgebung zu Problemen für die Entwickler führt. Die Produktionsumgebungs-CA hingegen erzwingt kürzere Gültigkeitsdauern und strenge Namenskonventionen, da ein Zertifikatsablauf in der Produktionsumgebung zu Problemen für die Benutzer führt.

Die Isolation der Umgebung durch die CA-Hierarchie bedeutet, dass ein von der Entwicklungs-CA ausgestelltes Zertifikat nicht zur Authentifizierung bei einem Produktionsdienst verwendet werden kann. Der Truststore des Produktionsdienstes enthält ausschließlich das Zertifikat der Produktions-CA (nicht das der Entwicklungs-CA), obwohl beide auf dieselbe Root-CA verweisen. Dies dient der technischen Begrenzung der Auswirkungen von Kompromittierungen der Entwicklungsumgebung: Ein kompromittierter Entwicklungscluster kann nicht zur Vortäuschung der Identität eines Produktionsdienstes missbraucht werden, selbst wenn der Angreifer ein Zertifikat der Entwicklungsumgebung erlangt.

47-tägige Gültigkeit des Zertifikats und Plattformentwicklung

Der im April 2025 verabschiedete CA/B Forum-Abstimmungsbeschluss SC-081v3 legt die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate wie folgt fest: 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Für Plattformteams, die eine große Anzahl von Kubernetes-basierten Zertifikaten verwalten, bedeutet dies eine Automatisierungspflicht: Zertifikate, die sich alle 47 Tage erneuern, können nicht manuell verwaltet werden. Die einzige praktikable Betriebsmethode ist die automatisierte Erneuerung über cert-manager oder einen vergleichbaren Controller.

Plattformteams, die die PKIaaS-gestützte cert-manager-Automatisierung in den Identitätsanbieter (IDP) integrieren, entwickeln die 47-Tage-Compliance-Lösung als Nebeneffekt der Behebung des unmittelbaren Problems der Entwickler-Selbstverwaltung. Jede im Kubernetes-Manifest eines Entwicklers deklarierte Zertifikatsressource wird automatisch von cert-manager verwaltet und vor Ablauf der Gültigkeitsdauer erneuert, unabhängig von der Gültigkeitsdauer. Für die Umstellung von 90-Tage- auf 47-Tage-Zertifikate ist lediglich eine Änderung der Gültigkeitsdauer des Zertifikatsprofils in der PKIaaS-CA- und CertificateRequestPolicy-Konfiguration erforderlich. Die Entwicklerschnittstelle (die Zertifikatsressourcendeklaration im Helm-Chart) bleibt unverändert. Die Compliance-Umstellung ist eine Konfigurationsänderung der Plattform und kein Migrationsprojekt für Entwickler.

Wie Verschlüsselungsberatung helfen kann

• PKI als Dienstleistung: Verschlüsselungsberatung PKIaaS-Angebot Bietet das verwaltete CA-Backend für die Ausstellung von IDP-Zertifikaten: ACME+EAB für die Konfiguration des cert-manager ClusterIssuers, REST-API für die Integration mit Terraform und Ansible, Unterstützung für den OIDC-Token-Austausch bei der Zertifikatsausstellung für CI/CD-Pipelines, Zertifikatsprofile für jede Workload-Kategorie (Service-TLS, mTLS-Clientidentität, Pipeline-Jobs, Codesignierung) und umgebungsspezifische ausstellende CAs für Multi-Cluster-IDP-Topologien. Kontaktieren Sie uns unter Verschlüsselungsberatung um Ihre IDP-Zertifikatsarchitektur zu besprechen.
• CertSecure Manager: Verschlüsselungsberatung CertSecure Manager Bietet die CLM-Transparenzschicht für das Plattform- und Sicherheitsteam: einheitliches Zertifikatsinventar über alle Cluster und Umgebungen hinweg, Zertifikatsressourcenerkennung mit cert-manager, Ablaufüberwachung mit konfigurierbaren Alarmierungsschwellenwerten, Berichte zur Richtlinienkonformität (Kennzeichnung von Zertifikaten, die gegen die festgelegten Vorlagenbeschränkungen der Plattform verstoßen) und SIEM-Integration für Ereignisfeeds zum Zertifikatslebenszyklus. Backstage-Plugins, die CertSecure Manager-Daten im Entwicklerportal anzeigen, ermöglichen die Überwachung des Zertifikatstatus pro Dienst, ohne das Entwicklerportal verlassen zu müssen.
• CodeSign Secure: Für Plattformteams, die Codesignierung als IDP-Funktion anbieten, bietet Encryption Consulting die entsprechende Lösung an. CodeSign Secure Bietet die HSM-gestützte Codesignierungsinfrastruktur, die CI/CD-Pipelines zum Signieren von Container-Images, Binärdateien und Deployment-Manifesten verwenden. Signaturschlüssel werden in FIPS 140-3 Level 3 HSMs gespeichert; jeder Signierungsvorgang wird im Audit-Trail protokolliert; Signaturrichtlinien schränken ein, welche Pipelines welche Artefakttypen signieren dürfen. Die Integration mit Kubernetes Admission-Controllern (Sigstore Policy Controller) ermöglicht die Signaturprüfung als Zulassungskriterium für alle Cluster-Deployments.
• PKI-Dienste: Für Plattformteams, die die PKIaaS-IDP-Integration von Grund auf neu konzipieren, bietet Encryption Consulting die passende Lösung. PKI-Dienste Bereitstellung eines CA-Hierarchie-Designs für Multi-Cluster- und Multi-Umgebungs-IDPs, eines Zertifikatvorlagen-Designs für jede Workload-Kategorie, einer cert-manager CertificateRequestPolicy-Konfiguration, eines OIDC-Token-Austausch-Setups für CI/CD-Pipelines, von Terraform- und Ansible-Integrationsmustern sowie einer Backstage-Plugin-Beratung zur Anzeige des Zertifikatsstatus im Entwicklerportal.
• PQC Beratungsleistungen: Plattformteams, die PKIaaS-gestützte Zertifikatsautomatisierung in den Identitätsanbieter (IDP) integrieren, legen damit auch den Grundstein für den Übergang zu Post-Quanten-Zertifikaten. (Encryption Consulting) PQC-Beratungsdienste Die Planung der hybriden Zertifikatsausstellung nach ML-DSA (FIPS 204) wird in das Design der IDP-Zertifikatvorlage integriert, sodass der PQC-Übergang eine Konfigurationsänderung an den PKIaaS-Profilen und cert-manager-Vorlagen darstellt und kein entwicklerorientiertes Migrationsprojekt ist.

Fazit

Die interne Entwicklerplattform ist der ideale Ort, um das Problem der Zertifikatsverwaltung für Entwickler-Workloads im Unternehmen zu lösen. Entwickler benötigen Zertifikate und sollten diese mit denselben Tools erhalten können, die sie für alle anderen Funktionen der Plattform verwenden. Sicherheitsteams benötigen Transparenz und die Möglichkeit zur Durchsetzung von Richtlinien; diese sollten sie automatisch über die CLM-Ebene der Plattform erhalten, nicht durch die manuelle Prüfung einzelner Anfragen. Plattformteams benötigen eine skalierbare und wartungsfreundliche Lösung; diese sollten sie über ein optimal integriertes PKIaaS-Backend und nicht über eine Sammlung von Skripten und gemeinsam genutzten Geheimnissen erhalten.

Die Integration ist unkompliziert. Der cert-manager ClusterIssuer verweist auf einen PKIaaS ACME-Endpunkt. Die CertificateRequestPolicy definiert die Sicherheitsvorkehrungen. Für Pipeline-Jobs wird ein OIDC-Token ausgetauscht. Terraform-Nutzer nutzen die Vault PKI Secrets Engine. Für Teams, die eine Benutzeroberfläche benötigen, steht eine Backstage-Vorlage zur Verfügung. Dies sind alles Standardmuster im Plattform-Engineering, und PKIaaS ist das verwaltete CA-Backend, das deren Funktion ermöglicht, ohne dass Sicherheitsschulden entstehen, die sich schneller anhäufen, als das Plattformteam sie abbauen kann.

Die 47-tägige Gültigkeitsdauer von Zertifikaten gemäß CA/B Forum macht diese Integration dringend erforderlich. Plattformteams, die die Zertifikatsausstellung und -erneuerung vor 2029 automatisieren, entwickeln eine Plattformfunktion, die den Übergang zur Einhaltung der Vorschriften ohne eine Entwicklermigration ermöglicht. Plattformteams, die abwarten, entwickeln einen manuellen Prozess, der bei einer Gültigkeitsdauer von 47 Tagen scheitern wird.

Wenn Ihr Plattformteam die PKIaaS-Integration für Ihren Identitätsanbieter entwirft und die Architektur validieren möchte, wenden Sie sich an Encryption Consulting.

Dieser Beitrag wird halbjährlich überprüft, und zwar immer dann, wenn cert-manager, Backstage, der Gültigkeitsplan des CA/B Forum SC-081v3 oder wichtige IDP-Plattformen Aktualisierungen veröffentlichen, die sich auf die Integrationsmuster der Zertifikatsautomatisierung auswirken.

Häufig gestellte Fragen

Welche Rolle spielt PKIaaS in einer internen Entwicklerplattform?

PKIaaS ist das verwaltete CA-Backend, das vom Plattformteam einmalig konfiguriert und über standardisierte IDP-Schnittstellen bereitgestellt wird: cert-manager ClusterIssuers für Kubernetes-Workloads, ACME-Endpunkte mit OIDC-Authentifizierung für CI/CD-Pipeline-Jobs, Terraform-Provider für IaC-Nutzer und Backstage-Vorlagen für UI-gesteuerte Anfragen. Entwickler können Zertifikate mithilfe vertrauter Tools selbstständig ausstellen; die Plattform setzt die Zertifikatsrichtlinie des Sicherheitsteams automatisch im Hintergrund durch.

Wie integriert cert-manager PKIaaS in einen Kubernetes-basierten IDP?

Das Plattformteam installiert cert-manager und konfiguriert einen ClusterIssuer, der auf den PKIaaS-ACME-Endpunkt mit externen Kontobindungs-Anmeldeinformationen verweist. Entwickler deklarieren Zertifikatsressourcen in ihren Kubernetes-Manifesten; cert-manager übernimmt die Ausstellung, speichert das Zertifikat als Kubernetes-Secret und erneuert es automatisch vor Ablauf. Die CertificateRequestPolicy von cert-manager setzt die Richtlinien des Zertifikatsprofils der Plattform durch und weist Anfragen, die außerhalb der zulässigen Parameter liegen, zurück, bevor die CSR die PKIaaS-CA erreicht.

Was sind Zertifikatsanforderungsvorlagen im Kontext von PKIaaS und IDPs?

Zertifikatsanforderungsvorlagen sind vorkonfigurierte, richtlinienkonforme Spezifikationen für jede Workload-Kategorie: zulässige SAN-Muster, Gültigkeitszeiträume, Schlüsselalgorithmen und EKU-OIDs. Entwickler wählen bei der Zertifikatsanforderung eine Vorlage aus; die Plattform setzt die Vorgaben der Vorlage durch, ohne dass der Entwickler die Details der Zertifikatsrichtlinien kennen muss. Vorlagen werden Zertifikatprofilen in der PKIaaS-CA und CertificateRequestPolicy-Ressourcen in cert-manager zugeordnet.

Wie sollte ein Plattformteam Zertifikatsanfragen für Nicht-Kubernetes-Workloads handhaben?

Für VMs und Bare-Metal-Server: ACME-Clients (certbot, acme.sh) verweisen auf den PKIaaS-ACME-Endpunkt. Für Terraform: HashiCorp Vault PKI Secrets Engine mit PKIaaS als Upstream-CA, genutzt über den Vault-Terraform-Provider. Für Ansible: Die PKIaaS-REST-API, aufgerufen von Ansible-Tasks, gekapselt in einer standardisierten Plattformrolle. Für Netzwerkgeräte: EST- oder SCEP-Endpunkte. Für CI/CD-Pipeline-Jobs: OIDC-Token-Austausch zur Ausstellung kurzlebiger Pipeline-Zertifikate ohne vorab geteilte Geheimnisse.

Welche Schutzmechanismen sollten Plattformteams in die Zertifikatsausstellung für die Entwickler-Selbstbedienung einbauen?

Fünf Leitplankenkategorien: Einschränkungen bei der Subjektbenennung (zulässige CN- und SAN-Muster pro Namespace/Team, durchgesetzt durch CertificateRequestPolicy), Gültigkeitsdauerbeschränkungen (maximale Gültigkeitsdauer pro Workload-Typ), Mindestanforderungen an den Schlüsselalgorithmus (minimale Schlüssellänge und Algorithmusanforderungen), Beschränkungen des Zertifikatstyps (jedes Team/Namespace kann nur für seinen Workload geeignete Typen anfordern, keine CA- oder Codesignaturzertifikate über die allgemeine Entwicklerschnittstelle) und Audit-Transparenz (alle Ausstellungsereignisse werden im PKIaaS-Audit-Log protokolliert und in der CLM-Plattform angezeigt).