Wat is werkbelastingidentiteit? SPIFFE uitgelegd

Workload-identificatie is de praktijk waarbij elke softwareworkload, zoals een container, microservice, virtuele machine of geautomatiseerd proces, een eigen verifieerbare cryptografische identiteit krijgt, zodat deze zich zonder statische geheimen kan authenticeren bij andere systemen. SPIFFE (Secure Production Identity Framework For Everyone) is de open standaard die definieert hoe deze identiteiten worden benoemd, uitgegeven en geverifieerd.

Bij workload-identificatie wordt aan elke softwareworkload, zoals een container, microservice of virtuele machine, een kortstondige cryptografische authenticatiecode toegekend op basis van geverifieerde eigenschappen van de workload in plaats van een opgeslagen geheim. SPIFFE, een CNCF-standaard, definieert het identiteitsformaat en de authenticatietypen, en SPIRE is de runtime die deze authenticatiecodes in productie uitgeeft en roteert.

Key Takeaways

• Een workload-identiteit authenticeert een softwareworkload (container, service, VM of proces) met een geattesteerde, kortstondige referentie in plaats van een API-sleutel of gedeeld geheim.
• SPIFFE definieert de standaard: een SPIFFE ID in de vorm spiffe://trust-domain/path, geleverd als een X.509-certificaat of JWT genaamd een SVID (SPIFFE Verifiable Identity Document).
• SPIRE, de SPIFFE Runtime Environment, geeft SVID's uit via node- en workload-attestatie zonder bootstrap-geheim. Beide projecten zijn in september 2022 afgestudeerd aan de CNCF.
• SPIRE geeft X.509 SVID's uit met een standaard geldigheidsduur van één uur en roteert deze automatisch, waardoor gestolen workload-referenties binnen een uur verlopen in plaats van maandenlang geldig te blijven.
• NIST-SP 800-207A SPIFFE wordt genoemd als infrastructuur voor applicatie-identiteit ten behoeve van Zero Trust in cloud-native, multi-cloudomgevingen.

Waarom werklasten een eigen identiteit nodig hebben

In de meeste productieomgevingen zijn machines tegenwoordig in de meerderheid ten opzichte van menselijke gebruikers, en elke serviceaanroep tussen die machines vereist een vertrouwensbeslissing. Een betaalservice moet er zeker van zijn dat het zojuist ontvangen verzoek daadwerkelijk afkomstig is van de betaalservice en niet van een gecompromitteerde pod op hetzelfde netwerk.

Traditionele oplossingen voor dat probleem zijn gebaseerd op iets wat de workload bevat: een API-sleutel in een omgevingsvariabele, een wachtwoord in een configuratiebestand, een certificaat dat voor drie jaar is uitgegeven en tussen hosts is gekopieerd. Statische inloggegevens lekken in broncode repositories en logs, blijven lang bestaan ​​nadat de workload die ze gebruikte is verdwenen, en worden zelden geroteerd omdat rotatie problemen veroorzaakt. Netwerklocatie is geen betere indicator voor vertrouwen, omdat containers netwerken delen, IP-adressen binnen enkele seconden worden hergebruikt en een enkele gecompromitteerde host zich binnen de perimeter bevindt.

Workload-identiteit vervangt wat een service weet (een geheim) door wat een service ís (een geverifieerde identiteit). De authenticatiegegevens zijn afgeleid van verifieerbare feiten over de workload en het platform waarop deze draait, ze zijn minuten of uren geldig en worden automatisch vernieuwd zonder menselijke tussenkomst.

Wat is SPIFFE?

SPIFFE, het Secure Production Identity Framework For Everyone, is een open standaard die definieert hoe workload-identiteiten worden benoemd, hoe de authenticatiegegevens eruitzien en hoe workloads deze ontvangen. Het project wordt gehost door de Cloud Native Computing Foundation en bereikte in september 2022 de status 'graduated', hetzelfde volwassenheidsniveau als Kubernetes. SPIFFE definieert vier bouwstenen:

• SPIFFE ID: Een URI in de vorm spiffe://trust-domain/path, bijvoorbeeld spiffe://prod.example.com/payments/api. Het trust-domein is de administratieve grens; het pad benoemt de workload daarbinnen.
• SVID: Het SPIFFE Verifiable Identity Document (SVID) is de authenticatiemethode die de SPIFFE-ID bewijst. Een X.509-SVID integreert de SPIFFE-ID als een URI in het Subject Alternative Name-veld van het certificaat en kan direct worden gebruikt in wederzijdse TLS-verbindingen. Een JWT-SVID heeft dezelfde identiteit als een ondertekend token voor HTTP- en API-contexten.
• Workload API: Een lokale API, beschikbaar via een Unix-domeinsocket, waarmee een workload zijn SVID en de trust bundle ophaalt die gebruikt wordt om peers te verifiëren. Voor het aanroepen van de API zijn geen inloggegevens vereist; het platform bevestigt de authenticiteit van de aanroeper.
• FederatieTwee onafhankelijke vertrouwensdomeinen kunnen vertrouwensbundels uitwisselen en elkaars workloads verifiëren zonder een gemeenschappelijke root-CA te delen, waardoor authenticatie tussen clouds en organisaties praktisch uitvoerbaar wordt.

SPIFFE zelf levert geen software mee. Het is de specificatie. De referentie-implementatie die in productie draait, is SPIRE.

Hoe SPIRE werkbelastingidentiteiten toekent

SPIRE, de SPIFFE Runtime Environment, geeft identiteiten uit via een attestatieketen in plaats van een gedistribueerd geheim. Een SPIRE-server fungeert als vertrouwensanker voor het domein en een SPIRE-agent draait op elk knooppunt. De uitgifte verloopt in vier stappen:

1. Knooppuntattestatie: De agent bewijst op welk knooppunt hij draait met behulp van platformbewijs, zoals een AWS-instantie-identiteitsdocument, een door Azure beheerde identiteit of een Kubernetes-serviceaccounttoken.
2. Verklaring van werkbelasting: Wanneer een proces de Workload API aanroept, inspecteert de agent dit via het platform: de Kubernetes-namespace en het serviceaccount, de Unix-gebruikers-ID of de containerimage.
3. SVID-uitgifte: De server vergelijkt deze geverifieerde eigenschappen met registratiegegevens en genereert een SVID voor de bijbehorende SPIFFE ID.
4. Automatische rotatie: De standaard levensduur van een X.509 SVID in SPIRE is één uur, en de agent vernieuwt elke SVID voordat deze verloopt. Workloads verwerken nooit een vernieuwingsgebeurtenis.

Omdat de identiteit is afgeleid van attestatie, is er geen bootstrap-geheim dat verspreid, bewaard of gelekt kan worden. In de aankondiging van de CNCF-afstudering worden Bloomberg, ByteDance, Pinterest, Twilio, Uber, Netflix en GitHub genoemd als gebruikers in productieomgevingen, en service meshes zoals Istio gebruiken het SPIFFE-identiteitsformaat voor hun workloadcertificaten. Voor details over de implementatiearchitectuur en configuratie, zie de diepgaande analyse van SPIFFE en SPIRE door Encryption Consulting.

Werkbelastingidentiteit versus statische geheimen

Het praktische verschil tussen SPIFFE-achtige workloadidentificatie en statische machinegegevens komt tot uiting in levensduur, rotatie en impactbereik.

Kenmerk	Statische geheimen (API-sleutels, langlopende certificaten)	SPIFFE-werkbelastingidentiteit
Vertrouwensgrondslag	Wat de werklast inhoudt	Wat de werkdruk is, bevestigd door attestatie.
Typische levensduur	Maanden tot jaren	Standaard één uur in SPIRE, configureerbaar naar minuten.
Rotatie	Handleiding, wordt vaak overgeslagen	Automatisch, vóór elke vervaldatum
Bootstrap	Het geheim moet eerst worden verspreid.	Geen Bootstrap-geheim; alleen platformattestatie.
Draagbaar	Vastgebonden aan één platform of kluis	Dezelfde spiffe://-identiteit in alle clouds, clusters en virtuele machines.
Explosiekracht indien gestolen	Geldig totdat iemand het ontdekt en intrekt.	Beperkt tot de resterende minuten van de geldigheidsduur van de accreditatie.

De rol van Workload Identity binnen Zero Trust.

Zero Trust beschouwt identiteit, en niet netwerklocatie, als de primaire toegangscontrole, en workload-identiteit is hoe dit principe wordt toegepast op machine-to-machine-verkeer. NIST SP 800-207 (augustus 2020) definieert de Zero Trust-architectuur. De cloud-native tegenhanger, NIST SP 800-207A (september 2023), benoemt SPIFFE expliciet als applicatie-identiteitsinfrastructuur voor toegangscontrole in multi-cloudomgevingen, naast API-gateways en sidecar-proxies. De NIST SP 800-204- reeks legt dezelfde link voor service mesh-implementaties, waarbij wederzijdse TLS tussen workloads de identiteit overdraagt.

Standaardisatie is nog steeds in ontwikkeling. De IETF WIMSE-werkgroep (Workload Identity in Multi System Environments) definieert hoe workload-identiteiten en -tokens samenwerken in verschillende vertrouwensdomeinen, en diezelfde identiteitsinfrastructuur biedt nu antwoord op een nieuwere vraag: hoe authenticeren we AI-agenten en andere niet-menselijke identiteiten die autonoom opereren in verschillende systemen?

Workload-identificatie vereist nog steeds Enterprise PKI.

SPIFFE vervangt PKI niet; het is PKI toegepast op workloads met machinesnelheid. Elk vertrouwensdomein wordt ondersteund door ondertekeningssleutels die functioneren als een certificeringsinstantie. Iemand moet bepalen waar de root van dat vertrouwensdomein zich bevindt, de sleutels beschermen, de rotatie plannen en beslissen of SVID's verwijzen naar een zelfstandige root of naar een upstream bedrijfs-CA via de UpstreamAuthority-integratie van SPIRE.

Dit zijn klassieke PKI-governancevragen, en ze worden complexer naarmate SPIFFE-implementaties toenemen: platformteams zetten vertrouwensdomeinen op per cluster, er worden duizenden certificaten per dag uitgegeven, en niets daarvan verschijnt in een certificaatinventaris die is opgebouwd voor TLS-eindpunten. Een organisatie die haar workloadcertificaten niet kan inzien, kan ze ook niet controleren, en een rootcertificaat van een vertrouwensdomein dat op een laptop is gegenereerd, is net zo goed een rootcertificaat. Het verankeren van vertrouwensdomeinen in een gecontroleerde CA-hiërarchie en het uitbreiden van de zichtbaarheid van certificaten naar kortstondige workloadreferenties is wat een veelbelovend framework transformeert in een controleerbaar identiteitsprogramma. Een basiskennis van de fundamenten van de public key infrastructure (PKI) is hierbij nuttig, omdat elk SPIFFE-concept overeenkomt met een PKI-concept.

Hoe encryptieconsultancy kan helpen

PKI-as-a-Service biedt u een beheerde, door HSM ondersteunde certificeringsinstantiehiërarchie die kan dienen als het upstream-vertrouwensanker voor SPIFFE-vertrouwensdomeinen. Hierdoor loopt de keten van workloadreferenties naar een root die uw organisatie beheert, waarbij sleutelceremonies en -rotatie volgens plan worden uitgevoerd. CertSecure Manager houdt vervolgens machine- en workloadcertificaten zichtbaar in één inventaris, volgt de vervaldatum en automatiseert de levenscyclus in verschillende clouds en clusters. Ondersteund door ISO/IEC 27001:2022 en SOC 2-gecertificeerde werkwijzen.

Veelgestelde Vragen / FAQ

Wat is workload identity in eenvoudige bewoordingen?

De identiteit van een workload is als een paspoort voor software. In plaats van dat een persoon inlogt, krijgt een container, microservice of virtuele machine een eigen, kortstondige cryptografische authenticatiecode die bewijst wat het is. Andere services controleren die code voordat ze gegevens uitwisselen, net zoals een grenswacht een paspoort controleert. Hierdoor hoeft er nooit een gedeeld wachtwoord of API-sleutel te worden opgeslagen of verspreid.

Wat is het verschil tussen SPIFFE en SPIRE?

SPIFFE is de specificatie en SPIRE is de software die deze implementeert. SPIFFE definieert het identiteitsformaat (spiffe://trust-domain/path), de SVID-referentietypen en de Workload API. SPIRE, de SPIFFE Runtime Environment, attesteert knooppunten en workloads, geeft SVID's uit en roteert deze automatisch. Beide projecten zijn in september 2022 afgestudeerd aan de Cloud Native Computing Foundation.

Hoe ziet een SPIFFE-ID eruit?

Een SPIFFE ID is een URI in de vorm spiffe://trust-domain/path, bijvoorbeeld spiffe://prod.example.com/payments/api. Het trust-domein verwijst naar de uitgevende instantie en het pad identificeert de specifieke workload daarbinnen. Dezelfde SPIFFE ID blijft geldig, ongeacht of de workload in Kubernetes, op een virtuele machine of bij verschillende cloudproviders draait, waardoor de identiteit overdraagbaar is.

Vervangt SPIFFE PKI of een certificeringsinstantie?

Nee. SPIFFE past public key infrastructure (PKI) toe op workloads in plaats van deze te vervangen. Elk SPIFFE-vertrouwensdomein wordt ondersteund door ondertekeningssleutels die functioneren als een certificeringsinstantie, en SPIRE kan een keten vormen met een upstream bedrijfs-CA. Organisaties hebben nog steeds behoefte aan beheerde sleutelceremonies, beschermde rootcertificaten en certificaatzichtbaarheid. Daarom draaien programma's voor workloadidentificatie meestal naast een beheerde PKI.

Hoe lang is een SPIFFE-certificaat (SVID) geldig?

SPIRE geeft X.509 SVID's uit met een standaard geldigheidsduur van één uur, en de SPIRE Agent verlengt deze automatisch voordat ze verlopen. De geldigheidsduur kan tot op de minuut nauwkeurig worden ingesteld. Omdat de rotatie automatisch verloopt, hoeven workloads nooit handmatig te worden verlengd en werkt een gestolen inloggegeven niet meer binnen de resterende minuten van de geldigheidsduur, in plaats van maandenlang geldig te blijven.

Hoe ondersteunt workload-identificatie Zero Trust?

Zero Trust elimineert impliciet vertrouwen op basis van netwerklocatie en verifieert elk verzoek aan de hand van een identiteit. NIST SP 800-207 definieert deze architectuur, en NIST SP 800-207A noemt SPIFFE de identiteitsinfrastructuur voor cloud-native, multi-cloudomgevingen. De workloadidentiteit levert de verifieerbare service-identiteiten waarop Zero Trust-beleidsengines en wederzijdse TLS vertrouwen, waardoor het model niet alleen voor menselijke gebruikers geldt, maar voor elke machine.

Veranker de werkbelastingidentiteit in de PKI die u beheert.

Ontdek PKI-as-a-Service om uw identiteitsprogramma voor workloads te verankeren in een beheerde, door HSM ondersteunde CA-hiërarchie, of neem contact op met een adviseur van Encryption Consulting om de automatisering van certificaatdetectie en -levenscyclus uit te breiden naar uw clusters met CertSecure Manager. ISO 27001:2022 gecertificeerd en SOC 2-geattesteerd.