Stratégie de sécurité pour les conteneurs confidentiels sur Azure Kubernetes Service
Comme décrit par le Consortium d’informatique confidentielle (CCC), « L’informatique confidentielle est la protection des données utilisées en effectuant des calculs dans un environnement d’exécution de confiance (TEE) attesté et basé sur le matériel. » Les conteneurs confidentiels AKS sont conçus pour protéger les données des pods Kubernetes utilisés contre l’accès non autorisé en dehors de ces pods. Chaque pod s’exécute dans une machine virtuelle utilitaire (UVM) protégée par leTEE AMD SEV-SNP en chiffrant les données utilisées et en empêchant l’accès aux données par le système d’exploitation hôte. Les ingénieurs Microsoft ont collaboré avec les communautés open source Conteneurs confidentiels (CoCo) et Conteneurs Kata sur la conception et l’implémentation des conteneurs confidentiels.
Vue d’ensemble des stratégies de sécurité
L’un des principaux composants de l’architecture système des conteneurs Kata est l’agent Kata. Lorsque vous utilisez des conteneurs Kata pour implémenter des conteneurs confidentiels, l’agent est exécuté à l’intérieur du TEE basé sur le matériel et fait donc partie de la base de calcul de confiance (TCB) du pod. Comme illustré dans le diagramme suivant, l’agent Kata fournit un ensemble d’API de ttrpc permettant aux composants système en dehors du TEE de créer et de gérer des pods Kubernetes basés sur Confidential. Ces autres composants (par exemple, Kata Shim) ne font pas partie du TCB du pod. Par conséquent, l’agent doit se protéger contre les appels d’API potentiellement problématiques ou malveillants.
Dans les conteneurs confidentiels AKS, l’API de l’agent Kata est implémentée à l’aide d’une stratégie de sécurité (également appelée la stratégie d’agent Kata), spécifiée par les propriétaires des pods confidentiels. Le document de stratégie contient des règles et des données correspondant à chaque pod, à l’aide du langage de stratégie Rego standard dans le secteur. L’application de la stratégie à l’intérieur de la machine virtuelle utilitaire est implémentée à l’aide de l’OPA (Open Policy Agent), un projet issu de la Cloud Native Computing Foundation (CNCF).
Contenu de la stratégie
La stratégie de sécurité décrit tous les appels aux API ttrpc de l’agent’(et les paramètres de ces appels d’API) attendus pour la création et la gestion du pod confidentiel. Le document de stratégie de chaque pod est un fichier texte qui utilise le langage Rego. Il existe trois sections générales du document de stratégie.
Données
Les données de stratégie sont spécifiques à chaque pod. Il contient, par exemple :
- Une liste des conteneurs censés être créés dans le pod.
- Une liste des API bloquées par défaut par la stratégie (pour des raisons de confidentialité).
Des exemples de données incluses dans le document de stratégie pour chacun des conteneurs dans un pod :
- Des informations sur l'intégrité des images.
- Les commandes exécutées dans le conteneur.
- Les volumes de stockage et montages.
- Le contexte de sécurité d’exécution. Par exemple, le système de fichiers racine est-il en lecture seule ?
- Le processus est-il autorisé à obtenir de nouveaux privilèges ?
- Variables d'environnement.
- D’autres champs de la configuration de runtime du conteneur OCI (Open Container Initiative).
Règles
Les règles de stratégie, spécifiées au format Rego, sont exécutées par OPA pour chaque appel d’API de l’agent Kata en dehors de la machine virtuelle utilitaire. L’agent fournit toutes les entrées d’API à OPA, qui utilise les règles pour vérifier si les entrées sont cohérentes avec les données de stratégie. Si les règles de stratégie et les données n’autorisent pas les entrées d’API, l’agent rejette l’appel d’API en retournant un message d’erreur « bloqué par stratégie ». Voici d’autres exemples de règles :
- Chaque couche de conteneur est exposée en tant que périphérique de bloc virtio en lecture seule de la machine virtuelle utilitaire. L’intégrité de ces appareils de bloc est protégée à l’aide de la technologie dm-verity du noyau Linux. La valeur racine attendue de l’arborescence de hachage dm-verity est incluse dans les données de stratégie et vérifiée lors de l’exécution par les règles de stratégie.
- Les règles rejettent la création du conteneur lorsqu’une ligne de commande, un montage de stockage, un contexte de sécurité d’exécution ou une variable d’environnement inattendu est détecté.
Par défaut, les règles de stratégie sont communes à tous les pods. L’outil genpolicy génère les données de stratégie et est spécifique à chaque pod.
Valeurs par défaut
Lors de l’évaluation des règles Rego à l’aide des données de stratégie et des entrées d’API en tant que paramètres, OPA tente de trouver au moins un ensemble de règles qui retourne une valeur true en fonction des données d’entrée. Si les règles ne retournent pas true, OPA retourne à l’agent la valeur par défaut de cette API. Exemples de valeurs par défaut de la stratégie :
default CreateContainerRequest := false: signifie que n’importe quel appel d’API CreateContainer est rejeté, sauf si un ensemble de règles de stratégie autorise explicitement cet appel.default GuestDetailsRequest := true: signifie que les appels de l’extérieur du TEE à l’API GuestDetails sont toujours autorisés, car les données retournées par cette API ne sont pas sensibles en termes de confidentialité des charges de travail client.
Envoi de la stratégie à l’agent Kata
Toutes les machines virtuelles utilitaires de conteneurs confidentiels AKS démarrent à l’aide d’une stratégie générique par défaut incluse dans le système de fichiers racine de la machine virtuelle utilitaire. Par conséquent, une stratégie qui correspond à la charge de travail réelle du client doit être fournie à l’agent au moment de l’exécution. Le texte de stratégie est incorporé dans votre fichier manifeste YAML, comme décrit précédemment, et est fourni de cette façon à l’agent au début de l’initialisation de la machine virtuelle utilitaire. L’annotation de stratégie transite par les composants kubelet, containerd et Kata shim du système de conteneurs confidentiels AKS. Ensuite, l’agent travaillant avec OPA applique la stratégie pour tous les appels à ses propres API.
La stratégie est fournie à l’aide de composants qui ne font pas partie de votre TCB. Par conséquent, cette stratégie n’est pas approuvée initialement. Le degré de confiance de la stratégie doit être établi via l’attestation distante, comme décrit dans la section suivante.
Établir la confiance dans le document de stratégie
Avant de créer la machine virtuelle utilitaire, le Kata shim calcule le hachage SHA256 du document de stratégie et attache cette valeur de hachage au TEE. Cette action crée une liaison forte entre le contenu de la stratégie et la machine virtuelle utilitaire. Ce champ TEE n’est pas modifiable ultérieurement par le logiciel exécuté à l’intérieur de la machine virtuelle utilitaire ou en dehors de celle-ci.
Lors de la réception de la stratégie, l’agent vérifie que le hachage de la stratégie correspond au champ TEE immuable. L’agent rejette la stratégie entrante s’il détecte une incompatibilité de hachage.
Avant de gérer des informations sensibles, vos charges de travail doivent effectuer des étapes d’attestation à distance pour prouver à toute partie de confiance que la charge de travail est exécutée à l’aide des versions attendues du TEE, du système d’exploitation, de l’agent, de l’OPA et des versions du système de fichiers racine. L’attestation est implémentée dans un conteneur exécuté à l’intérieur de la machine virtuelle utilitaire qui obtient des preuves d’attestation signées à partir du matériel AMD SEV-SNP. L’un des champs de la preuve d’attestation est le champ TEE de hachage de stratégie décrit précédemment. Par conséquent, le service d’attestation peut vérifier l’intégrité de la stratégie, en comparant la valeur de ce champ au hachage attendu de la stratégie de pod.
Application de la stratégie
L’agent Kata est responsable de l’application de la stratégie. Microsoft a contribué au code de l’agent de la communauté Kata et CoCo, responsable de la vérification de la stratégie pour chaque appel d’API ttrpc de l’agent. Avant d’effectuer les actions correspondant à l’API, l’agent utilise l’API REST OPA pour vérifier si les règles de stratégie et les données autorisent ou bloquent l’appel.