PKIaaS voor interne ontwikkelaarsplatformen

Platform engineeringteams krijgen steeds dezelfde vraag, in verschillende vormen. Ontwikkelaars hebben TLS-certificaten nodig voor hun services. CI/CD-pipelines hebben referenties nodig die geen hardgecodeerde API-sleutels zijn. Kubernetes-workloads hebben mTLS-identiteiten nodig. Het beveiligingsteam wil dat dit alles gebeurt met consistent beleid, traceerbare uitgifte en zonder handmatige tussenkomst van het PKI-team bij elk verzoek. Het antwoord waar het platformteam meestal naar grijpt, is een serviceaccount, een gedeeld certificaat of een zelfondertekend certificaatscript dat in de repository is opgeslagen. Geen van deze oplossingen is de juiste.

Het juiste antwoord is PKIaaS als platformfunctionaliteit: het platformteam koppelt een beheerde certificeringsinstantie eenmalig aan de IDP, stelt deze beschikbaar via ACME, cert-manager en een API, en ontwikkelaars krijgen zelfservice voor certificaatuitgifte die automatisch het beleid van het beveiligingsteam afdwingt zonder dat de ontwikkelaar hoeft te weten wat een certificaatprofiel is. In dit artikel wordt uitgelegd hoe u die functionaliteit kunt bouwen.

Kort antwoord: Hoe ziet PKIaaS eruit als een IDP-functionaliteit?

PKIaaS wordt een IDP-functionaliteit wanneer het platformteam de PKIaaS CA-backend configureert, certificaatprofielen definieert voor elk type workload en deze profielen beschikbaar stelt via de standaardinterfaces van het platform: een cert-manager ClusterIssuer voor Kubernetes-workloads, een ACME-endpoint met OIDC-authenticatie voor CI/CD-pipelinejobs, een Terraform-providermodule voor infrastructure-as-code-gebruikers en een Backstage-servicecatalogussjabloon voor teams die de voorkeur geven aan een op de gebruikersinterface gebaseerde aanvraagstroom. Ontwikkelaars vragen certificaten aan via de interface die ze al gebruiken. De PKIaaS CA handhaaft het certificaatbeleid van het platformteam zonder dat ontwikkelaars hier iets voor hoeven te doen. De CLM-laag biedt het beveiligingsteam inzicht in het volledige certificaatportfolio van alle platformtenants.

Key Takeaways

• Platformteams zijn de rechtmatige beheerders van het certificaatuitgiftebeleid, niet applicatieontwikkelaars. Het platformteam stelt de randvoorwaarden eenmalig vast (geldige certificaatprofielen, naamgevingsbeperkingen, geldigheidsperiodebeperkingen, minimumvereisten voor sleutelalgoritmen). Ontwikkelaars kunnen binnen deze randvoorwaarden aanvragen zonder te weten dat deze randvoorwaarden bestaan. Dit is hetzelfde gestandaardiseerde model dat platformteams toepassen op containerbase-images, Terraform-modules en observability-configuraties.
• Cert-manager is de Kubernetes-interface tussen de workloads van ontwikkelaars en de PKIaaS CA. Het platformteam implementeert cert-manager en configureert een ClusterIssuer die is gekoppeld aan het PKIaaS ACME-eindpunt. Ontwikkelaars declareren certificaatbronnen in hun Kubernetes-manifesten; cert-manager verzorgt de uitgifte, opslag als Kubernetes Secrets en automatische verlenging. Na de eerste declaratie is geen verdere interactie van de ontwikkelaar vereist.
• Dankzij de OIDC-tokenuitwisseling zijn CI/CD-pipelinecertificaten mogelijk zonder vooraf gedeelde geheimen. Moderne CI/CD-platformen (GitHub Actions, GitLab CI, CircleCI) geven OIDC-tokens uit aan pipelinejobs die via het ACME External Account Binding-mechanisme kunnen worden ingewisseld voor kortstondige PKIaaS-certificaten. Het certificaat van de pipelinejob is alleen geldig gedurende de looptijd van de job en verloopt automatisch. Er is geen rotatie van geheimen nodig.
• Sjabloonen voor certificaataanvragen nemen de noodzaak voor expertise weg bij certificaataanvragen vanuit de ontwikkelaarskant. Sjabloonen definiëren de geldige onderwerpnaamgevingspatronen, SAN-typen, geldigheidsperioden en sleutelgebruik voor elke certificaatcategorie. Ontwikkelaars selecteren een sjabloon; het platform handhaaft de sjabloonbeperkingen. Ontwikkelaars hoeven nooit te weten wat een Extended Key Usage OID is of wat de Baseline Requirements van het CA/B Forum zeggen over SAN-opmaak.
• De CA/B Forum SC-081v3-richtlijn met een maximale geldigheidsduur van 47 dagen (van kracht vanaf 15 maart 2029) maakt automatische verlenging verplicht voor alle openbare TLS-certificaten. Platformteams die PKIaaS-ondersteunde automatische verlenging in hun IDP integreren, bouwen nu de compliance-oplossing vóór de deadline, in plaats van zich te haasten om automatisering achteraf toe te passen op een handmatig beheerd certificaatsysteem.

Het platformengineeringprobleem met certificaten

Platformteams staan ​​voor een specifieke variant van het certificaatbeheerprobleem, die verschilt van het bedrijfsbrede certificaatbeheerprobleem waarmee beveiligingsteams te maken hebben. Beveiligingsteams maken zich zorgen over het volledige certificaatportfolio: ontdekking, inventarisatie, naleving van beleid en bewaking van de vervaldatum van alle certificaten uit alle bronnen. Platformteams maken zich zorgen over een smaller, maar operationeel meer urgent probleem: hoe verkrijgen ontwikkelaars certificaten voor hun workloads zonder een wachtrij te creëren in de inbox van het PKI-team, zonder geheimen naar repositories te schrijven en zonder een certificaatportfolio te produceren dat op grote schaal onbeheerbaar is?

De patronen waar platformteams naar grijpen wanneer PKIaaS niet beschikbaar is, hebben allemaal dezelfde zwakke plek: ze optimaliseren voor ontwikkelaarsgemak ten koste van beveiliging en operationeel beheer. Wildcardcertificaten die over verschillende services worden gedeeld, elimineren het certificaatbeheer per service, maar elimineren ook de isolatie per service: een gecompromitteerde service kan de wildcard gebruiken om zich voor te doen als een andere service. Zelfondertekende certificaten elimineren het knelpunt van het PKI-team, maar elimineren ook de vertrouwensketen die mTLS zo belangrijk maakt. Langdurige serviceaccountreferenties bieden een werkbare tijdelijke oplossing, maar leiden tot technische schuld: ze vereisen rotatiegebeurtenissen die moeilijk te coördineren zijn binnen een grote ontwikkelaarsorganisatie.

PKIaaS als IDP-functionaliteit elimineert deze compromissen. Het gebruiksgemak voor ontwikkelaars wordt geboden door de selfservice-interface (een certificaatresource in cert-manager, een Terraform-moduleaanroep, een Backstage-sjabloon). De certificaatbeveiliging wordt verzorgd door de PKIaaS CA (FIPS 140-3 Level 3 HSM-ondersteunde sleutels, beleidsgestuurde uitgifte, automatische vervaldatum). Het operationele beheer wordt verzorgd door de CLM-laag (uniforme inventaris, automatische verlenging, monitoring van beleidsnaleving). Het platformteam configureert de integratie eenmalig; ontwikkelaars kunnen deze vervolgens permanent gebruiken.

Kubernetes-integratie: cert-manager als IDP-interface

Voor platformteams die Kubernetes-gebaseerde IDP's gebruiken, is cert-manager de standaardinterface tussen de workloads van ontwikkelaars en de PKIaaS CA. De integratiearchitectuur bestaat uit drie lagen die het platformteam eenmalig configureert.

ClusterIssuer-configuratie

Het platformteam installeert cert-manager in elk cluster en maakt een ClusterIssuer aan (of meerdere namespace-scoped Issuers voor multi-tenant clusters met verschillende certificaatbeleidsregels per tenant) die verwijst naar het PKIaaS ACME-eindpunt. De ClusterIssuer-configuratie specificeert de ACME-server-URL, de External Account Binding (EAB)-sleutel-ID en het HMAC-geheim dat is uitgegeven door de PKIaaS CA voor dit cluster, en de DNS- of HTTP-challengeconfiguratie voor domeinvalidatie. Voor interne services die gebruikmaken van private DNS (wat typisch is voor een Kubernetes-omgeving binnen een bedrijf), is een DNS-01-challenge tegen de interne DNS-provider van de organisatie het juiste type challenge.

Zodra de ClusterIssuer is geconfigureerd en gevalideerd, kan elke Certificate-resource in elke namespace ernaar verwijzen als de uitgever. Het platformteam bepaalt welke namespaces welke uitgevers mogen gebruiken via het CertificateRequestPolicy van cert-manager (de component voor het goedkeuren van beleid in cert-manager) in combinatie met Kubernetes RBAC. Een applicatienamespace kan bijvoorbeeld beperkt zijn tot het aanvragen van certificaten met SAN's die overeenkomen met het toegewezen domeinpatroon van de namespace; een systeemnamespace kan toegang hebben tot een andere uitgever die infrastructuurspecifieke certificaattypen toestaat.

Certificaatbronnen gericht op ontwikkelaars

Vanuit het perspectief van de ontwikkelaar ziet het aanvragen van een certificaat in de Kubernetes IDP er als volgt uit: declareer een Certificate-resource in de Helm-grafiek of Kustomize-overlay van de service, waarbij het gewenste onderwerp en de SAN's worden gespecificeerd, verwijs naar de door het platform geleverde ClusterIssuer en implementeer. cert-manager maakt een CertificateRequest aan, dient de CSR in bij het PKIaaS ACME-eindpunt, voltooit de domeinvalidatie-uitdaging, haalt het ondertekende certificaat op en slaat het op als een Kubernetes Secret. De applicatie verwijst naar de Secret in de Pod-specificatie als een volume-mount of omgevingsvariabele. Het certificaat verschijnt binnen enkele seconden in de draaiende Pod nadat de Certificate-resource is toegepast.

Wanneer het certificaat de verlengingsdrempel nadert (standaard vernieuwt cert-manager wanneer tweederde van de geldigheidsperiode is verstreken), vraagt ​​cert-manager automatisch een verlenging aan bij het PKIaaS ACME-eindpunt. Het vernieuwde certificaat vervangt het verlopen certificaat in de Kubernetes Secret. Applicaties die de Secret als volume mounten, nemen het nieuwe certificaat mee bij de volgende bestandssysteemsynchronisatie zonder dat de pod opnieuw hoeft te worden opgestart. Applicaties die de certificaatwaarde bij het opstarten cachen, vereisen een rolling restart, die cert-manager automatisch kan activeren indien geconfigureerd. De ontwikkelaar hoeft de vervaldatums van certificaten niet bij te houden of eraan te denken om verlengingen te initiëren.

Beleidsrichtlijnen via CertificateRequestPolicy

De beleidsgoedkeurder van cert-manager voegt de handhavingslaag toe die de door ACME ondersteunde cert-manager transformeert van een handige certificaattool naar een beheerde platformfunctionaliteit. CertificateRequestPolicy-resources definiëren welke certificaatverzoeken zijn toegestaan ​​voor elke namespace of aanvrager. Een beleid kan bijvoorbeeld het volgende toestaan: SAN's die overeenkomen met het patroon *.namespace-name.svc.cluster.localDe minimale sleutelgrootte is RSA-2048 of ECDSA-256, de certificaatvaliditeit is maximaal 90 dagen en het uitgebreide sleutelgebruik is alleen toegestaan ​​voor TLS-serverauthenticatie en TLS-clientauthenticatie. Elk certificaatverzoek dat niet overeenkomt met een goedgekeurd beleid wordt geweigerd voordat het CSR de PKIaaS CA bereikt. De weigering wordt vastgelegd, is zichtbaar voor het platformteam in het auditlogboek van cert-manager en verschijnt in de CLM-inventaris als een beleidsschending.

Dit geeft het platformteam de nodige beveiliging om selfservice veilig te maken: ontwikkelaars kunnen elk certificaat aanvragen dat binnen het beleid valt, zonder goedkeuringswachtrij of handmatige controle. Aanvragen die buiten het beleid vallen, worden automatisch geweigerd met een foutmelding die de ontwikkelaar vertelt welke beleidsbeperking is overtreden en wat de juiste aanpak is. Het beveiligingsteam definieert het beleid; het platform handhaaft het automatisch; ontwikkelaars werken er probleemloos mee.

CI/CD-pipelinecertificaatuitgifte

CI/CD-pipelinejobs hebben om een ​​andere reden authenticatiegegevens nodig dan services: ze moeten zich tijdens het bouwproces kunnen aanmelden bij implementatiedoelen, containerregisters, artifactopslag en de PKIaaS-codeondertekeningsservice. De certificaatgegevens voor een CI/CD-job mogen alleen geldig zijn gedurende de uitvoeringsduur van die specifieke job, niet voor onbepaalde tijd.

OIDC-tokenruil voor pijplijncertificaten

Moderne CI/CD-platformen geven OIDC-tokens uit aan pipeline-jobs die de identiteit van de job coderen: de repository, de branch, de workflownaam en de omgeving. Deze tokens zijn kortstondig geldig en worden ondertekend door de OIDC-provider van het CI/CD-platform. Het platformteam configureert het PKIaaS ACME-eindpunt om deze OIDC-tokens te accepteren als External Account Binding-referenties via een tokenuitwisselingsproces: de pipeline-job presenteert zijn OIDC-token aan een geconfigureerd uitwisselingseindpunt, dat het token valideert aan de hand van het JWKS-eindpunt van het CI/CD-platform en een EAB-referentie uitgeeft. De pipeline-job gebruikt deze EAB-referentie om een ​​certificaat aan te vragen bij het PKIaaS ACME-eindpunt.

Het resulterende certificaat is geldig voor het geconfigureerde certificaatprofiel van de pipeline (doorgaans 1 tot 4 uur, wat de maximaal verwachte looptijd van de pipeline dekt). Het certificaat codeert de identiteit van de pipeline in het onderwerp (de repository en workflow in het CN- of SAN-URI-veld). Wanneer de pipeline-taak dit certificaat gebruikt om zich te authenticeren bij implementatiedoelen of ondertekeningsservices, kunnen die systemen de identiteit van de pipeline verifiëren aan de hand van het certificaat en autorisatiebeslissingen nemen op basis van welke repository en workflow actief zijn. Het certificaat verloopt automatisch wanneer de taak eindigt. Er is geen rotatie van geheimen vereist: er zijn geen langdurige referenties die geroteerd hoeven te worden, omdat er geen langdurige referenties worden uitgegeven.

Codeondertekeningscertificaten voor pipeline-artefacten

Dezelfde PKIaaS CA die servicecertificaten en pipeline-identiteitscertificaten uitgeeft, kan ook codeondertekeningscertificaten uitgeven voor het ondertekenen van containerimages, binaire bestanden, pakketten en implementatiemanifesten die door de CI/CD-pipeline worden geproduceerd. Het platformteam configureert een apart codeondertekeningscertificaatprofiel in de PKIaaS CA (met de Code Signing Extended Key Usage OID 1.3.6.1.5.7.3.3) en stelt dit beschikbaar via de PKIaaS REST API of een speciale ondertekeningsservice. Pipeline-taken die artefacten produceren, vragen via dit profiel een ondertekeningscertificaat aan, ondertekenen hun artefacten en het certificaat verloopt wanneer de taak is voltooid. Kubernetes admission controllers (Sigstore's Policy Controller, OPA/Gatekeeper met beleid voor beeldverificatie) kunnen de handtekeningen van containerimages verifiëren aan de hand van de PKIaaS CA trust root voordat implementatie wordt toegestaan, zodat alleen images die zijn ondertekend door geautoriseerde pipeline-taken tot het cluster worden toegelaten.

Integratie van infrastructuur als code

Niet alle workloads in een enterprise IDP draaien in Kubernetes. Virtuele machines, bare metal-services, serverloze functies en netwerkapparaten hebben allemaal certificaten nodig, en de platformteams beheren de infrastructuur vaak via Terraform, Pulumi of Ansible in plaats van Kubernetes-manifesten. PKIaaS biedt een REST API die direct door infrastructure-as-code-tools kan worden gebruikt.

Voor op Terraform gebaseerde IDP's kan de HashiCorp Vault PKI secrets engine worden geconfigureerd om PKIaaS als upstream CA te gebruiken. Hierdoor wordt een Vault PKI-mount beschikbaar gesteld die Terraform-resources via de Vault Terraform-provider gebruiken. Het platformteam beheert de Vault-configuratie en de PKIaaS CA-integratie; Terraform-modules die door applicatieteams worden geschreven, gebruiken de Vault PKI-mount zonder de onderliggende PKIaaS CA te kennen. Certificaatuitgifte vindt plaats als onderdeel van de Terraform apply: de resourcedefinitie specificeert de gewenste certificaatparameters, Vault geeft het certificaat uit vanaf de door PKIaaS ondersteunde PKI-mount en het certificaat wordt opgeslagen in de secret store van Vault. De Terraform-status verwijst naar het geheime pad van Vault; de daadwerkelijke privésleutel van het certificaat wordt nooit naar de Terraform-status of een versiebeheersysteem geschreven.

Voor provisioning via Ansible kan de PKIaaS REST API rechtstreeks vanuit Ansible-taken worden aangeroepen met behulp van de uri module, of via door de community ontwikkelde Ansible-modules voor ACME-certificaatbeheer. Het platformteam levert een gestandaardiseerde Ansible-rol die de PKIaaS-API voor certificaatuitgifte omvat en de sleutelgeneratie, CSR-constructie, indiening en certificaatopslag in een standaardpad op de geconfigureerde host afhandelt. Applicatieteams nemen de rol op in hun playbooks met parameters die het gewenste certificaattype specificeren (dat overeenkomt met een PKIaaS-certificaatprofiel); de rol regelt de rest.

Integratie van Backstage en Servicecatalogus

Veel volwaardige platformteams gebruiken een ontwikkelaarsportaal (Backstage is de meest gebruikte open-source optie) als front-end interface naar de IDP. Voor ontwikkelteams die de voorkeur geven aan een UI-gestuurde aanvraagstroom boven het schrijven van Kubernetes-manifesten of Terraform-code, kan de PKIaaS-certificaatuitgiftefunctionaliteit in de servicecatalogus worden weergegeven als een softwaretemplate.

Een Backstage-softwaretemplate voor certificaatuitgifte toont de ontwikkelaar een formulier: selecteer het certificaattype (uit een dropdownmenu met goedgekeurde templates), voer de servicenaam in (waarmee de CN en DNS SAN worden ingevuld op basis van het naamgevingsbeleid van het team), selecteer de implementatieomgeving (die de uitgevende CA en de geldigheidsperiode bepaalt). Het indienen van het formulier activeert een scaffolding-actie die de cert-manager Certificate-resource (of het Terraform-variabelenbestand, of de Ansible-playbookaanroep) in de GitOps-repository van het team aanmaakt via een pull request. De ontwikkelaar keurt de pull request goed; de GitOps-pipeline implementeert de Certificate-resource; cert-manager geeft het certificaat uit via PKIaaS. De interactie van de ontwikkelaar met PKI komt neer op het invullen van een formulier van twee minuten. Het platform handhaaft het certificaatbeleid van het beveiligingsteam op de achtergrond.

De Backstage-servicecatalogus kan ook informatie over de certificaatstatus weergeven voor services die in de catalogus zijn geregistreerd. Een Backstage-plug-in die is gekoppeld aan de CLM-laag kan de certificaatinventaris van elke service, de huidige vervaldatums, de verlengingsstatus en eventuele beleidsschendingen weergeven op de Backstage-entiteitspagina van de service. Ontwikkelaars krijgen inzicht in de certificaatstatus van hun service zonder de ontwikkelaarsportal te verlaten, en het beveiligingsteam krijgt hetzelfde inzicht via het gecentraliseerde dashboard van het CLM-platform zonder ontwikkelaars te hoeven bevragen over hun certificaatstatus.

Het ontwerpen van certificaatsjablonen voor platformteams

Het ontwerp van de certificaatsjablonen is de meest cruciale beveiligingsbeslissing bij de PKIaaS-integratie van het platformteam. Sjablonen bepalen welke certificaten het platform uitgeeft; beleid bepaalt welke certificaten het niet uitgeeft. Een goed ontworpen set sjablonen voor een enterprise IDP omvat doorgaans de volgende categorieën:

Intern TLS-certificaat voor de service. Gebruikt voor HTTPS-eindpunten op interne services die niet door externe clients hoeven te worden vertrouwd. Onderwerp CN: service-name.namespace.svc.cluster.localSAN's: DNS SAN die overeenkomt met de DNS-naam van de Kubernetes-service en optioneel het IP-adres van de pod als IP SAN. Sleutel: ECDSA P-256 of RSA-2048. Geldigheid: 90 dagen. EKU: TLS-serverauthenticatie. Automatische verlenging wordt afgehandeld door cert-manager.

mTLS-clientcertificaat (service-identiteit). Gebruikt door services die uitgaande aanroepen doen naar andere services waarvoor wederzijdse TLS-authenticatie vereist is. Onderwerp CN: de identiteitsnaam van de service. URI SAN: SPIFFE-ID indien SPIFFE in gebruik is. Sleutel: ECDSA P-256. Geldigheid: 24 tot 48 uur (kortstondig, afgestemd op de levenscyclus van de container). EKU: TLS-clientauthenticatie. Wordt automatisch vernieuwd door cert-manager of SPIRE.

Certificaat voor CI/CD-pipelinejobs. Wordt gebruikt door pipelinejobs om zich te authenticeren bij implementatiedoelen en ondertekeningsservices. Onderwerp CN: de repository- en workflow-identificatie. URI SAN: de OIDC-onderwerpclaim van de pipelinejob. Sleutel: ECDSA P-256. Geldigheid: 1 tot 4 uur. EKU: TLS-clientauthenticatie. Uitgegeven via OIDC-tokenuitwisseling bij de start van de pipeline, verloopt bij het einde van de pipeline.

Internetgericht TLS-certificaat. Gebruikt voor services die door externe clients vertrouwd moeten worden. Onderwerp CN: de publieke domeinnaam. SAN's: alle toepasselijke publieke domeinnamen. Sleutel: ECDSA P-256 of RSA-2048. Geldigheid: afgestemd op het CA/B Forum SC-081v3-schema (200 dagen tot 15 maart 2026; 100 dagen tot 15 maart 2027; 47 dagen vanaf 15 maart 2029). EKU: TLS-serverauthenticatie. Wordt automatisch verlengd door cert-manager. Deze sjabloon vereist een publiekelijk vertrouwde uitgevende CA of kruiscertificering met een publieke CA-root, aangezien privé-CA-certificaten niet worden vertrouwd door publieke browsers.

Codeondertekeningscertificaat. Gebruikt door pipeline-taken om containerimages, binaire bestanden en implementatiemanifesten te ondertekenen. Onderwerp CN: de pipeline- of teamidentiteit. Sleutel: RSA-4096 of ECDSA P-384 (hogere betrouwbaarheid dan servicecertificaten). Geldigheid: 1 tot 4 uur. EKU: Codeondertekening (OID 1.3.6.1.5.7.3.3). Toegang beperkt tot geautoriseerde ondertekeningspipelines door CertificateRequestPolicy.

Integratie van auditzichtbaarheid en beveiligingsteams

Het zelfservice-certificaatuitgifteproces roept de vraag op: als elke ontwikkelaar via het platform een ​​certificaat kan aanvragen, hoe weet het beveiligingsteam dan wat er is uitgegeven en of de uitgifte conform het beleid was? Het antwoord is de CLM-laag die is gekoppeld aan de PKIaaS-CA.

Elke gebeurtenis waarbij een certificaat wordt uitgegeven via de PKIaaS-eindpunten die beschikbaar zijn op het platform, wordt vastgelegd in het PKIaaS-auditlogboek met de uitgevende CA, het certificaatonderwerp en de SAN's, de aanvragende identiteit (het cert-manager-serviceaccount, het pipeline OIDC-onderwerp of de Terraform-werkruimte) en het tijdstempel. Het CLM-platform dat is gekoppeld aan de PKIaaS CA biedt het beveiligingsteam een ​​uniform overzicht van alle certificaten in alle platformtenants: welke services certificaten hebben, hoe hun vervalprofielen eruitzien, welke certificaten bijna verlopen en welke certificaataanvragen door beleid zijn geweigerd.

Voor het beveiligingsteam is dit aanzienlijk beter dan het alternatief (geen inzicht in door ontwikkelaars uitgegeven certificaten, afhankelijk van netwerkscans om te achterhalen wat er daadwerkelijk is geïmplementeerd). Voor het platformteam biedt het de bewijsbasis voor compliance-audits: elk certificaat in de omgeving kan worden herleid tot een geauthenticeerd uitgifteverzoek via het platform, in plaats van dat de herkomst onbekend is.

De SIEM-integratie vanuit het CLM-platform zorgt ervoor dat gebeurtenissen in de levenscyclus van certificaten (uitgifte, verlenging, waarschuwingen voor verlopen certificaten, beleidsschendingen, intrekking) samen met andere infrastructuurgebeurtenissen in de beveiligingsmonitoring worden opgenomen. Een waarschuwing voor het verlopen van een servicecertificaat verschijnt in hetzelfde SIEM-dashboard als een mislukte inlogpoging of een afwijkende netwerkverbinding, waardoor het beveiligingsteam contextueel inzicht krijgt in certificaatrisico's zonder dat een aparte certificaatbeheerconsole nodig is.

Ontwerp voor meerdere clusters en meerdere omgevingen

Enterprise IDP's omvatten doorgaans meerdere Kubernetes-clusters (ontwikkeling, staging, productie, regiospecifieke clusters) en meerdere implementatieomgevingen (publieke cloud, on-premises, edge). Het ontwerp van de PKIaaS CA-hiërarchie moet rekening houden met deze topologie.

Het aanbevolen ontwerp maakt gebruik van één PKIaaS-root-CA met omgevingsspecifieke uitgevende CA's: een ontwikkelings-CA voor alle ontwikkelclusters, een staging-CA voor alle stagingclusters en een of meer productie-CA's voor productieclusters (mogelijk regiospecifieke uitgevende CA's voor dataresidentievereisten). Elke uitgevende CA heeft een eigen certificaatprofiel dat geschikt is voor die omgeving. De CA voor de ontwikkelomgeving kan langere geldigheidsperioden en minder strenge naamgevingsbeperkingen toestaan, omdat het verlopen van certificaten in de ontwikkelomgeving wrijving veroorzaakt bij ontwikkelaars. De CA voor de productieomgeving hanteert kortere geldigheidsperioden en strikte naamgevingsbeperkingen, omdat het verlopen van certificaten in de productieomgeving incidenten veroorzaakt die gebruikers ondervinden.

Omgevingsisolatie via de CA-hiërarchie betekent dat een certificaat uitgegeven door de CA die de ontwikkelomgeving beheert, geen authenticatie kan uitvoeren bij een productieservice. De vertrouwensopslag van de productieservice bevat alleen het certificaat van de productie-CA (niet dat van de ontwikkelomgeving), ook al verwijzen beide naar dezelfde root. Dit is een technische beveiliging om de impact van een inbreuk op de ontwikkelomgeving te beperken: een gecompromitteerd ontwikkelcluster kan niet worden gebruikt om zich voor te doen als een productieservice, zelfs niet als de aanvaller een certificaat van de ontwikkelomgeving bemachtigt.

Certificaat geldigheidsduur van 47 dagen en platformengineering

CA/B Forum Ballot SC-081v3, goedgekeurd in april 2025, stelt het volgende schema vast voor de maximale geldigheidsduur van TLS-certificaten voor publiekelijk vertrouwde certificaten: 200 dagen vanaf 15 maart 2026; 100 dagen vanaf 15 maart 2027; 47 dagen vanaf 15 maart 2029. Voor platformteams die een grote, op Kubernetes gebaseerde certificatenportefeuille beheren, betekent dit dat automatisering noodzakelijk is: certificaten die elke 47 dagen moeten worden vernieuwd, kunnen niet handmatig worden beheerd. Het enige haalbare operationele model is geautomatiseerde vernieuwing via cert-manager of een vergelijkbare controller.

Platformteams die PKIaaS-ondersteunde cert-manager-automatisering in de IDP integreren, bouwen nu de 47-dagen compliance-oplossing als neveneffect van het oplossen van het directe selfservice-probleem voor ontwikkelaars. Elke certificaatbron die in het Kubernetes-manifest van een ontwikkelaar is gedeclareerd, wordt automatisch beheerd door cert-manager, die het certificaat vernieuwt vóór de vervaldatum, ongeacht de geldigheidsperiode. Een overgang van 90-dagen naar 47-dagen certificaten vereist alleen een wijziging van de geldigheidsperiode van het certificaatprofiel in de PKIaaS CA- en CertificateRequestPolicy-configuratie. De ontwikkelaarsinterface (de declaratie van de certificaatbron in de Helm-grafiek) verandert niet. De compliance-overgang is een wijziging in de platformconfiguratie, geen migratieproject voor ontwikkelaars.

Hoe encryptieconsultancy kan helpen

• PKI als een service: Encryptie Consulting's PKIaaS-aanbod Biedt de beheerde CA-backend voor IDP-certificaatuitgifte: ACME+EAB voor cert-manager ClusterIssuer-configuratie, REST API voor Terraform- en Ansible-integratie, ondersteuning voor OIDC-tokenuitwisseling voor CI/CD-pipelinecertificaatuitgifte, certificaatprofielen voor elke workloadcategorie (service-TLS, mTLS-clientidentiteit, pipelinejobs, codeondertekening) en omgevingsspecifieke uitgevende CA's voor multi-cluster IDP-topologieën. Neem contact met ons op via Encryptie Consulting om uw IDP-certificaatarchitectuur te bespreken.
• CertSecure Manager: Encryptie Consulting's CertSecure Manager Biedt de CLM-zichtbaarheidslaag voor het platformteam en het beveiligingsteam: een uniforme certificaatinventaris voor alle clusters en omgevingen, certificaatresource-ontdekking via cert-manager, vervalbewaking met configureerbare waarschuwingsdrempels, rapportage over naleving van beleid (waarbij certificaten die de door het platform gestelde sjabloonbeperkingen schenden, worden gemarkeerd) en SIEM-integratie voor gebeurtenisfeeds met betrekking tot de certificaatlevenscyclus. Backstage-plug-ins die CertSecure Manager-gegevens in de ontwikkelaarsportal weergeven, maken inzicht in de certificaatstatus per service mogelijk zonder de ontwikkelaarsportal te verlaten.
• CodeSign Secure: Voor platformteams die codeondertekening als een IDP-functionaliteit aanbieden, biedt Encryption Consulting de volgende oplossingen. CodeSign Secure Biedt de door HSM ondersteunde infrastructuur voor codeondertekening die CI/CD-pipelines gebruiken om containerimages, binaire bestanden en implementatiemanifesten te ondertekenen. Ondertekeningssleutels worden opgeslagen in FIPS 140-3 Level 3 HSM's; elke ondertekeningsgebeurtenis wordt vastgelegd in het auditlogboek; ondertekeningsbeleid beperkt welke pipelines welke artefacttypen mogen ondertekenen. Integratie met Kubernetes admission controllers (Sigstore Policy Controller) maakt verificatie van handtekeningen mogelijk als toegangspoort voor alle clusterimplementaties.
• PKI-diensten: Voor platformteams die de PKIaaS IDP-integratie helemaal vanaf nul ontwerpen, biedt Encryption Consulting uitkomst. PKI-diensten Het programma biedt ontwerp voor de CA-hiërarchie voor IDP's met meerdere clusters en omgevingen, ontwerp voor certificaatsjablonen voor elke workloadcategorie, configuratie van het CertificateRequestPolicy in cert-manager, configuratie van de OIDC-tokenuitwisseling voor CI/CD-pipelines, integratiepatronen voor Terraform en Ansible, en advies over de Backstage-plug-in voor het weergeven van de certificaatstatus in de ontwikkelaarsportal.
• PQC-adviesdiensten: Platformteams die PKIaaS-ondersteunde certificaatautomatisering in de IDP integreren, leggen nu ook de basis voor de post-quantum certificaattransitie. Encryption Consulting's PQC Adviesdiensten Integreer de planning voor de uitgifte van hybride ML-DSA (FIPS 204)-certificaten in het ontwerp van de IDP-certificaatsjabloon, zodat de PQC-overgang een configuratiewijziging is in de PKIaaS-profielen en cert-manager-sjablonen in plaats van een migratieproject voor ontwikkelaars.

Conclusie

Het interne ontwikkelaarsplatform is de juiste plek om het probleem van certificaatbeheer voor ontwikkelaarsworkloads op te lossen. Ontwikkelaars hebben certificaten nodig; ze moeten deze kunnen verkrijgen via dezelfde tools die ze voor al het andere op het platform gebruiken. Beveiligingsteams hebben inzicht en beleidshandhaving nodig; ze moeten dit automatisch krijgen via de CLM-laag van het platform, en niet via handmatige beoordeling van individuele aanvragen. Platformteams hebben een schaalbare en onderhoudbare oplossing nodig; ze moeten deze krijgen via een goed geïntegreerde PKIaaS-backend in plaats van via een verzameling scripts en gedeelde geheimen.

De integratie is niet complex. Een cert-manager ClusterIssuer die verwijst naar een PKIaaS ACME-eindpunt. Een CertificateRequestPolicy die de beveiligingsregels definieert. OIDC-tokenuitwisseling voor pipeline-taken. Een Vault PKI-geheimenengine voor Terraform-gebruikers. Een Backstage-sjabloon voor teams die een gebruikersinterface willen. Dit zijn allemaal standaard platformontwikkelingspatronen, en PKIaaS is de beheerde CA-backend die ervoor zorgt dat ze werken zonder een beveiligingsschuld te creëren die sneller oploopt dan het platformteam deze kan aflossen.

De 47-daagse geldigheidsduur van certificaten van het CA/B Forum maakt deze integratie urgent. Platformteams die de uitgifte en verlenging van certificaten vóór 2029 automatiseren, bouwen een platformfunctionaliteit die de overgang naar de nieuwe regelgeving zonder tussenkomst van ontwikkelaars mogelijk maakt. Platformteams die wachten, bouwen een handmatig proces dat bij een geldigheidsduur van 47 dagen niet zal werken.

Als uw platformteam PKIaaS-integratie voor uw IDP ontwerpt en de architectuur wil valideren, neem dan contact op met Encryption Consulting.

Dit bericht wordt elke zes maanden herzien, en wel wanneer cert-manager, Backstage, het CA/B Forum SC-081v3-validiteitsschema of belangrijke IDP-platformen updates publiceren die van invloed zijn op de integratiepatronen voor certificaatautomatisering.

Veelgestelde Vragen / FAQ

Wat is de rol van PKIaaS in een intern ontwikkelaarsplatform?

PKIaaS is de beheerde CA-backend die het platformteam eenmalig configureert en beschikbaar stelt via standaard IDP-interfaces: cert-manager ClusterIssuers voor Kubernetes-workloads, ACME-endpoints met OIDC-authenticatie voor CI/CD-pipelinejobs, Terraform-providers voor IaC-gebruikers en Backstage-templates voor UI-gestuurde verzoeken. Ontwikkelaars kunnen zelf certificaten aanvragen via vertrouwde tools; het platform handhaaft het certificaatbeleid van het beveiligingsteam automatisch op de achtergrond.

Hoe integreert cert-manager PKIaaS in een op Kubernetes gebaseerde IDP?

Het platformteam installeert cert-manager en configureert een ClusterIssuer die verwijst naar het PKIaaS ACME-eindpunt met externe accountbinding-referenties. Ontwikkelaars declareren certificaatbronnen in hun Kubernetes-manifesten; cert-manager verzorgt de uitgifte, slaat het certificaat op als een Kubernetes Secret en vernieuwt het automatisch vóór de vervaldatum. Het CertificateRequestPolicy van cert-manager handhaaft de beveiligingsregels van het certificaatprofiel van het platform en weigert verzoeken die buiten de goedgekeurde parameters vallen voordat de CSR de PKIaaS CA bereikt.

Wat zijn certificaataanvraagsjablonen in de context van PKIaaS en IDP's?

Certificaataanvraagsjablonen zijn vooraf geconfigureerde, door het beleid goedgekeurde specificaties voor elke workloadcategorie: toegestane SAN-patronen, geldigheidsperioden, sleutelalgoritmen en EKU OID's. Ontwikkelaars selecteren een sjabloon bij het aanvragen van een certificaat; het platform handhaaft de beperkingen van het sjabloon zonder dat de ontwikkelaar de details van het certificaatbeleid hoeft te begrijpen. Sjablonen worden gekoppeld aan certificaatprofielen in de PKIaaS CA en aan CertificateRequestPolicy-resources in cert-manager.

Hoe moet een platformteam omgaan met certificaatverzoeken voor workloads die geen Kubernetes gebruiken?

Voor VM's en bare metal: ACME-clients (certbot, acme.sh) die verwijzen naar het PKIaaS ACME-eindpunt. Voor Terraform: HashiCorp Vault PKI secrets engine met PKIaaS als upstream CA, gebruikt via de Vault Terraform-provider. Voor Ansible: de PKIaaS REST API die wordt aangeroepen vanuit Ansible-taken, verpakt in een gestandaardiseerde platformrol. Voor netwerkapparaten: EST- of SCEP-eindpunten. Voor CI/CD-pipelinejobs: OIDC-tokenuitwisseling die kortstondige pipelinecertificaten uitgeeft zonder vooraf gedeelde geheimen.

Welke waarborgen moeten platformteams inbouwen in de certificaatuitgifte voor zelfservice door ontwikkelaars?

Vijf categorieën van beveiligingsmechanismen: beperkingen voor onderwerpnamen (toegestane CN- en SAN-patronen per naamruimte/team, afgedwongen door CertificateRequestPolicy), limieten voor de geldigheidsperiode (maximale geldigheid per workloadtype), minimumvereisten voor sleutelalgoritmen (minimale sleutelgrootte en algoritmevereisten), beperkingen voor certificaattypen (elk team/elke naamruimte kan alleen typen aanvragen die geschikt zijn voor hun workload; geen CA- of codeondertekeningscertificaten via de algemene ontwikkelaarsinterface) en auditzichtbaarheid (alle uitgiftegebeurtenissen worden vastgelegd in het PKIaaS-auditlogboek en weergegeven in het CLM-platform).