Hoe authenticeert Workload Identity services binnen een AI-stack voor thuis?
Workloadidentiteit authenticeert lokale AI-services door kortlevende cryptografische referenties te koppelen aan een geattesteerd proces, in plaats van aan een netwerkadres of opgeslagen wachtwoord.
Een lokale RAG-API, modelserver, vectordatabank en gateway voor agenttools kunnen één thuisnetwerk delen, terwijl hun rechten sterk kunnen verschillen. Met workloadidentiteit kan elk proces bewijzen welke goedgekeurde service het is voordat het data of referenties ontvangt. De verifier controleert runtime-bewijs, geeft een benoemde identiteit uit en laat resourceautorisatie over aan een afzonderlijke beleidsbeslissing.
Attestatie koppelt een actief proces aan een gedeclareerde identiteit
Een identiteitsagent observeert verifieerbare runtime-eigenschappen, zoals serviceaccount, uitvoerbaar bestand, containerimage, namespace, host of ondertekende workloadmetadata. Registratiebeleid koppelt een geaccepteerde combinatie aan een stabiele servicenaam, in plaats van te vertrouwen op een zelfverklaard label.
Een praktische demonstratie van runtime-workloadattestatie laat zien hoe SPIFFE en SPIRE workloads attesteren voordat ze identiteiten uitgeven binnen een homelab. Het bootstrapvertrouwen ligt in het node- en registratieproces, niet in een geheim dat naar elke container wordt gekopieerd.
Hierdoor verandert de eerste authenticatievraag van “welk IP-adres heeft verbinding gemaakt?” in “welke goedgekeurde workload heeft bewezen deze identiteit te bezitten?” Dynamische adressen en herstarts van containers vereisen niet langer een nieuwe statische referentie. Dit onderscheid blijft zichtbaar tijdens latere tests in huis.
De identiteitsautoriteit geeft kortlevende verifieerbare referenties uit
Na attestatie geeft een autoriteit een X.509- of JWT-referentie uit met de workloadidentifier en een beperkte geldigheidsduur. De lokale agent levert deze via een beschermde workloadinterface en roteert hem voordat hij verloopt. Het tussenresultaat moet controleerbaar blijven voordat automatisering erop voortbouwt.
Een overzicht van kortlevende workloadreferenties legt uit dat SPIFFE-identiteiten kortlevend en cryptografisch verifieerbaar zijn, waardoor de afhankelijkheid van hardgecodeerde servicesecrets afneemt. De ontvangende service valideert uitgever, doelgroep, tijd en het bewijs van sleutelbezit. Die grens moet afzonderlijk worden gemeten onder realistische gebruiksomstandigheden.
Korte geldigheidsduren beperken de blootstelling nadat een service is verwijderd of gecompromitteerd. Rotatie moet automatisch blijven, omdat verlopen certificaten de toegang standaard moeten weigeren in plaats van beheerders aan te moedigen langlevende sleutels te herstellen. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen strijden om beperkte context.
Authenticatie levert identiteit, maar beleid verleent toegang
Een geldige workloadidentiteit bewijst welke service de aanroep doet; het bewijst niet dat de modelserver elke collectie mag lezen of dat een agent namens een bepaalde gebruiker handelt. Autorisatie evalueert identiteit plus resource, bewerking, gebruikersdelegatie en huidig beleid.
Een analyse van workload- en agentidentiteit onderscheidt workloadidentiteit, wederzijdse authenticatie en de gebruikers- of agentcontext die boven de verbinding wordt meegestuurd. Die scheiding voorkomt dat een vertrouwd servicecertificaat een universele bevoegdheid wordt. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.
De foutgrens ligt bij een gecompromitteerde identiteitsautoriteit, node-attestor of registratieregel. Cryptografisch bewijs dwingt getrouw de identiteit af die is uitgegeven, zelfs wanneer het uitgiftebeleid een door een aanvaller beheerd proces aan de verkeerde service heeft gekoppeld.
Volg één serviceaanroep van attestatie tot autorisatie
Kies een verzoek van RAG naar vectordatastore en leg de workloadselector, geregistreerde identiteit, uitgever, geldigheidsduur van certificaat of token, sleutellocatie, peervalidatie, gevraagde resource, gedelegeerde gebruiker, beleidsbeslissing, rotatie, intrekking en auditidentifier vast. Het resultaat moet daarom worden gecontroleerd aan de hand van het oorspronkelijke bewijs.
Vergelijk de controle met AI-identiteitscontroles. Test een legitieme herstart, gekopieerde referentie, niet-geregistreerde container, verkeerde doelgroep, verlopen identiteit, gewijzigd serviceaccount en een geldige identiteit die een verboden collectie opvraagt. Dit onderscheid blijft zichtbaar tijdens latere tests in huis.
Slaag alleen wanneer authentieke workloads automatisch opnieuw verbinding maken en elke imitatie of overschrijding van bevoegdheden faalt op een benoemde grens. Bescherm de identiteitsautoriteit afzonderlijk en houd resourceautorisatie beperkter dan serviceauthenticatie. Het tussenresultaat moet controleerbaar blijven voordat automatisering erop voortbouwt.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Welke invloed heeft downsampling van tijdreeksen op anomaliedetectie in een slimme woning?
Ontdek hoe bucketbreedte, aggregatie, anti-aliasing, ontbrekende gegevens, gebeurtenisduur en retentie op meerdere schalen de detectie van afwijkingen in slimme woningen beïnvloeden.
Hoe combineert een bezettingsraster zwakke signalen van een slim huis?
Leer hoe ruimtelijke cellen, sensormodellen, log-odds-updates, verval, gecorreleerd bewijs en drempelwaarden zwakke signalen uit huis omzetten in bezettingsschattingen.
Hoe beïnvloedt fotometrische normalisatie het clusteren van privégezichten?
Bekijk hoe verlichtingscorrectie gezichtscrops, embeddings, clust afstanden, drempelwaarden, overnormalisatie en de evaluatie van privéfotozoekopdrachten verandert.
