PKIaaS för interna utvecklarplattformar

Plattformsteknikteam blir ombedda att göra samma sak upprepade gånger, i olika former. Utvecklare behöver TLS-certifikat för sina tjänster. CI/CD-pipelines behöver autentiseringsuppgifter som inte är hårdkodade API-nycklar. Kubernetes-arbetsbelastningar behöver mTLS-identiteter. Säkerhetsteamet behöver att allt detta sker med konsekvent policy, granskningsbar utfärdande och ingen manuell PKI-teaminblandning i varje begäran. Svaret som plattformsteamet söker efter är vanligtvis ett tjänstkonto, ett delat certifikat eller ett självsignerat certifikatskript som är allokerat till arkivet. Inget av dessa är rätt svar.

Det rätta svaret är PKIaaS som en plattformsfunktion: plattformsteamet kopplar en styrd certifikatutfärdare till IDP:n en gång, exponerar den via ACME, cert-manager och ett API, och utvecklare får självbetjäningscertifikatutfärdande som automatiskt tillämpar säkerhetsteamets policyer utan att utvecklaren behöver veta vad en certifikatprofil är. Det här inlägget förklarar hur man bygger den funktionen.

Snabbt svar: Hur ser PKIaaS ut som en IDP-funktion?

PKIaaS blir en IDP-funktion när plattformsteamet konfigurerar PKIaaS CA-backend, definierar certifikatprofiler för varje arbetsbelastningstyp och exponerar dessa profiler via plattformens standardgränssnitt: en cert-manager ClusterIssuer för Kubernetes-arbetsbelastningar, en ACME-slutpunkt med OIDC-autentisering för CI/CD-pipelinejobb, en Terraform-providermodul för infrastruktur-som-kod-konsumenter och en Backstage-tjänstkatalogmall för team som föredrar ett UI-baserat förfrågningsflöde. Utvecklare begär certifikat via det gränssnitt de redan använder. PKIaaS CA tillämpar plattformsteamets certifikatpolicy utan någon komplexitet för utvecklaren. CLM-lagret ger säkerhetsteamet granskningsinsyn i hela certifikattillgången över alla plattformsklienter.

Key Takeaways

• Plattformsteamen är de rättmätiga ägarna av policyn för utfärdande av certifikat, inte applikationsutvecklare. Plattformsteamet sätter skyddsräckena en gång (giltiga certifikatprofiler, namngivningsbegränsningar, giltighetsperiodsgränser, minimivärden för nyckelalgoritmer). Utvecklare begär inom dessa skyddsräcken utan att veta att skyddsräckena existerar. Detta är samma asfalterade vägmodell som plattformsteamen tillämpar på containerbasbilder, Terraform-moduler och observationskonfigurationer.
• cert-manager är Kubernetes-gränssnittet mellan utvecklarnas arbetsbelastningar och PKIaaS CA. Plattformsteamet driftsätter cert-manager och konfigurerar en ClusterIssuer som pekar mot PKIaaS ACME-slutpunkten. Utvecklare deklarerar certifikatresurser i sina Kubernetes-manifest; cert-manager hanterar utfärdande, lagring som Kubernetes Secrets och automatisk förnyelse. Ingen utvecklarinteraktion krävs efter den initiala deklarationen.
• OIDC-tokenutbyte möjliggör CI/CD-pipelinecertifikat utan fördelade hemligheter. Moderna CI/CD-plattformar (GitHub Actions, GitLab CI, CircleCI) utfärdar OIDC-tokens till pipelinejobb som kan bytas mot kortlivade PKIaaS-certifikat via ACME:s externa kontobindningsmekanism. Pipelinejobbets certifikat är endast giltigt under jobbets varaktighet och upphör automatiskt. Ingen rotation av hemligheter krävs.
• Mallar för certifikatförfrågningar tar bort expertiskravet från certifikatförfrågningar på utvecklarsidan. Mallar definierar giltiga namngivningsmönster för ämnen, SAN-typer, giltighetsperioder och nyckelanvändning för varje certifikatkategori. Utvecklare väljer en mall; plattformen tillämpar mallbegränsningarna. Utvecklare behöver aldrig veta vad ett Extended Key Usage OID är eller vad CA/B Forums baslinjekrav säger om SAN-formatering.
• CA/B Forum SC-081v3:s maximala giltighetsschema på 47 dagar (gäller från och med den 15 mars 2029) gör automatisk förnyelse obligatorisk för alla publika TLS-certifikat. Plattformsteam som bygger in PKIaaS-baserad automatisk förnyelse i IDP:n bygger nu efterlevnadslösningen innan deadline anländer, och kämpar inte för att eftermontera automatisering över en manuellt hanterad certifikattillgång.

Plattformsteknikproblemet med certifikat

Plattformsteam står inför en specifik version av certifikathanteringsproblemet som skiljer sig från det företagsomfattande certifikathanteringsproblemet som säkerhetsteam står inför. Säkerhetsteam oroar sig för hela certifikattillgången: identifiering, inventering, policyefterlevnad, övervakning av utgångsdatum för alla certifikat från alla källor. Plattformsteam oroar sig för ett snävare men mer operativt omedelbart problem: hur får utvecklare certifikat för sina arbetsbelastningar utan att skapa en kö i PKI-teamets inkorg, utan att spara hemligheter till databaser och utan att skapa en certifikattillgång som är omöjlig att hantera i stor skala?

De mönster som plattformsteam strävar efter när PKIaaS inte är tillgängligt har alla samma felläge: de optimerar för utvecklarnas bekvämlighet på bekostnad av säkerhet och operativ hanterbarhet. Wildcard-certifikat som delas över tjänster eliminerar hantering av certifikat per tjänst, men eliminerar också isolering per tjänst: en komprometterad tjänst kan använda wildcard-certifikatet för att imitera vilken annan som helst. Självsignerade certifikat eliminerar PKI-teamets flaskhals men eliminerar också den förtroendekedja som gör mTLS meningsfull. Långlivade tjänstkontouppgifter ger en fungerande tillfällig lösning men ackumuleras som teknisk skuld: de kräver rotationshändelser som är svåra att koordinera över en stor utvecklarorganisation.

PKIaaS som en IDP-funktion eliminerar dessa kompromisser. Utvecklare får bekvämlighet tack vare självbetjäningsgränssnittet (en cert-manager-certifikatresurs, ett Terraform-modulanrop, en Backstage-mall). Certifikatsäkerhet tillhandahålls av PKIaaS CA (FIPS 140-3 Level 3 HSM-baserade nycklar, policystyrd utfärdande, automatiskt utgångsdatum). Operativ hanterbarhet tillhandahålls av CLM-lagret (enhetlig inventering, automatisk förnyelse, övervakning av policyefterlevnad). Plattformsteamet konfigurerar integrationen en gång; utvecklare använder den för alltid.

Kubernetes-integration: cert-manager som IDP-gränssnitt

För plattformsteam som kör Kubernetes-baserade IDP:er är cert-manager standardgränssnittet mellan utvecklarnas arbetsbelastningar och PKIaaS CA. Integrationsarkitekturen har tre lager som plattformsteamet konfigurerar en gång.

Klusterutgivarekonfiguration

Plattformsteamet installerar cert-manager i varje kluster och skapar en ClusterIssuer (eller flera namnrymdsbaserade utfärdare för kluster med flera hyresgäster med olika certifikatpolicyer per hyresgäst) som pekar mot PKIaaS ACME-slutpunkten. ClusterIssuer-konfigurationen anger ACME-serverns URL, nyckel-ID för extern kontobindning (EAB) och HMAC-hemlighet som utfärdats av PKIaaS-CA för detta kluster, samt DNS- eller HTTP-utmaningskonfigurationen för domänvalidering. För interna tjänster som använder privat DNS (vilket är det typiska fallet i en Kubernetes-företagsmiljö) är DNS-01-utmaning mot organisationens interna DNS-leverantör lämplig utmaningstyp.

När ClusterIssuer har konfigurerats och validerats kan varje certifikatresurs i varje namnrymd referera till den som utfärdare. Plattformsteamet styr vilka namnrymder som kan använda vilka utfärdare genom cert-managers CertificateRequestPolicy (cert-manager policygodkännandekomponent) i kombination med Kubernetes RBAC. Ett applikationsnamnrymd kan vara begränsat till att begära certifikat med SAN som matchar namnrymdens tilldelade domänmönster; ett systemnamnrymd kan ha åtkomst till en annan utfärdare som tillåter infrastrukturspecifika certifikattyper.

Certifikatresurser för utvecklare

Ur utvecklarens perspektiv ser det ut så här att begära ett certifikat i Kubernetes IDP: deklarera en certifikatresurs i tjänstens Helm-diagram eller Kustomize-överlägg och ange önskat ämne och SAN, referera till den plattformsbaserade ClusterIssuer och distribuera. cert-manager skapar en CertificateRequest, skickar CSR:n till PKIaaS ACME-slutpunkten, slutför domänvalideringsutmaningen, hämtar det signerade certifikatet och lagrar det som en Kubernetes-hemlighet. Applikationen refererar till hemligheten i sin Pod-specifikation som en volymmontering eller miljövariabel. Certifikatet visas i den körande Poden inom några sekunder efter att certifikatresursen har tillämpats.

När certifikatet närmar sig sin förnyelsegräns (cert-managers standardinställning är att förnyas när två tredjedelar av giltighetsperioden har gått), begär cert-manager automatiskt en förnyelse från PKIaaS ACME-slutpunkten. Det förnyade certifikatet ersätter det utgångna certifikatet i Kubernetes-hemligheten. Program som monterar hemligheten som en volym hämtar det nya certifikatet vid nästa filsystemsynkronisering utan en omstart av pod:en. Program som cachar certifikatvärdet vid start kräver en rullande omstart, vilket cert-manager kan utlösa automatiskt om det är konfigurerat för att göra det. Utvecklaren behöver inte spåra certifikatens utgångsdatum eller komma ihåg att initiera förnyelser.

Policy Guardrails via CertificateRequestPolicy

cert-managers policygodkännare lägger till det verkställighetslager som omvandlar ACME-stödda cert-manager från ett bekvämt certifikatverktyg till en styrd plattformsfunktion. CertificateRequestPolicy-resurser definierar vilka certifikatförfrågningar som är tillåtna för varje namnrymd eller begärare. En policy kan tillåta: SAN som matchar mönstret *.namespace-name.svc.cluster.local, nyckelstorlek på minst RSA-2048 eller ECDSA-256, certifikatgiltighet på maximalt 90 dagar och utökad nyckelanvändning endast för TLS-serverautentisering och TLS-klientautentisering. Alla CertificateRequests som inte matchar en godkänd policy nekas innan CSR:n når PKIaaS CA. Avslaget loggas, är synligt för plattformsteamet i cert-manager-granskningsloggen och visas i CLM-inventeringen som ett policybrott.

Detta ger plattformsteamet ett skyddsbeteende som gör självbetjäning säker: utvecklare kan begära vilket certifikat som helst som passar in i policyn, utan godkännandekö eller manuell granskning. Förfrågningar som faller utanför policyn nekas automatiskt med ett felmeddelande som talar om för utvecklaren vilken policybegränsning de brutit mot och vad rätt tillvägagångssätt är. Säkerhetsteamet definierar policyn; plattformen tillämpar den automatiskt; utvecklare arbetar inom den utan friktion.

Utfärdande av CI/CD-pipelinecertifikat

CI/CD-pipelinejobb behöver autentiseringsuppgifter av en annan anledning än att köra tjänster: de måste autentiseras mot distributionsmål, containerregister, artefaktlager och PKIaaS-kodsigneringstjänsten under byggprocessen. Certifikatautentiseringsuppgifterna för ett CI/CD-jobb ska endast vara giltiga under den specifika jobbkörningen, inte på obestämd tid.

OIDC-tokenutbyte för pipeline-certifikat

Moderna CI/CD-plattformar utfärdar OIDC-tokens till pipeline-jobb som kodar jobbets identitet: arkivet, grenen, arbetsflödesnamnet och miljön. Dessa tokens är kortlivade och signerade av CI/CD-plattformens OIDC-leverantör. Plattformsteamet konfigurerar PKIaaS ACME-slutpunkten för att acceptera dessa OIDC-tokens som externa kontobindningsuppgifter via ett tokenutbytesflöde: pipeline-jobbet presenterar sin OIDC-token till en konfigurerad utbytesslutpunkt, som validerar token mot CI/CD-plattformens JWKS-slutpunkt och utfärdar en EAB-autentiseringsuppgifter. Pipeline-jobbet använder denna EAB-autentiseringsuppgifter för att begära ett certifikat från PKIaaS ACME-slutpunkten.

Det resulterande certifikatet är giltigt för den konfigurerade pipeline-certifikatprofilen (vanligtvis 1 till 4 timmar, vilket täcker den maximala förväntade pipeline-körtiden). Certifikatet kodar pipelines identitet i dess ämne (arkivet och arbetsflödet i CN- eller SAN URI-fältet). När pipeline-jobbet använder detta certifikat för att autentisera mot distributionsmål eller signeringstjänster kan dessa system verifiera pipelines identitet från certifikatet och fatta auktoriseringsbeslut baserat på vilket arkiv och arbetsflöde som körs. Certifikatet upphör automatiskt när jobbet avslutas. Ingen rotation av hemligheter krävs: det finns inga långlivade autentiseringsuppgifter att rotera eftersom inga långlivade autentiseringsuppgifter utfärdas.

Kodsigneringscertifikat för pipelineartefakter

Samma PKIaaS CA som utfärdar servicecertifikat och pipeline-identitetscertifikat kan också utfärda kodsigneringscertifikat för signering av containeravbildningar, binärfiler, paket och distributionsmanifest som produceras av CI/CD-pipelinen. Plattformsteamet konfigurerar en separat kodsigneringscertifikatprofil i PKIaaS CA (med Code Signing Extended Key Usage OID 1.3.6.1.5.7.3.3) och exponerar den via PKIaaS REST API eller en dedikerad signeringstjänst. Pipelinejobb som producerar artefakter begär ett signeringscertifikat via denna profil, signerar sina artefakter och certifikatet upphör att gälla när jobbet avslutas. Kubernetes-åtkomstkontroller (Sigstores Policy Controller, OPA/Gatekeeper med bildverifieringspolicyer) kan verifiera containeravbildningssignaturer mot PKIaaS CA:s förtroenderot innan distribution tillåts, vilket säkerställer att endast avbildningar som signerats av auktoriserade pipelinejobb släpps in i klustret.

Integrering av infrastruktur som kod

Inte alla arbetsbelastningar i en företags-IDP körs i Kubernetes. Virtuella maskiner, bare metal-tjänster, serverlösa funktioner och nätverksapparater behöver alla certifikat, och deras plattformsteam hanterar ofta infrastruktur via Terraform, Pulumi eller Ansible snarare än Kubernetes-manifest. PKIaaS exponerar ett REST API som infrastruktur-som-kod-verktyg kan konsumera direkt.

För Terraform-baserade IDP:er kan HashiCorp Vault PKI-hemlighetsmotorn konfigureras för att använda PKIaaS som uppströms certifikatutfärdare, vilket exponerar en Vault PKI-montering som Terraform-resurser förbrukar via Vault Terraform-leverantören. Plattformsteamet hanterar Vault-konfigurationen och PKIaaS CA-integrationen; Terraform-moduler som applikationsteam skriver förbrukar Vault PKI-monteringen utan att känna till den underliggande PKIaaS CA:n. Certifikatutfärdande sker som en del av Terraform-tillämpningen: resursdefinitionen anger önskade certifikatparametrar, Vault utfärdar certifikatet från sin PKIaaS-baserade PKI-montering och certifikatet lagras i Vaults hemliga arkiv. Terraform-tillstånd refererar till Vaults hemliga sökväg; den faktiska privata certifikatnyckeln skrivs aldrig till Terraform-tillstånd eller ett versionskontrollsystem.

För Ansible-baserad provisionering kan PKIaaS REST API anropas direkt från Ansible-uppgifter med hjälp av uri modulen, eller genom community-utvecklade Ansible-moduler för ACME-certifikathantering. Plattformsteamet tillhandahåller en standardiserad Ansible-roll som omsluter PKIaaS-certifikatutfärdande-API:et och hanterar nyckelgenerering, CSR-konstruktion, inlämning och certifikatlagring i en standardsökväg på den provisionerade värden. Applikationsteam inkluderar rollen i sina playbooks med parametrar som anger önskad certifikattyp (som mappas till en PKIaaS-certifikatprofil); rollen hanterar allt annat.

Integrering bakom scenen och tjänstekatalogen

Många team med mogna plattformar använder en utvecklarportal (Backstage är det mest använda alternativet med öppen källkod) som frontend-gränssnitt till IDP:n. För utvecklingsteam som föredrar ett UI-drivet förfrågningsflöde framför att skriva Kubernetes-manifest eller Terraform-kod kan PKIaaS-certifikatutfärdandefunktionen visas i tjänstekatalogen som en programvarumall.

En Backstage-mall för certifikatutfärdande presenterar ett formulär för utvecklaren: välj certifikattyp (från en rullgardinsmeny med godkända mallar), ange tjänstnamnet (som fyller i CN och DNS SAN baserat på teamets namngivningspolicy), välj distributionsmiljö (som avgör den utfärdande CA:n och giltighetsperioden). Att skicka in formuläret utlöser en scaffolding-åtgärd som skapar cert-manager Certificate-resursen (eller Terraform-variabelfilen eller Ansible Playbook-anropet) i teamets GitOps-arkiv via en pull request. Utvecklaren godkänner pull requesten; GitOps-pipelinen distribuerar certifikatresursen; cert-manager utfärdar certifikatet från PKIaaS. Utvecklarens interaktion med PKI motsvarar att fylla i ett tvåminutersformulär. Plattformen tillämpar säkerhetsteamets certifikatpolicy i bakgrunden.

Backstage-tjänstkatalogen kan också visa information om certifikathälsa för tjänster som är registrerade i katalogen. Ett Backstage-plugin som är anslutet till CLM-lagret kan visa varje tjänsts certifikatinventering, aktuella utgångsdatum, förnyelsestatus och eventuella policyöverträdelser på tjänstens Backstage-entitetssida. Utvecklare får insyn i sin tjänsts certifikatstatus utan att lämna utvecklarportalen, och säkerhetsteamet får samma insyn från CLM-plattformens centraliserade instrumentpanel utan att behöva fråga utvecklare om deras certifikatstatus.

Utforma certifikatmallar för plattformsteam

Certifikatmallens design är det viktigaste säkerhetsbeslutet i plattformsteamets PKIaaS-integration. Mallar avgör vad plattformen kommer att utfärda; policyn avgör vad den inte kommer att utfärda. En väl utformad malluppsättning för en företags-IDP innehåller vanligtvis följande kategorier:

TLS-certifikat för intern tjänst. Används för HTTPS-slutpunkter på interna tjänster som inte behöver vara betrodda av externa klienter. Ämnes-CN: service-name.namespace.svc.cluster.localSAN: DNS-SAN som matchar Kubernetes-tjänstens DNS-namn och eventuellt Podens IP-adress som ett IP-SAN. Nyckel: ECDSA P-256 eller RSA-2048. Giltighetstid: 90 dagar. EKU: TLS-serverautentisering. Automatiska förnyelser hanteras av cert-manager.

mTLS-klientcertifikat (tjänstidentitet). Används av tjänster som gör utgående anrop till andra tjänster som kräver ömsesidig TLS-autentisering. Ämnes-CN: tjänstens identitetsnamn. URI SAN: SPIFFE-ID om SPIFFE används. Nyckel: ECDSA P-256. Giltighet: 24 till 48 timmar (kortlivad, matchad med containerns livscykel). EKU: TLS-klientautentisering. Förnyas automatiskt av cert-manager eller SPIRE.

CI/CD-certifikat för pipeline-jobb. Används av pipeline-jobb för att autentisera mot distributionsmål och signeringstjänster. Ämnes-CN: databasens och arbetsflödes-ID:n. URI SAN: pipeline-jobbets OIDC-ämnesanspråk. Nyckel: ECDSA P-256. Giltighet: 1 till 4 timmar. EKU: TLS-klientautentisering. Utfärdas via OIDC-tokenutbyte vid pipelinestart, upphör att gälla vid pipelineslut.

Internetanslutet TLS-certifikat. Används för tjänster som behöver litas på av externa klienter. Ämnes-CN: det publika domännamnet. SAN: alla tillämpliga publika domännamn. Nyckel: ECDSA P-256 eller RSA-2048. Giltighet: i linje med CA/B Forum SC-081v3-schemat (200 dagar till och med 15 mars 2026; 100 dagar till och med 15 mars 2027; 47 dagar från och med 15 mars 2029). EKU: TLS-serverautentisering. Förnyas automatiskt av cert-manager. Denna mall kräver antingen en offentligt betrodd utfärdande CA eller korscertifiering med en offentlig CA-rot, eftersom privata CA-certifikat inte är betrodda av offentliga webbläsare.

Kodsigneringscertifikat. Används av pipeline-jobb för att signera containeravbildningar, binärfiler och distributionsmanifest. Ämnes-CN: pipeline- eller teamidentiteten. Nyckel: RSA-4096 eller ECDSA P-384 (högre tillförlitlighet än servicecertifikat). Giltighetstid: 1 till 4 timmar. EKU: Kodsignering (OID 1.3.6.1.5.7.3.3). Åtkomst begränsad till auktoriserade signeringspipelines av CertificateRequestPolicy.

Integration av revisionssynlighet och säkerhetsteam

Självbetjäningscertifikatutfärdande skapar en fråga om revisionsspår: om vilken utvecklare som helst kan begära ett certifikat via plattformen, hur vet säkerhetsteamet vad som har utfärdats och om utfärdandet var policykompatibelt? Svaret är CLM-lagret som är anslutet till PKIaaS CA.

Varje certifikatutfärdandehändelse via de plattformsexponerade PKIaaS-slutpunkterna loggas i PKIaaS-granskningsloggen med den utfärdande certifikatutfärdaren, certifikatsubjektet och SAN:erna, den begärande identiteten (cert-manager-tjänstkontot, pipeline-OIDC-subjektet eller Terraform-arbetsytan) och tidsstämpeln. CLM-plattformen som är ansluten till PKIaaS-certifikatutfärdaren ger säkerhetsteamet en enhetlig bild av hela certifikattillgången för alla plattformsklienter: vilka tjänster som har certifikat, hur deras utgångsprofiler ser ut, vilka certifikat som närmar sig förnyelse och vilka certifikatförfrågningar som nekades av policyn.

För säkerhetsteamet är detta väsentligt bättre än alternativet (ingen insyn i utvecklarutfärdade certifikat, utan man förlitar sig på nätverksskanning för att hitta vad som faktiskt distribueras). För plattformsteamet ger det bevisbasen för efterlevnadsrevisioner: varje certifikat i miljön kan spåras tillbaka till en autentiserad utfärdandeförfrågan via plattformen, snarare än att vara av okänt ursprung.

SIEM-integration från CLM-plattformen matar in händelser under certifikatens livscykel (utfärdande, förnyelse, utgångsvarningar, policyöverträdelser, återkallelsehändelser) i säkerhetsövervakningsstacken tillsammans med andra infrastrukturhändelser. En utgångsvarning för ett tjänstecertifikat visas i samma SIEM-instrumentpanel som ett misslyckat inloggningsförsök eller en avvikande nätverksanslutning, vilket ger säkerhetsteamet kontextuell insyn i certifikatrisker utan att kräva en separat certifikathanteringskonsol.

Design för flera kluster och flera miljöer

Företags-IDP:er omfattar vanligtvis flera Kubernetes-kluster (utveckling, staging, produktion, regionspecifika kluster) och flera distributionsmiljöer (publikt moln, lokalt, edge). PKIaaS CA-hierarkin måste ta hänsyn till denna topologi.

Den rekommenderade designen använder en enda PKIaaS-rot-CA med miljöspecifika utfärdande CA:er: en utvecklingsutfärdande CA för alla utvecklingskluster, en mellanliggande CA för alla mellanliggande kluster och en eller flera produktionsutfärdande CA:er för produktionskluster (potentiellt regionspecifika utfärdande CA:er för datalagringskrav). Varje utfärdande CA har sin egen certifikatprofil som är lämplig för den miljön. Utvecklingsmiljöns CA kan tillåta längre giltighetsperioder och lösare namngivningsbegränsningar eftersom certifikatutgången under utveckling orsakar friktion hos utvecklarna. Produktionsmiljöns CA tillämpar kortare giltighetsperioder och strikta namngivningsbegränsningar eftersom certifikatutgången i produktion orsakar användarvändiga incidenter.

Miljöisolering genom CA-hierarkin innebär att ett certifikat som utfärdats av den utvecklingsutfärdande CA:n inte kan autentiseras mot en produktionstjänst. Produktionstjänstens förtroendearkiv innehåller endast det produktionsutfärdande CA-certifikatet (inte utvecklingscertifikatet), trots att båda är kopplade till samma rot. Detta är en teknisk kontroll av explosionsradien för komprometterade utvecklingsmiljöer: ett komprometterat utvecklingskluster kan inte användas för att imitera en produktionstjänst även om angriparen får ett utvecklingsmiljöcertifikat.

47 dagars certifikatgiltighet och plattformsteknik

CA/B Forum Ballot SC-081v3, godkänd i april 2025, fastställer följande schema för maximal TLS-certifikatgiltighet för offentligt betrodda certifikat: 200 dagar från 15 mars 2026; 100 dagar från 15 mars 2027; 47 dagar från 15 mars 2029. För plattformsteam som hanterar en stor Kubernetes-baserad certifikattillgång skapar detta ett automatiseringsmandat: certifikat som förnyas var 47:e dag kan inte hanteras manuellt. Den enda gångbara operativa modellen är automatiserad förnyelse via cert-manager eller en motsvarande kontrollant.

Plattformsteam som integrerar PKIaaS-baserad cert-manager-automation i IDP:n bygger nu 47-dagars efterlevnadslösningen som en bieffekt av att lösa det omedelbara självbetjäningsproblemet för utvecklare. Varje certifikatresurs som deklareras i en utvecklares Kubernetes-manifest hanteras automatiskt av cert-manager, som förnyar den före utgången oavsett giltighetsperiod. En övergång från 90-dagars till 47-dagars certifikat kräver endast en ändring av certifikatprofilens giltighetsperiod i PKIaaS CA- och CertificateRequestPolicy-konfigurationen. Det utvecklarvänliga gränssnittet (certifikatresursdeklarationen i Helm-diagrammet) ändras inte. Efterlevnadsövergången är en ändring av plattformskonfigurationen, inte ett utvecklarmigreringsprojekt.

Hur krypteringskonsulting kan hjälpa

• PKI som en tjänst: Krypteringskonsulttjänster PKIaaS-erbjudande tillhandahåller den styrda CA-backend för utfärdande av IDP-certifikat: ACME+EAB för konfiguration av cert-manager ClusterIssuer, REST API för Terraform- och Ansible-integration, stöd för OIDC-tokenutbyte för utfärdande av CI/CD-pipelinecertifikat, certifikatprofiler för varje arbetsbelastningskategori (tjänst-TLS, mTLS-klientidentitet, pipelinejobb, kodsignering) och miljöspecifika utfärdande CA:er för IDP-topologier med flera kluster. Kontakta oss på Krypteringskonsulting för att diskutera er IDP-certifikatarkitektur.
• CertSecure-chef: Krypteringskonsulttjänster CertSecure-hanterare Tillhandahåller CLM-synlighetslagret för plattformsteamet och säkerhetsteamet: enhetlig certifikatinventering över alla kluster och miljöer, cert-manager Certifikatresursidentifiering, övervakning av utgångsdatum med konfigurerbara tröskelvärden för varningar, rapportering av policyefterlevnad (flaggning av certifikat som bryter mot plattformens angivna mallbegränsningar) och SIEM-integration för händelseflöden för certifikatlivscykeln. Backstage-plugins som visar CertSecure Manager-data i utvecklarportalen möjliggör synlighet av certifikathälsa per tjänst utan att lämna utvecklarportalen.
• CodeSign Säkert: För plattformsteam som exponerar kodsignering som en IDP-funktion, Encryption Consultings CodeSign Secure tillhandahåller den HSM-baserade kodsigneringsinfrastrukturen som CI/CD-pipelines använder för att signera containeravbildningar, binärfiler och distributionsmanifest. Signeringsnycklar lagras i FIPS 140-3 nivå 3 HSM:er; varje signeringshändelse loggas i revisionsloggen; signeringspolicyer begränsar vilka pipelines som kan signera vilka artefakttyper. Integration med Kubernetes-åtkomstkontroller (Sigstore Policy Controller) möjliggör signaturverifiering som en åtkomstgrind för alla klusterdistributioner.
• PKI-tjänster: För plattformsteam som utformar PKIaaS IDP-integrationen från grunden, Encryption Consultings PKI-tjänster Tillhandahålla CA-hierarkidesign för IDP:er med flera kluster och flera miljöer, certifikatmalldesign för varje arbetsbelastningskategori, konfiguration av Cert-Manager CertificateRequestPolicy, konfiguration av OIDC-tokenutbyte för CI/CD-pipelines, Terraform- och Ansible-integrationsmönster och Backstage-plugin-rådgivning för certifikathälsomiljön i utvecklarportalen.
• PQC-rådgivningstjänster: Plattformsteam som bygger in PKIaaS-baserad certifikatautomation i IDP:n lägger nu också grunden för övergången till kvantcertifikat. Encryption Consultings PQC-rådgivningstjänster integrera planering för utfärdande av hybridcertifikat för ML-DSA (FIPS 204) i IDP-certifikatmalldesignen, så att PQC-övergången är en konfigurationsändring av PKIaaS-profilerna och certifikathanterarmallarna snarare än ett migreringsprojekt som riktar sig till utvecklaren.

Slutsats

Den interna utvecklarplattformen är rätt plats att lösa problemet med hantering av företagscertifikat för utvecklarnas arbetsbelastningar. Utvecklare behöver certifikat; de ska kunna få dem genom samma verktyg som de använder för allt annat i plattformen. Säkerhetsteam behöver insyn och policytillämpning; de ska få det automatiskt från plattformens CLM-lager, inte genom manuell granskning av enskilda förfrågningar. Plattformsteam behöver en skalbar, underhållbar lösning; de ska få den från en korrekt integrerad PKIaaS-backend snarare än från en samling skript och delade hemligheter.

Integrationen är inte komplex. cert-manager ClusterIssuer som pekar på en PKIaaS ACME-slutpunkt. CertificateRequestPolicy som definierar skyddsräcken. OIDC-tokenutbyte för pipeline-jobb. Vault PKI-hemlighetsmotor för Terraform-konsumenter. En Backstage-mall för team som vill ha ett användargränssnitt. Dessa är alla standardmönster för plattformsteknik, och PKIaaS är den styrda CA-backend som får dem att fungera utan att skapa en säkerhetsskuld som ackumuleras snabbare än plattformsteamet kan betala av den.

CA/B Forums 47-dagars giltighetsschema för certifikat gör denna integration brådskande. Plattformsteam som automatiserar utfärdande och förnyelse av certifikat före 2029 bygger en plattformskapacitet som hanterar övergången till efterlevnad utan en utvecklarorienterad migrering. Plattformsteam som väntar bygger en manuell process som kommer att misslyckas vid 47-dagarsskalan.

Om ert plattformsteam utformar PKIaaS-integration för er IDP och vill validera arkitekturen, kontakta Encryption Consulting.

Det här inlägget granskas med sex månaders mellanrum och när cert-manager, Backstage, CA/B Forum SC-081v3:s giltighetsschema eller större IDP-plattformar publicerar uppdateringar som påverkar integrationsmönster för certifikatautomation.

Vanliga frågor om partihandel med mat och dryck

Vilken roll spelar PKIaaS i en intern utvecklarplattform?

PKIaaS är den styrda CA-backend som plattformsteamet konfigurerar en gång och exponerar via standard IDP-gränssnitt: cert-manager ClusterIssuers för Kubernetes-arbetsbelastningar, ACME-slutpunkter med OIDC-autentisering för CI/CD-pipelinejobb, Terraform-leverantörer för IaC-konsumenter och Backstage-mallar för UI-drivna förfrågningar. Utvecklare får självbetjäningscertifikatutfärdande genom välbekanta verktyg; plattformen tillämpar säkerhetsteamets certifikatpolicy automatiskt i bakgrunden.

Hur integrerar cert-manager PKIaaS i en Kubernetes-baserad IDP?

Plattformsteamet installerar cert-manager och konfigurerar en ClusterIssuer som pekar mot PKIaaS ACME-slutpunkten med External Account Binding-inloggningsuppgifter. Utvecklare deklarerar certifikatresurser i sina Kubernetes-manifest; cert-manager hanterar utfärdandet, lagrar certifikatet som en Kubernetes-hemlighet och förnyar det automatiskt innan det löper ut. cert-managers CertificateRequestPolicy tillämpar plattformens certifikatprofilskydd och avvisar förfrågningar som faller utanför godkända parametrar innan CSR:n når PKIaaS CA.

Vad är mallar för certifikatförfrågningar i samband med PKIaaS och IDP:er?

Mallar för certifikatförfrågningar är förkonfigurerade, policygodkända specifikationer för varje arbetsbelastningskategori: tillåtna SAN-mönster, giltighetsperioder, nyckelalgoritmer och EKU OID:er. Utvecklare väljer en mall när de begär ett certifikat; plattformen tillämpar mallens begränsningar utan att utvecklaren behöver förstå certifikatpolicydetaljer. Mallar mappas till certifikatprofiler i PKIaaS CA och till CertificateRequestPolicy-resurser i cert-manager.

Hur ska ett plattformsteam hantera certifikatförfrågningar för arbetsbelastningar som inte är Kubernetes?

För virtuella maskiner och bare metal: ACME-klienter (certbot, acme.sh) pekade mot PKIaaS ACME-slutpunkt. För Terraform: HashiCorp Vault PKI-hemlighetsmotor med PKIaaS som uppströms CA, konsumerad via Vault Terraform-leverantören. För Ansible: PKIaaS REST API som anropas från Ansible-uppgifter, inkapslat i en standardiserad plattformsroll. För nätverksapparater: EST- eller SCEP-slutpunkter. För CI/CD-pipelinejobb: OIDC-tokenutbyte som utfärdar kortlivade pipeline-certifikat utan fördelade hemligheter.

Vilka skyddsräcken bör plattformsteam bygga in i certifikatutfärdandet för utvecklares självbetjäning?

Fem skyddsräckeskategorier: begränsningar för ämnesnamn (tillåtna CN- och SAN-mönster per namnrymd/team, upprätthållna av CertificateRequestPolicy), giltighetsperiodsgränser (maximal giltighet per arbetsbelastningstyp), minimivärden för nyckelalgoritmer (minimi nyckelstorlek och algoritmkrav), begränsningar för certifikattyper (varje team/namnrymd kan bara begära typer som är lämpliga för deras arbetsbelastning, inga CA- eller kodsigneringscertifikat via det allmänna utvecklargränssnittet) och granskningssynlighet (alla utfärdandehändelser loggas till PKIaaS-granskningsloggen och visas i CLM-plattformen).