Identitet för arbetslaster

Ett tjänstkonto är en icke-mänsklig identitet som används av en applikation, tjänst eller automatiserad process för att autentisera sig mot andra tjänster och API:er. Till skillnad från användarkonton hanteras tjänstkonton programmatiskt, är kopplade till en arbetsbelastning snarare än en person, och i moderna system kräver de inte ett lagrat lösenord.

I traditionella miljöer var tjänstkonton associerade med långlivade lösenord eller API-nycklar lagrade i konfigurationsfiler eller miljövariabler. Detta skapade betydande säkerhetsrisk. Uppgifterna var statiska, delades ofta över flera tjänster och miljöer, var svåra att rotera utan att orsaka driftstopp och glömdes lätt i källkod.

I moln- och Kubernetes-miljöer har tjänstkonton utvecklats till att vara lösenordsfria. Molnhanterade tjänstkonton (AWS IAM-roller, GCP-tjänstkonton, Azure Managed Identities) fungerar genom plattformsbaserade mekanismer. Molnplattformen attesterar att en beräkningsresurs körs med en viss identitet och tillhandahåller automatiskt kortlivade uppgifter.

Det vanligaste misstaget med tjänstkonton är att ge dem alltför stora behörigheter. Ett tjänstkonto för en skrivskyddad rapporteringstjänst bör inte ha skrivbehörighet till produktionsdatabasen. Att följa principen om minsta behörighet strikt innebär att skapa ett dedikerat tjänstkonto för varje arbetsbelastning med exakt de behörigheter arbetsbelastningen kräver.

Arbetsbelastningsidentitet är konceptet att tilldela en unik, verifierbar, kryptografiskt stödd identitet till varje körande arbetsbelastning (applikation, tjänst, container eller jobb), snarare än till en person. Denna identitet härleds från egenskaper hos arbetsbelastningens körningsmiljö och attesteras av en betrodd myndighet som molnleverantören eller Kubernetes kontrollplan.

Den viktigaste distinktionen från traditionella tjänstkonton är att arbetsbelastningsidentitet inte bygger på en hemlighet som arbetsbelastningen innehar. En pod som körs i ett specifikt Kubernetes-namnrum med ett specifikt ServiceAccount får en identitet för att Kubernetes API-servern attesterar det faktum och utfärdar en signerad token. Ingen uppgift lagras, identiteten är en egenskap hos driftsättningen.

Tokens för arbetsbelastningsidentitet följer ett gemensamt mönster. Den betrodda myndigheten utfärdar en signerad JSON Web Token (JWT) med anspråk som beskriver arbetsbelastningen. Arbetsbelastningen presenterar denna token för andra tjänster, som validerar signaturen med myndighetens publicerade publika nycklar. Eftersom token är kortlivad och bunden till specifika anspråk kan den inte återanvändas av en angripare efter utgångstiden.

Arbetsbelastningsidentitet är grundläggande för zero trust-arkitekturer. När varje tjänst kryptografiskt kan bevisa sin identitet kan åtkomstkontrollbeslut baseras på 'vilken tjänst gör detta anrop' snarare än 'vilken nätverksadress anropar'. Detta möjliggör säker tjänst-till-tjänst-kommunikation även i platta, delade nätverk.

Identitetsfederation är mekanismen som gör det möjligt för en arbetsbelastning att presentera en identitet från ett system (som Kubernetes eller GitHub Actions) och utbyta den mot uppgifter i ett annat system (som AWS eller GCP), utan att källsystemet behöver lagra några långlivade uppgifter från målsystemet. Federation bygger på ömsesidigt förtroende.

Det vanligaste federationsmönstret i DevSecOps är CI/CD-pipeline till molnleverantör. Ett GitHub Actions-arbetsflöde autentiserar sig mot AWS med OIDC-federation utan att lagra några AWS-uppgifter i GitHub. Arbetsflödet begär en GitHub-utfärdad OIDC-token, presenterar den för AWS STS och tar emot temporära AWS-uppgifter giltiga under jobbets varaktighet.

Federation bygger på öppna standarder. OIDC (OpenID Connect) och SAML är de två dominerande federationsprotokollen. OIDC föredras för modern arbetsbelastningsidentitet eftersom det använder kompakta JWT:er och stöds native av alla stora molnleverantörer och CI/CD-plattformar.

Ett vanligt misstag är att ange alltför breda förtroendekonditioner i federationspolicyer. När man konfigurerar GitHub OIDC-federation med AWS bör team begränsa förtroendet till specifika reposiotorer, specifika grenar och specifika miljöer. En policy som litar på vilket arbetsflöde som helst från vilket repository som helst i en GitHub-organisation innebär att alla bidragsgivare kan få molnuppgifter.

OpenID Connect (OIDC) är ett identitetslager byggt ovanpå OAuth 2.0. I sammanhanget av molnarbetsbelastningsidentitet gör OIDC det möjligt för arbetsbelastningar att autentisera sig mot molntjänster genom att presentera en signerad JWT utfärdad av en betrodd identitetsleverantör (Kubernetes API-servern, GitHub Actions, CircleCI, etc.) och utbyta den mot molnbaserade temporära uppgifter.

Utbytet fungerar på följande sätt. Arbetsbelastningen begär en token från sin lokala OIDC-leverantör, presenterar denna token för molnleverantörens Security Token Service (STS), och molnleverantören validerar tokens signatur med OIDC-leverantörens publicerade publika nycklar. Om giltig utfärdar molnleverantören temporära uppgifter kopplade till den mappade IAM-rollen.

OIDC-tokens bär strukturerade anspråk som beskriver arbetsbelastningen. En Kubernetes pod-token bär anspråk för namnrymden, tjänstkontots namn och podden. En GitHub Actions-token bär anspråk för repositoryt, grenen, arbetsflödets namn och miljön. Moln-IAM-policyer använder dessa anspråk som villkor i förtroendepolicing.

Säkerhetsegenskaperna hos OIDC-federation är starka eftersom tokens är kortlivade, kryptografiskt signerade med kända nycklar och bundna till specifika strukturerade anspråk om arbetsbelastningen. Det finns inga bestående uppgifter att stjäla och återanvända på obestämd tid. Om en token avlyssnas löper den snabbt ut.

Kortlivade uppgifter är autentiseringstokens eller hemligheter som automatiskt löper ut efter en kort period, vanligtvis minuter till timmar. Genom att begränsa uppgifternas livstid begränsar organisationen skadan av stöld av uppgifter. En angripare som erhåller uppgifter som löper ut om 15 minuter har ett mycket smalt fönster att utnyttja dem.

AWS STS, GCPs OAuth-tokentjänst och Azure AD genererar alla temporära uppgifter med konfigurerbara utgångstider. Applikationer som använder dessa tjänster håller aldrig en långlivad uppgift, de begär färska temporära uppgifter vid behov och använder sin arbetsbelastningsidentitet för autentisering. SDK:er för molnleverantörer hanterar detta transparent. De cachelagrar uppgifter och uppdaterar dem proaktivt innan de löper ut.

Den operativa utmaningen med kortlivade uppgifter är hantering av uppdatering. Applikationer måste designas för att erhålla nya uppgifter innan de nuvarande löper ut. De flesta moln-SDK:er hanterar detta transparent för API-anrop, men applikationer som cachelagrar uppgifter på applikationsnivå (som databasanslutningspooler) kan hålla utgångna uppgifter.

Ett vanligt antimönster är att skapa 'långlivade tokens' genom att ange konstlat långa utgångstider på vad som tekniskt sett är en kortlivad uppgiftsmekanism. Team gör ibland detta för att undvika att hantera tokenuppdateringslogik, men detta motverkar syftet. Målet är uppgifter som löper ut på minuter till timmar, inte på ett år.

Principen om minsta behörighet fastslår att varje identitet bara ska ha åtkomst till den minsta uppsättning behörigheter som krävs för dess avsedda funktion. Tillämpad på arbetsbelastningsidentitet innebär detta att varje tjänst får sin egen identitet med exakt de behörigheter den behöver, avgränsade till exakt de resurser den behöver. Alltför privilegierade arbetsbelastningsidentiteter är en av de vanligaste molnsäkerhetsfelkonfiguationerna.

Minsta behörighet i moln-IAM uppnås genom finkorniga policydefinitioner. Istället för att ge en tjänst administratörsrollen eller bred åtkomst till alla resurser i ett konto kan ett korrekt privilegierat tjänstkonto ha behörighet att läsa objekt från ett specifikt S3-bucket-prefix, skriva till en specifik DynamoDB-tabell och publicera till ett specifikt SNS-ämne.

Behörighetsanalysverktyg hjälper team att identifiera och stänga gapet mellan beviljade och faktiskt använda behörigheter. AWS IAM Access Analyzer med sin senast använda information, GCP Policy Analyzer och liknande verktyg analyserar CloudTrail-loggar eller granskningsloggar för att avgöra vilka behörigheter en roll faktiskt utövar i praktiken.

Ett vanligt misstag är att bevilja jokertecknsbehörigheter för att det är enklare än att fastställa de exakta kraven. Att skriva 'Action: *' eller 'Resource: *' i en IAM-policy är en betydande varningssignal. Ett annat vanligt misstag är att bevilja behörigheter på kontonivå när de borde avgränsas till specifika resurser. Båda mönstren skapar mycket mer åtkomst än vad någon enskild arbetsbelastning någonsin borde behöva.