Beveiligingsbeleid voor vertrouwelijke containers in Azure Kubernetes Service
Zoals beschreven door het Confidential Computing Consortium (CCC), is Confidential Computing de beveiliging van gegevens die worden gebruikt door berekeningen uit te voeren in een hardwaregebaseerde, geteste TRUSTED Execution Environment (TEE)." Vertrouwelijke AKS-containers zijn ontworpen om Kubernetes-pods te beschermen tegen onbevoegde toegang van buiten deze pods. Elke pod wordt uitgevoerd in een vertrouwelijke virtuele machine (CVM) die wordt beveiligd door de AMD SEV-SNP TEE door gegevens in gebruik te versleutelen en toegang tot de gegevens te voorkomen door het hostbesturingssysteem (OS). Microsoft-technici hebben samengewerkt met de opensource-community's Confidential Containers (CoCo) en Kata Containers voor het ontwerp en de implementatie van vertrouwelijke containers.
Overzicht van beveiligingsbeleid
Een van de belangrijkste onderdelen van de Kata Containers-systeemarchitectuur is de Kata-agent. Wanneer u Kata Containers gebruikt om vertrouwelijke containers te implementeren, wordt de agent uitgevoerd in de hardwaregebaseerde TEE en maakt deze daarom deel uit van de Trusted Computing Base (TCB) van de pod. Zoals in het volgende diagram wordt weergegeven, biedt de Kata-agent een set ttrpc-API's waarmee de systeemonderdelen buiten de TEE Kubernetes-pods op basis van CVM kunnen maken en beheren. Deze andere onderdelen (bijvoorbeeld de Kata Shim) maken geen deel uit van de TCB van de pod. Daarom moet de agent zichzelf beschermen tegen mogelijk buggy- of schadelijke API-aanroepen.
In AKS Confidential Containers wordt self-protection van de Kata-agent-API geïmplementeerd met behulp van een beveiligingsbeleid (ook wel kata-agentbeleid genoemd), opgegeven door de eigenaren van de vertrouwelijke pods. Het beleidsdocument bevat regels en gegevens die overeenkomen met elke pod, met behulp van de industriestandaard Rego-beleidstaal. Het afdwingen van het beleid in de CVM wordt geïmplementeerd met behulp van de Open Policy Agent (OPA) – een gegradeerd project van de Cloud Native Computing Foundation (CNCF).
Beleidsinhoud
Het beveiligingsbeleid beschrijft alle aanroepen naar de ttrpc-API's van de agent (en de parameters van deze API-aanroepen) die worden verwacht voor het maken en beheren van de vertrouwelijke pod. Het beleidsdocument van elke pod is een tekstbestand met behulp van de Rego-taal. Er zijn drie secties op hoog niveau van het beleidsdocument.
Gegevens
De beleidsgegevens zijn specifiek voor elke pod. Het bevat bijvoorbeeld:
- Er wordt verwacht dat er een lijst met containers wordt gemaakt in de pod.
- Een lijst met API's die standaard door het beleid worden geblokkeerd (om vertrouwelijkheidsredenen).
Voorbeelden van gegevens die zijn opgenomen in het beleidsdocument voor elk van de containers in een pod:
- Informatie over afbeeldingsintegriteit.
- Opdrachten die worden uitgevoerd in de container.
- Opslagvolumes en koppels.
- Beveiligingscontext voor uitvoering. Is het hoofdbestandssysteem bijvoorbeeld alleen-lezen?
- Mag het proces nieuwe bevoegdheden krijgen?
- Omgevingsvariabelen.
- Andere velden uit de configuratie van de OCI-containerruntime (Open Container Initiative).
Regels
De beleidsregels, die zijn opgegeven in de Rego-indeling, worden uitgevoerd door OPA voor elke Kata-agent-API-aanroep van buiten de CVM. De agent biedt alle API-invoer voor OPA en OPA gebruikt de regels om te controleren of de invoer consistent is met beleidsgegevens. Als de beleidsregels en gegevens geen API-invoer toestaan, weigert de agent de API-aanroep door een foutbericht 'geblokkeerd door beleid' te retourneren. Hier volgen enkele regelvoorbeelden:
- Elke containerlaag wordt weergegeven als een alleen-lezen virtio-blokapparaat voor de CVM. De integriteit van deze blokapparaten wordt beveiligd met behulp van de dm-verity-technologie van de Linux-kernel. De verwachte hoofdwaarde van de dm-verity-hashstructuur wordt opgenomen in de beleidsgegevens en gecontroleerd tijdens runtime door de beleidsregels.
- Regels weigeren het maken van containers wanneer een onverwachte opdrachtregel, opslagkoppeling, uitvoeringsbeveiligingscontext of omgevingsvariabele wordt gedetecteerd.
Standaard zijn beleidsregels gebruikelijk voor alle pods. Het hulpprogramma genpolicy genereert de beleidsgegevens en is specifiek voor elke pod.
Standaardwaarden
Bij het evalueren van de Rego-regels met behulp van de beleidsgegevens en API-invoer als parameters, probeert OPA ten minste één set regels te vinden die een true waarde retourneert op basis van de invoergegevens. Als de regels niet worden geretourneerd true, retourneert OPA de standaardwaarde voor die API naar de agent. Voorbeelden van standaardwaarden uit het beleid:
default CreateContainerRequest := false– betekent dat elke CreateContainer-API-aanroep wordt geweigerd, tenzij een set beleidsregels die aanroep expliciet toestaat.default GuestDetailsRequest := true– betekent dat aanroepen van buiten de TEE naar de GuestDetails-API altijd zijn toegestaan omdat de gegevens die door deze API worden geretourneerd, niet gevoelig zijn voor vertrouwelijkheid van de workloads van de klant.
Het beleid verzenden naar Kata-agent
Alle AKS Confidential Containers CVM's worden gestart met behulp van een algemeen, standaardbeleid dat is opgenomen in het basisbestandssysteem van de CVM's. Daarom moet een beleid dat overeenkomt met de werkelijke workload van de klant, tijdens runtime aan de agent worden verstrekt. De beleidstekst wordt ingesloten in het YAML-manifestbestand zoals eerder is beschreven en wordt op deze manier aan de agent geleverd tijdens de cvm-initialisatie. De beleidsaantekening gaat door de kubelet-, container-, en Kata-shim-onderdelen van het AKS Confidential Containers-systeem. Vervolgens dwingt de agent die samenwerkt met OPA het beleid af voor alle aanroepen naar zijn eigen API's.
Het beleid wordt geleverd met behulp van onderdelen die geen deel uitmaken van uw TCB, dus in eerste instantie wordt dit beleid niet vertrouwd. De betrouwbaarheid van het beleid moet worden vastgesteld via Remote Attestation, zoals beschreven in de volgende sectie.
Vertrouwensrelatie tot stand brengen in het beleidsdocument
Voordat u de Pod CVM maakt, berekent de Kata-shim de SHA256-hash van het beleidsdocument en koppelt deze hashwaarde aan de TEE. Deze actie maakt een sterke binding tussen de inhoud van het beleid en de CVM. Dit TEE-veld kan later niet meer worden gewijzigd door de software die wordt uitgevoerd in de CVM of erbuiten.
Na ontvangst van het beleid controleert de agent of de hash van het beleid overeenkomt met het onveranderbare TEE-veld. De agent weigert het binnenkomende beleid als een hash niet overeenkomt.
Voordat u gevoelige informatie verwerkt, moeten uw workloads externe Attestation-stappen uitvoeren om te bewijzen dat de workload wordt uitgevoerd met behulp van de verwachte versies van de TEE-, OS-, agent-, OPA- en hoofdbestandssysteemversies. Attestation wordt geïmplementeerd in een container die wordt uitgevoerd in de CVM die ondertekend attestation-bewijs van de AMD SEV-SNP-hardware verkrijgt. Een van de velden uit het attestation-bewijs is het teE-veld voor beleidshash dat eerder is beschreven. Daarom kan de Attestation-service de integriteit van het beleid verifiëren door de waarde van dit veld te vergelijken met de verwachte hash van het podbeleid.
Beleidsafdwinging
De Kata-agent is verantwoordelijk voor het afdwingen van het beleid. Microsoft heeft bijgedragen aan de Kata- en CoCo-community, de agentcode die verantwoordelijk is voor het controleren van het beleid voor elke ttrpc-API-aanroep van de agent. Voordat de acties worden uitgevoerd die overeenkomen met de API, gebruikt de agent de OPA REST API om te controleren of de beleidsregels en gegevens de aanroep toestaan of blokkeren.