Vertrouwelijke containers (preview) met Azure Kubernetes Service (AKS)

Vertrouwelijke containers bieden een set functies en mogelijkheden om uw standaardcontainerworkloads verder te beveiligen om hogere doelstellingen voor gegevensbeveiliging, gegevensprivacy en runtimecode-integriteit te bereiken. Azure Kubernetes Service (AKS) bevat vertrouwelijke containers (preview) op AKS.

Confidential Containers is gebaseerd op Kata Confidential Containers en op hardware gebaseerde versleuteling om het containergeheugen te versleutelen. Er wordt een nieuw niveau van vertrouwelijkheid van gegevens vastgesteld door te voorkomen dat gegevens in het geheugen tijdens de berekening in duidelijke tekst, leesbare indeling zijn. Vertrouwen wordt verdiend in de container via hardwareverklaring, waardoor toegang tot de versleutelde gegevens wordt toegestaan door vertrouwde entiteiten.

Samen met Pod Sandboxing kunt u gevoelige workloads die zijn geïsoleerd in Azure uitvoeren om uw gegevens en workloads te beveiligen. Wat maakt een container vertrouwelijk:

• Transparantie: de vertrouwelijke containeromgeving waarin uw gevoelige toepassing wordt gedeeld, kunt u zien en controleren of deze veilig is. Alle onderdelen van de Trusted Computing Base (TCB) zijn open source.
• Controlebaarheid: u hebt de mogelijkheid om te controleren welke versie van het CoCo-omgevingspakket, inclusief linux-gastbesturingssystemen en alle onderdelen actueel zijn. Microsoft meldt zich aan bij het gast-besturingssysteem en de runtime-omgeving van de container voor verificaties via attestation. Er wordt ook een beveiligd hash-algoritme (SHA) van gastbesturingssystemen uitgebracht voor het bouwen van een tekenreeks- en controleverhaal.
• Volledige attestation: alles wat deel uitmaakt van het TEE, wordt volledig gemeten door de CPU met de mogelijkheid om extern te verifiëren. Het hardwarerapport van DE AMD SEV-SNP-processor weerspiegelt containerlagen en containerruntimeconfiguratie-hash via de attestation-claims. De toepassing kan het hardwarerapport lokaal ophalen, inclusief het rapport dat de installatiekopieën van het gastbesturingssystem en de containerruntime weerspiegelt.
• Code-integriteit: runtime-afdwinging is altijd beschikbaar via door de klant gedefinieerde beleidsregels voor containers en containerconfiguratie, zoals onveranderbaar beleid en containerondertekening.
• Isolatie van operator: Beveiligingsontwerpen die uitgaan van minimale bevoegdheden en de hoogste isolatieafscherming van alle niet-vertrouwde partijen, inclusief klant-/tenantbeheerders. Het omvat het beperken van bestaande Kubernetes-toegang tot besturingsvlak (kubelet) tot vertrouwelijke pods.

Met andere beveiligingsmaatregelen of besturingselementen voor gegevensbescherming, als onderdeel van uw algehele architectuur, helpen deze mogelijkheden u te voldoen aan wettelijke, branche- of governancenalevingsvereisten voor het beveiligen van gevoelige informatie.

In dit artikel krijgt u inzicht in de functie Vertrouwelijke containers en leert u hoe u het volgende implementeert en configureert:

• Een AKS-cluster implementeren of upgraden met behulp van de Azure CLI
• Een aantekening toevoegen aan uw pod YAML om de pod te markeren als een vertrouwelijke container
• Een beveiligingsbeleid toevoegen aan uw pod YAML
• Afdwingen van het beveiligingsbeleid inschakelen
• Uw toepassing implementeren in Confidential Computing

Ondersteunde scenario's

Vertrouwelijke containers (preview) zijn geschikt voor implementatiescenario's waarbij gevoelige gegevens zijn betrokken. Bijvoorbeeld persoonsgegevens (PII) of gegevens met sterke beveiliging die nodig zijn voor naleving van regelgeving. Enkele veelvoorkomende scenario's met containers zijn:

• Voer big data-analyses uit met Behulp van Apache Spark voor het herkennen van fraudepatronen in de financiële sector.
• Zelf-hostende GitHub-runners uitvoeren om code veilig te ondertekenen als onderdeel van CI/CD DevOps-procedures (Continuous Integration and Continuous Deployment).
• Machine Learning-deductie en training van ML-modellen met behulp van een versleutelde gegevensset van een vertrouwde bron. Het ontsleutelt alleen in een vertrouwelijke containeromgeving om de privacy te behouden.
• Het bouwen van big data clean rooms for ID matching as part of multi-party computation in industries like retail with digital advertising.
• Het bouwen van vertrouwelijke computing Zero Trust-landingszones om te voldoen aan privacyvoorschriften voor toepassingsmigraties naar de cloud.

Overwegingen

Hier volgen overwegingen met deze preview van Vertrouwelijke containers:

• Een toename van de opstarttijd van pods vergeleken met runc-pods en kernel-geïsoleerde pods.
• Containerinstallatiekopieën van versie 1 worden niet ondersteund.
• Updates voor geheimen en ConfigMaps worden niet weergegeven in de gast.
• Tijdelijke containers en andere probleemoplossingsmethoden, zoals exec in een container, logboekuitvoer van containers, en stdio (ReadStreamRequest en WriteStreamRequest) vereisen een beleidswijziging en opnieuw implementeren.
• Het hulpprogramma voor beleidsgenerator biedt geen ondersteuning voor cronjob-implementatietypen.
• Omdat containerinstallatiekopieënlaagmetingen worden gecodeerd in het beveiligingsbeleid, raden we u niet aan de tag te gebruiken bij het latest opgeven van containers.
• Services, Load Balancers en EndpointSlices ondersteunen alleen het TCP-protocol.
• Alle containers in alle pods op de clusters moeten worden geconfigureerd voor imagePullPolicy: Always.
• De beleidsgenerator ondersteunt alleen pods die gebruikmaken van IPv4-adressen.
• ConfigMaps en geheimenwaarden kunnen niet worden gewijzigd als de instelling met behulp van de methode omgevingsvariabele nadat de pod is geïmplementeerd. Het beveiligingsbeleid voorkomt dit.
• Logboeken voor podbeëindiging worden niet ondersteund. Hoewel pods beëindigingslogboeken schrijven naar /dev/termination-log of naar een aangepaste locatie als deze zijn opgegeven in het podmanifest, kan de host/kubelet deze logboeken niet lezen. Wijzigingen van gast naar dat bestand worden niet weergegeven op de host.

Overzicht van resourcetoewijzing

Het is belangrijk dat u begrijpt wat het geheugen- en processorresourcetoewijzingsgedrag is in deze release.

• CPU: De shim wijst één vCPU toe aan het basis-besturingssysteem in de pod. Als er geen resource limits is opgegeven, hebben de workloads geen afzonderlijke CPU-shares toegewezen, wordt de vCPU vervolgens gedeeld met die workload. Als ER CPU-limieten zijn opgegeven, worden CPU-shares expliciet toegewezen voor workloads.
• Geheugen: De Kata-CC-handler gebruikt 2 GB geheugen voor het UVM-besturingssysteem en X MB extra geheugen waarbij X de resource limits is als deze is opgegeven in het YAML-manifest (wat resulteert in een VM van 2 GB wanneer er geen limiet wordt gegeven, zonder impliciet geheugen voor containers). De Kata-handler maakt gebruik van 256 MB basisgeheugen voor het UVM OS en X MB extra geheugen wanneer de resource limits is opgegeven in het YAML-manifest. Als limieten niet zijn opgegeven, wordt een impliciete limiet van 1792 MB toegevoegd, wat resulteert in een virtuele machine van 2 GB en 1792 MB impliciet geheugen voor containers.

In deze release worden resourceaanvragen in de podmanifesten niet ondersteund. De Kata-container negeert resourceaanvragen van het YAML-manifest voor pods en als gevolg hiervan worden de aanvragen niet doorgegeven aan de shim. Gebruik resource limit in plaats van resource requests om geheugen- of CPU-resources toe te wijzen voor workloads of containers.

Met het lokale containerbestandssysteem dat wordt ondersteund door VM-geheugen, kan het schrijven naar het containerbestandssysteem (inclusief logboekregistratie) het beschikbare geheugen dat aan de pod wordt verstrekt, vullen. Deze voorwaarde kan leiden tot potentiële podcrashes.

Volgende stappen

• Zie het overzicht van het beveiligingsbeleid vertrouwelijke containers voor meer informatie over hoe workloads en hun gegevens in een pod worden beveiligd.
• Implementeer vertrouwelijke containers op AKS met een standaardbeveiligingsbeleid.
• Meer informatie over Azure Dedicated-hosts voor knooppunten met uw AKS-cluster voor het gebruik van hardware-isolatie en controle over onderhoudsgebeurtenissen van het Azure-platform.