Säkerhetsprincip för konfidentiella containrar i Azure Kubernetes Service
Som beskrivs av Confidential Computing Consortium (CCC) är "Konfidentiell databehandling skyddet av data som används genom att utföra beräkningen i en maskinvarubaserad, intygad betrodd körningsmiljö (TEE)." AKS Konfidentiella containrar är utformade för att skydda Kubernetes podddata som används från obehörig åtkomst utanför dessa poddar. Varje podd körs i en virtuell verktygsdator (UVM) som skyddas av AMD SEV-SNP TEE genom att kryptera data som används och förhindra åtkomst till data av värdoperativsystemet (OS). Microsofts tekniker samarbetade med communityn Konfidentiella containrar (CoCo) och Kata Containers med öppen källkod om utformning och implementering av konfidentiella containrar.
Översikt över säkerhetsprincip
En av huvudkomponenterna i Kata Containers-systemarkitekturen är Kata-agenten. När du använder Kata Containers för att implementera konfidentiella containrar körs agenten i den maskinvarubaserade TEE:en och är därför en del av poddens TCB (Trusted Computing Base). Som du ser i följande diagram tillhandahåller Kata-agenten en uppsättning ttrpc-API :er som gör att systemkomponenterna utanför TEE kan skapa och hantera konfidentiellt baserade Kubernetes-poddar. Dessa andra komponenter (till exempel Kata Shim) ingår inte i poddens TCB. Agenten måste därför skydda sig mot potentiellt buggiga eller skadliga API-anrop.
I AKS Konfidentiella containrar implementeras Kata-agent-API:ets självskydd med hjälp av en säkerhetsprincip (även kallad Kata Agent-principen), som anges av ägarna till de konfidentiella poddarna. Principdokumentet innehåller regler och data som motsvarar varje podd med hjälp av branschstandarden Rego-principspråk. Tillämpningen av principen i den virtuella datorn för verktyg (UVM) implementeras med hjälp av Open Policy Agent (OPA) – ett examensprojekt av Cloud Native Computing Foundation (CNCF).
Principinnehåll
Säkerhetsprincipen beskriver alla anrop till agentens ttrpc-API:er (och parametrarna för dessa API-anrop) som förväntas för att skapa och hantera den konfidentiella podden. Principdokumentet för varje podd är en textfil med språket Rego. Det finns tre avsnitt på hög nivå i principdokumentet.
Data
Principdata är specifika för varje podd. Den innehåller till exempel:
- En lista över containrar som förväntas skapas i podden.
- En lista över API:er som blockeras av principen som standard (av sekretessskäl).
Exempel på data som ingår i principdokumentet för var och en av containrarna i en podd:
- Information om bildintegritet.
- Kommandon som körs i containern.
- Lagringsvolymer och monteringar.
- Körningssäkerhetskontext. Är rotfilsystemet till exempel skrivskyddat?
- Tillåts processen att få nya privilegier?
- Miljövariabler.
- Andra fält från OCI-konfigurationen (Open Container Initiative).
Regler
Principreglerna, som anges i Rego-format, körs av OPA för varje Kata-agent-API-anrop utanför den virtuella verktygsdatorn (UVM). Agenten tillhandahåller alla API-indata till OPA och OPA använder reglerna för att kontrollera om indata är konsekventa med principdata. Om principreglerna och data inte tillåter API-indata avvisar agenten API-anropet genom att returnera felmeddelandet "blockerad av princip". Här följer några regelexempel:
- Varje containerlager exponeras som en skrivskyddad virtio-blockenhet för den virtuella verktygsdatorn (UVM). Integriteten för dessa blockenheter skyddas med hjälp av dm-verity-tekniken i Linux-kerneln. Det förväntade rotvärdet för dm-verity-hashträdet ingår i principdata och verifieras vid körning av principreglerna.
- Regler avvisar skapande av container när en oväntad kommandorad, lagringsmontering, körningssäkerhetskontext eller miljövariabel identifieras.
Som standard är principregler gemensamma för alla poddar. Genpolicy-verktyget genererar principdata och är specifikt för varje podd.
Standardvärden
När du utvärderar Rego-reglerna med hjälp av principdata och API-indata som parametrar försöker OPA hitta minst en uppsättning regler som returnerar ett true värde baserat på indata. Om reglerna inte returnerar truereturnerar OPA standardvärdet för api:et till agenten. Exempel på standardvärden från principen:
default CreateContainerRequest := false– innebär att alla CreateContainer API-anrop avvisas om inte en uppsättning principregler uttryckligen tillåter det anropet.default GuestDetailsRequest := true– innebär att anrop utanför TEE till GuestDetails-API:et alltid tillåts eftersom de data som returneras av det här API:et inte är känsliga för konfidentialitet för kundens arbetsbelastningar.
Skicka principen till Kata-agenten
Alla virtuella aks-datorer (Confidential Container Utility VM) startas med hjälp av en allmän standardprincip som ingår i rotfilsystemet För virtuell verktygsdator (UVM). Därför måste en princip som matchar den faktiska kundarbetsbelastningen tillhandahållas till agenten vid körning. Principtexten bäddas in i YAML-manifestfilen enligt beskrivningen tidigare och tillhandahålls på det här sättet till agenten tidigt under initieringen av den virtuella verktygsdatorn (UVM). Principanteckningen överförs genom komponenterna kubelet, containerd och Kata shim i AKS Confidential Containers-systemet. Sedan tillämpar agenten som arbetar tillsammans med OPA principen för alla anrop till sina egna API:er.
Principen tillhandahålls med hjälp av komponenter som inte ingår i din TCB, så till en början är den här principen inte betrodd. Principens tillförlitlighet måste upprättas via fjärrattestering, enligt beskrivningen i följande avsnitt.
Upprätta förtroende för principdokumentet
Innan du skapar den virtuella verktygsdatorn (UVM) beräknar Kata shim SHA256-hashen för policydokumentet och bifogar det hashvärdet till TEE. Den åtgärden skapar en stark bindning mellan innehållet i principen och den virtuella nyttodatorn (UVM). Det här TEE-fältet kan inte ändras senare av antingen programvaran som körs i den virtuella verktygsdatorn (UVM) eller utanför den.
När principen tas emot verifierar agenten att principens hash matchar det oföränderliga TEE-fältet. Agenten avvisar den inkommande principen om den identifierar ett hash-matchningsfel.
Innan du hanterar känslig information måste dina arbetsbelastningar utföra fjärrattesteringssteg för att bevisa för alla förlitande parter att arbetsbelastningen körs med hjälp av de förväntade versionerna av TEE-, OS-, agent-, OPA- och rotfilsystemversionerna. Attestering implementeras i en container som körs i den virtuella datorverktyget (UVM) som hämtar signerade attesteringsbevis från AMD SEV-SNP-maskinvaran. Ett av fälten från attesteringsbeviset är det principhash-TEE-fält som beskrevs tidigare. Därför kan attesteringstjänsten verifiera principens integritet genom att jämföra värdet för det här fältet med poddprincipens förväntade hash.
Principframtvingande
Kata-agenten ansvarar för att tillämpa principen. Microsoft bidrog till Kata- och CoCo-communityn agentkoden som ansvarar för att kontrollera principen för varje agent ttrpc API-anrop. Innan du utför de åtgärder som motsvarar API:et använder agenten OPA REST API för att kontrollera om principreglerna och data tillåter eller blockerar anropet.