L'informatique confidentielle s'appuie sur un environnement d'exécution de confiance (TEE, Trusted Execution Environnement) pour protéger la mémoire en cours d'utilisation et ainsi garantir le chiffrement des données au repos, en transit et en cours d'utilisation. Le projet Confidential Containers associe les TEE avec les déploiements Kubernetes. Le déploiement d'un TEE au niveau du pod permet de bien isoler les charges de travail, non seulement des autres charges de travail dans le cluster, mais également des administrateurs du cluster.

La prise en main de Confidential Containers n'est pas évidente. Si la décision de déployer un pod dans un conteneur confidentiel ne nécessite que de modifier une ligne du manifeste du pod, il faut cependant réussir à déployer un certain nombre de composants ensemble, idéalement dans plusieurs clusters. Red Hat a récemment annoncé la prise en charge de Confidential Containers sur Microsoft Azure dans la version 1.9 de l'opérateur de conteneurs en sandbox de Red Hat OpenShift et les versions ultérieures, ainsi que la prise en charge de l'attestation à distance avec la version Red Hat de Trustee.

Dans cet article de blog, nous allons voir comment utiliser les modèles validés pour atteindre trois objectifs :

1. Simplifier la prise en main de Confidential Containers avec l'opérateur de conteneurs en sandbox d'OpenShift et de la version Red Hat de Trustee sur Azure
2. Fournir une base cohérente et déclarative pour Confidential Containers afin de permettre le déploiement de meilleures pratiques
3. Apprendre à déployer des applications à l'aide de Confidential Containers

Présentation des modèles validés 

Les modèles validés sont des architectures de code dynamiques adaptées à différents cas d'utilisation des environnements multicloud et de cloud hybride. Chaque modèle est testé et lorsqu'il est suffisamment développé, il est ajouté au système d'intégration continue de Red Hat. Ce processus garantit que les tests sont effectués avec les dernières versions des opérateurs et des versions d'OpenShift, et pour tous les environnements de cloud public.

Chaque référentiel de modèles validés de Red Hat présente un cas d'utilisation métier sous la forme de ressources Kubernetes (charts Helm, Kustomize et objets primitifs), qui décrivent une pile de cloud hybride de manière déclarative et complète, des services à l'infrastructure sous-jacente. Les modèles validés facilitent les déploiements complexes et hautement reproductibles, et sont parfaitement adaptés pour exploiter ces déploiements à grande échelle à l'aide des pratiques GitOps.

Avantages des modèles validés 

Le déploiement de solutions métier complexes implique plusieurs étapes. Chaque étape, si elle est effectuée au hasard, peut engendrer des erreurs ou des inefficacités. Les modèles validés proposent un processus de déploiement prévalidé et automatisé qui offre les avantages suivants :

• Utilisation d'un modèle GitOps pour distribuer le cas d'utilisation sous forme de code
• Utilisation comme preuve de concept modifiée pour répondre à un besoin particulier, avec la possibilité de l'adapter en vue d'un déploiement réel
• Reproductibilité élevée, ce qui en fait un outil idéal pour une exploitation à grande échelle
• Modèles validés ouverts à la collaboration : tout le monde peut suggérer des améliorations, y contribuer ou les utiliser, car tous les référentiels Git sont accessibles en amont
• Possibilité de modifier chaque modèle validé en fonction des besoins : il est aussi simple de remplacer un composant (par exemple, utiliser le système de stockage Ceph au lieu de S3) que d'ajouter un commentaire pour exclure des sections de la configuration et inclure un autre référentiel
• Réalisation de tests : une fois le modèle validé, il est inclus dans le système d'intégration continue de Red Hat et sera testé pour toutes les versions du produit tant qu'il reste actif

Les modèles validés offrent une solution « tout inclus ». Quel que soit le point de départ avec ce framework de modèles, les composants de base et un ensemble de composants configurables sont fournis prêts à l'emploi. Pour les besoins de cet article, un modèle validé a été utilisé afin de créer une méthode simple pour commencer à utiliser Confidential Containers.

Déploiement d'un modèle

Le site web sur les modèles validés propose une documentation complète sur leur utilisation. Voici les éléments de base requis :

1. Un référentiel Git pour le modèle, tel qu'un fork du modèle (les modèles validés suivent les pratiques GitOps, ce qui oblige à contrôler le référentiel utilisé)
2. Un ordinateur portable de développement avec l'outil oc, Git et Podman
3. Un cluster OpenShift vide dans lequel l'opérateur de modèles « gère » le cluster

Voici comment ces éléments interagissent :

Dans cette configuration, le modèle validé « possède » ce qui se trouve dans le cluster, ce qui offre un point de départ unique.

Utilisation de modèles validés pour Confidential Containers

Les conteneurs en sandbox Red Hat OpenShift sont basés sur Kata Containers et offrent des fonctionnalités supplémentaires pour exécuter Confidential Containers. L'architecture de ce projet repose sur des conteneurs déployés dans une enclave matérielle isolée, qui contribue à protéger les données et le code des utilisateurs privilégiés tels que les administrateurs de cloud ou de cluster. Soutenu par la CNCF, le projet Confidential Containers est à la base de la solution de conteneurs confidentiels d'OpenShift.

L'informatique confidentielle permet de protéger les données pendant leur utilisation en exploitant les capacités de solutions matérielles dédiées. Le matériel aide à créer des environnements isolés propriétaires et à les protéger contre les accès ou changements non autorisés apportés aux données des charges de travail pendant leur exécution (données en cours d'utilisation).

Le projet Confidential Containers permet la mise en œuvre d'une stratégie informatique confidentielle et cloud-native qui repose sur plusieurs plateformes matérielles et technologies sous-jacentes. Cette solution vise à standardiser l'informatique confidentielle au niveau du pod et à simplifier son utilisation dans les environnements Kubernetes. Les utilisateurs de Kubernetes peuvent ainsi déployer des charges de travail dans des conteneurs confidentiels à l'aide de workflows et d'outils qu'ils maîtrisent sans avoir à connaître en détail les technologies sous-jacentes d'informatique confidentielle.

Pour en savoir plus, consultez l'article sur la solution de conteneurs confidentiels d'OpenShift. 

Architecture de Confidential Containers 

La solution de conteneurs confidentiels de Red Hat s'appuie sur deux opérateurs clés :

• Conteneurs confidentiels Red Hat OpenShift : fonction ajoutée à l'opérateur de conteneurs en sandbox de Red Hat OpenShift, qui permet de déployer les éléments de base pour connecter les charges de travail (pods) et les machines virtuelles confidentielles qui s'exécutent dans le TEE fourni par le matériel.
• Attestation à distance : la version Red Hat de Trustee se charge du déploiement et de la gestion du service Key Broker Service (KBS) dans un cluster Red Hat OpenShift.

Pour en savoir plus, consultez l'article sur le projet Trustee.

L'architecture de Confidential Containers repose généralement sur deux environnements : une zone fiable et une zone non fiable. Dans ces zones, Trustee et l'opérateur de conteneurs en sandbox sont déployés, respectivement comme suit : 

Quelle est donc la difficulté ? Il est essentiel de connaître les informations et les spécificités de l'infrastructure cloud ou sur site. Il convient de se poser plusieurs questions, par exemple : dans quelle région l'environnement est-il situé ? Quels sont les chipsets (Intel, AMD, IBM Power, s390) ciblés ? 

Pour en savoir plus sur le déploiement de Confidential Containers, consultez l'article sur les éléments à prendre en compte pour la solution de conteneurs confidentiels de Red Hat OpenShift.

Présentation du modèle validé pour les conteneurs confidentiels

L'objectif du modèle validé pour les conteneurs confidentiels est de faciliter la prise en main et de comprendre comment déployer Confidential Containers. Il utilise l'architecture de modèle validé pour réaliser les actions suivantes :

1. Déployer les opérateurs nécessaires à l'exécution de Confidential Containers
2. Configurer les composants périphériques de base, y compris les certificats (à l'aide de Let's Encrypt, si nécessaire)
3. Sécuriser l'utilisateur qui déploie Confidential Containers dans le cluster depuis le cloud à l'aide d'outils tels que Red Hat Advanced Cluster Manager
4. Déployer des exemples d'applications pour présenter diverses fonctions de Confidential Containers, notamment la manipulation de conteneurs confidentiels

Actuellement, le modèle est déployé sur Microsoft Azure dans un seul cluster, et tous les composants proviennent d'un seul modèle validé (d'autres déploiements seront proposés ultérieurement).

Fonctionnement

Nous utilisons l'opérateur de modèles validés pour déployer Argo CD, qui déploie ensuite les opérateurs supplémentaires requis. 

Le problème est que le mappage de configuration pairs-pods, y compris init-data et kata-policy, doit être configuré pour pointer vers leservice KBS de Trustee. Ces informations sont dynamiques, et l'utilisateur doit recourir à l'interface en ligne de commande Azure ou accéder au portail Azure. Du point de vue de la sécurité et de la visibilité, les données init-data et kata-policy sont également problématiques, car elles sont encodées en Base64 avant d'être transférées vers un mappage de configuration, ce qui rend difficile la vérification de la posture par l'utilisateur.

 

Ces problèmes sont résolus grâce à l'utilisation de métadonnées injectées par l'opérateur de modèles validés, permettant d'accéder facilement aux informations sur le cluster dans l'application. Les politiques de gestion avancée du cluster sont utilisées pour recueillir les informations définies par le gestionnaire de contrôleur cloud, et pour les injecter dans les mappages de configuration et les secrets appropriés pour l'opérateur de conteneurs en sandbox.

L'outil Hashicorp Vault est utilisé comme gestionnaire des clés au sein du cluster avec la configuration des secrets des modèles validés, ce qui permet aux utilisateurs de démarrer Vault de manière cohérente à partir d'un environnement de poste de travail de développement. Nous utilisons cette méthode afin de fournir des secrets à Trustee, qui sont synchronisés à l'aide de l'opérateur de secrets externe.

La combinaison de ces fonctionnalités permet d'effectuer l'installation à l'aide d'une seule commande, comme illustré ci-dessous : 

Exigences 

Actuellement, le déploiement est limité à Azure en tant que plateforme avec une topologie de modèle simple, c'est-à-dire un cluster OpenShift unique.

Les utilisateurs peuvent exploiter un cluster Azure Red Hat OpenShift ou un cluster OpenShift autogéré sur Azure. Le modèle inclut de la documentation sur la façon d'utiliser openshift-install pour assembler un cluster. Le cluster et le compte Azure doivent avoir accès aux machines virtuelles confidentielles Azure dans la région correspondante et être en mesure de les utiliser. Aujourd'hui, le modèle suppose l'utilisation de machines virtuelles de classe DCasv5 pour Confidential Containers, mais ce paramètre peut toutefois être personnalisé.

La seule configuration supplémentaire requise pour Azure est le déploiement d'une passerelle NAT pour le sous-réseau du nœud de calcul. Cette opération s'effectue automatiquement.

Le poste de travail de développement doit être de type POSIX (macOS ou Linux) et disposer des outils oc et Podman.

Instructions détaillées

Cette procédure ne comporte que trois étapes.

1. Création d'un fork

Commencez par créer un fork du référentiel GitHub de modèles validés au sein de votre organisation. Notez qu'en raison de la cohérence ultérieure avec Argo CD, l'utilisation directe du référentiel de modèles validés n'est pas sécurisée.

git clone https://github.com/(VOTRE ORG}/coco-pattern.git

2. Génération de clés aléatoires

Générez ensuite les secrets de base. Le modèle inclut des scripts pour générer des clés aléatoires :

sh scripts/gen-secrets.sh

3. Installation

Connectez-vous au cluster à l'aide de la commande oc login, puis exécutez le modèle install :

./pattern.sh make install

C'est terminé ! Attendez que le système soit en ligne, puis explorez les applications déployées.

Exploration des applications déployées

Le modèle déploie une instance Argo CD appelée Simple ArgoCD dans le menu à 9 zones de la console web d'OpenShift. Plusieurs applications sont déployées. Les deux applications essentielles à explorer sont hello-openshift et kbs-access.

L'application hello-openshift déploie une application web trois fois : 

• En tant que pod standard
• En tant que pod kata, où la configuration de l'agent a été volontairement remplacée pour permettre à un utilisateur de procéder à l'exécution dans le pod
• En tant qu'application « sécurisée » avec la fonction de sécurisation de Confidential Containers

L'application kbs-access est une simple démonstration de la récupération d'un secret auprès de Trustee à l'aide d'un conteneur init. Cette application permet d'accéder au secret via son API web afin de voir comment les modifications apportées au secret se propagent dans tout le système. Cette méthode de conteneur init pour récupérer des secrets est pratique pour renforcer la sécurité des applications existantes, car elle permet de le faire sans déployer Trustee dans tous les environnements de code.

Éléments à prendre en compte en matière de sécurité pour le déploiement de modèles pour les conteneurs confidentiels 

Parce que les conteneurs confidentiels sont axés sur la sécurité, il est important d'examiner la posture de sécurité du modèle validé qui sera utilisé. Il faut notamment prendre en compte deux éléments principaux pour ce modèle :

• Le modèle actuel utilise des valeurs de référence simples. Nous vous recommandons de vous informer sur le flux d'attestation RATS et de développer des politiques adaptées à vos besoins en matière de sécurité et au profil de risque de votre système.
• Le déploiement Trustee est séparé. En lien avec le premier point, le service d'attestation de Trustee repose sur le principe qu'il fonctionne dans une zone de sécurité fiable et distincte. Idéalement, il s'agit d'un environnement différent, par exemple sur site ou sur une autre plateforme cloud.

Le schéma ci-dessous illustre l'architecture utilisée pour déployer Trustee dans un environnement séparé, à l'aide du modèle validé pour les conteneurs confidentiels :

L'avenir des modèles pour Confidential Containers 

Le modèle validé pour Confidential Containers suffit pour commencer. Son objectif est de vous aider à réussir dans un seul cluster et un environnement pour vous permettre de commencer les tests. Notre objectif immédiat est de vous donner plus d'exemples pratiques pour que vous puissiez continuer à utiliser Confidential Containers.

Nous souhaitons prendre en charge les déploiements en étoile dans plusieurs clusters afin de déployer Trustee dans le hub avec Red Hat Advanced Cluster Management et les clusters en étoile où s'exécutent les charges de travail confidentielles.

Nous avons également l'intention de fournir des exemples pratiques d'utilisation de Trustee pour la gestion des secrets. Jusqu'ici, les exemples sont simples. Nos priorités pour le développement futur sont de permettre le chiffrement du stockage géré au sein d'un TEE, l'initialisation d'un secret pour les applications non liées à Trustee et la configuration d'un VPN.

Nous voulons également prendre en charge d'autres environnements pour le déploiement de Confidential Containers et de Trustee, afin que la confiance puisse être répartie entre les ressources sur site ou entre plusieurs fournisseurs de services cloud.

Résumé 

Le modèle validé pour les conteneurs confidentiels offre un mécanisme simple pour débuter avec Confidential Containers. C'est un excellent mécanisme pour lancer des expérimentations et déployer des applications séparées dans un référentiel unique, tout en suivant l'approche GitOps App-of-Apps standardisée d'Argo CD. Comme nous l'avons vu, il peut être très simple de se lancer à l'aide des commandes git clone et make install.