Dela via

Konfidentiella containrar (förhandsversion) med Azure Kubernetes Service (AKS)

  • Artikel

Konfidentiella containrar tillhandahåller en uppsättning funktioner för att ytterligare skydda dina standardcontainerarbetsbelastningar för att uppnå högre datasäkerhet, datasekretess och körningskodintegritetsmål. Azure Kubernetes Service (AKS) innehåller konfidentiella containrar (förhandsversion) på AKS.

Konfidentiella containrar bygger på Kata Confidential Containers och maskinvarubaserad kryptering för att kryptera containerminnet. Den etablerar en ny nivå av datasekretess genom att förhindra att data i minnet under beräkningen är i klartext, läsbart format. Förtroende skapas i containern via maskinvaruattestering, vilket ger åtkomst till krypterade data av betrodda entiteter.

Tillsammans med Pod Sandboxing kan du köra känsliga arbetsbelastningar isolerade i Azure för att skydda dina data och arbetsbelastningar. Vad gör en container konfidentiell:

  • Transparens: Den konfidentiella containermiljö där ditt känsliga program delas kan du se och kontrollera om det är säkert. Alla komponenter i TCB (Trusted Computing Base) ska öppen källkod d.
  • Granskningsbarhet: Du kan verifiera och se vilken version av CoCo-miljöpaketet, inklusive Linux gästoperativsystem och alla komponenter som är aktuella. Microsoft loggar in på gästoperativsystemet och containerkörningsmiljön för verifiering via attestering. Den släpper också en säker hashalgoritm (SHA) av gästoperativsystemversioner för att skapa en stränganvändbarhet och kontrollberättelse.
  • Fullständig attestering: Allt som ingår i TEE ska mätas fullständigt av processorn med möjlighet att fjärrstyra. Maskinvarurapporten från AMD SEV-SNP-processorn ska återspegla containerlager och konfigurationshash för containerkörning via attesteringsanspråken. Programmet kan hämta maskinvarurapporten lokalt, inklusive rapporten som återspeglar gästoperativsystemavbildningen och containerkörningen.
  • Kodintegritet: Körningsframtvingande är alltid tillgängligt via kunddefinierade principer för containrar och containerkonfiguration, till exempel oföränderliga principer och containersignering.
  • Isolering från operatör: Säkerhetsdesign som förutsätter minsta behörighet och högsta isoleringsskärmning från alla ej betrodda parter, inklusive kund-/klientadministratörer. Den innehåller härdning av befintlig Kubernetes-kontrollplansåtkomst (kubelet) till konfidentiella poddar.

Med andra säkerhetsåtgärder eller dataskyddskontroller, som en del av din övergripande arkitektur, hjälper dessa funktioner dig att uppfylla regel-, bransch- eller styrningsefterlevnadskrav för att skydda känslig information.

Den här artikeln hjälper dig att förstå funktionen Konfidentiella containrar och hur du implementerar och konfigurerar följande:

  • Distribuera eller uppgradera ett AKS-kluster med hjälp av Azure CLI
  • Lägg till en anteckning i din podd-YAML för att markera podden som en konfidentiell container
  • Lägga till en säkerhetsprincip i din podd-YAML
  • Aktivera tillämpning av säkerhetsprincipen
  • Distribuera ditt program i konfidentiell databehandling

Stödda scenarier

Konfidentiella containrar (förhandsversion) är lämpliga för distributionsscenarier som omfattar känsliga data. Till exempel personligt identifierbar information (PII) eller data med stark säkerhet som krävs för regelefterlevnad. Några vanliga scenarier med containrar är:

  • Kör stordataanalys med Apache Spark för igenkänning av bedrägerimönster inom finanssektorn.
  • Köra github-löpare med egen värd för att signera kod på ett säkert sätt som en del av CI/CD DevOps-metoder (Continuous Integration and Continuous Deployment).
  • Machine Learning-slutsatsdragning och träning av ML-modeller med hjälp av en krypterad datauppsättning från en betrodd källa. Den dekrypterar bara i en konfidentiell containermiljö för att bevara sekretessen.
  • Skapa stora datarengöringsrum för ID-matchning som en del av flerpartsberäkning i branscher som detaljhandel med digital annonsering.
  • Skapa konfidentiell databehandling Nolltillit landningszoner för att uppfylla sekretessregler för programmigreringar till molnet.

Att tänka på

Följande är överväganden med den här förhandsversionen av Konfidentiella containrar:

  • En ökning av starttiden för poddar jämfört med runc-poddar och kernelisolerade poddar.
  • Version 1-containeravbildningar stöds inte.
  • Uppdateringar av hemligheter och ConfigMaps återspeglas inte i gästen.
  • Tillfälliga containrar och andra felsökningsmetoder som exec till en container, loggutdata från containrar och stdio (ReadStreamRequest och WriteStreamRequest) kräver en principändring och omdistribution.
  • Verktyget principgenerator stöder inte cronjob-distributionstyper.
  • På grund av att mått på containeravbildningsskiktet kodas i säkerhetsprincipen rekommenderar vi inte att du använder taggen latest när du anger containrar.
  • Tjänster, Lastbalanserare och EndpointSlices stöder endast TCP-protokollet.
  • Alla containrar i alla poddar i klustren måste konfigureras till imagePullPolicy: Always.
  • Principgeneratorn stöder endast poddar som använder IPv4-adresser.
  • Det går inte att ändra värden för ConfigMaps och hemligheter om inställningen använder miljövariabelmetoden efter att podden har distribuerats. Säkerhetsprincipen förhindrar det.
  • Loggar för poddavslut stöds inte. Poddar skriver avslutningsloggar till /dev/termination-log eller till en anpassad plats om de anges i poddmanifestet, men värden/kubelet kan inte läsa loggarna. Ändringar från gäst till den filen återspeglas inte på värden.

Översikt över resursallokering

Det är viktigt att du förstår hur minnes- och processorresursallokering fungerar i den här versionen.

  • CPU: Shim tilldelar en vCPU till basoperativsystemet i podden. Om ingen resurs limits anges har arbetsbelastningarna inte separata cpu-resurser tilldelade, vCPU:n delas sedan med den arbetsbelastningen. Om cpu-gränser anges allokeras CPU-resurser uttryckligen för arbetsbelastningar.
  • Minne: Kata-CC-hanteraren använder 2 GB minne för UVM-operativsystemet och X MB extra minne där X är resursen limits om den anges i YAML-manifestet (vilket resulterar i en virtuell dator på 2 GB när ingen gräns anges, utan implicit minne för containrar). Kata-hanteraren använder 256 MB basminne för UVM OS och X MB extra minne när resursen limits anges i YAML-manifestet. Om gränserna är ospecificerade läggs en implicit gräns på 1 792 MB till, vilket resulterar i en virtuell dator på 2 GB och 1 792 MB implicit minne för containrar.

I den här versionen stöds inte att ange resursbegäranden i poddmanifesten. Kata-containern ignorerar resursbegäranden från POD YAML-manifestet och därför skickar containerd inte begäranden till shim. Använd resursen limit i stället för resurs requests för att allokera minne eller CPU-resurser för arbetsbelastningar eller containrar.

Med det lokala containerfilsystemet som backas upp av vm-minnet kan skrivning till containerfilsystemet (inklusive loggning) fylla upp det tillgängliga minne som tillhandahålls till podden. Det här villkoret kan leda till potentiella poddkrascher.

Nästa steg