Anthos clusters on Azure est disponible pour les clients ayant une relation d'assistance établie avec Google Cloud. Contactez votre responsable de compte pour obtenir un accès.

Présentation de la sécurité

Cette page décrit l'architecture de sécurité des clusters Anthos sur Azure, y compris l'authentification et la configuration des nœuds.

Anthos clusters on Azure offre plusieurs fonctionnalités pour sécuriser vos charges de travail, y compris le contenu de votre image de conteneur, l'environnement d'exécution du conteneur, le réseau du cluster et l'accès au serveur d'API du cluster.

Il est préférable d'adopter une approche multicouche pour protéger vos clusters et vos charges de travail. Vous pouvez appliquer le principe du moindre privilège au niveau d'accès que vous accordez à vos utilisateurs et à vos charges de travail. Vous devrez peut-être faire des compromis pour offrir le bon niveau de flexibilité et de sécurité.

Lorsque vous utilisez des clusters Anthos sur Azure, vous acceptez de prendre certaines responsabilités pour vos clusters. Pour plus d'informations, consultez la page Responsabilités partagées des clusters Anthos.

Comment Anthos se connecte à Azure

Le service de gestion s'authentifie auprès d'Azure à l'aide d'un objet AzureClient. Lorsque vous créez un client, Google génère une paire de clés X.509. Vous importez la clé publique dans Azure Active Directory (Azure AD).

Pour en savoir plus, consultez la page Créer un client Azure.

Authentification et autorisation

Vous vous authentifiez auprès des clusters Anthos sur Azure à l'aide de l'une des méthodes suivantes :

  • Google Identity, qui permet aux utilisateurs de se connecter à l'aide de leur identité Google Cloud Identity.

  • Anthos Identity Service, qui permet aux utilisateurs de se connecter à l'aide d'OpenID Connect.

Chiffrement des données au repos

Le chiffrement des données au repos est le chiffrement des données stockées, par opposition aux données en transit. Par défaut, Anthos clusters on Azure chiffre les données au repos dans les volumes etcd et de stockage à l'aide de clés gérées de la plate-forme Azure.

Les clusters Anthos clusters on Azure stockent les données dans des volumes Azure Disk. Ces volumes de disque sont toujours chiffrés au repos à l'aide de clés Azure Key Vault. Lorsque vous créez des clusters et des pools de nœuds, vous pouvez fournir une clé KeyVault gérée par le client pour chiffrer les volumes de disque sous-jacents du cluster. Si vous ne spécifiez pas de clé, Azure utilise la clé gérée par Azure par défaut dans la région Azure où le cluster est exécuté.

En outre, tous les clusters Anthos clusters on Azure permettent le Chiffrement des secrets au niveau de la couche d'application pour renforcer la sécurité des données sensibles, tels que les objets secrets Kubernetes, qui sont stockés dansetcd. Même si des pirates informatiques accèdent au volume sous-jacent où les données etcd sont stockées, cette seconde couche de chiffrement les protège.

Lorsque vous créez un cluster, vous pouvez fournir une clé Azure Key Vault dans le paramètre --database-encryption-kms-key-arn. Cette clé est utilisée pour le chiffrement des données de votre application. Si vous ne fournissez pas de clé lors de la création du cluster, Anthos clusters on Azure en crée une automatiquement pour votre cluster. Ce champ de ressource est immuable et ne peut pas être modifié une fois le cluster créé.

Vous pouvez également créer manuellement une clé Key Vault ou utiliser votre propre clé (BYOK, Bring Your Own Key) avec un module de sécurité matérielle (HSM, Hardware Security Module). Pour en savoir plus, consultez la section Utiliser votre propre clé.

Fonctionnement du chiffrement au niveau de l'application

Kubernetes propose le chiffrement au niveau de l'application grâce à une technique connue sous le nom de chiffrement encapsulé. Une clé locale, couramment appelée clé de chiffrement des données (DEK, Data Encryption Key), est utilisée pour chiffrer un secret. La DEK elle-même est ensuite chiffrée avec une deuxième clé appelée clé de chiffrement de clé (KEK, Key Encryption Key). La clé KEK n'est pas stockée par Kubernetes. Lorsque vous créez un secret Kubernetes, Anthos clusters on Azure effectue les opérations suivantes :

  1. Le serveur d'API Kubernetes génère une DEK unique pour le secret à l'aide d'un générateur de numéros aléatoires.

  2. Le serveur d'API Kubernetes chiffre le secret localement avec la DEK.

  3. Le serveur d'API Kubernetes envoie la DEK à Azure Key Vault pour chiffrement.

  4. Azure Key Vault utilise une KEK prégénérée pour chiffrer la DEK et renvoie la DEK chiffrée au plug-in Azure Key Vault du serveur d'API Kubernetes.

  5. Le serveur d'API Kubernetes enregistre le secret chiffré et la DEK chiffrée dans etcd. La DEK en texte brut n'est pas enregistré sur le disque.

  6. Le serveur d'API Kubernetes crée une entrée de cache en mémoire pour mapper la DEK chiffrée à la DEK en texte brut. Cela permet au serveur d'API de déchiffrer les secrets récemment utilisés sans interroger Azure Key Vault.

Lorsqu'un client demande un secret au serveur d'API Kubernetes, voici ce qui se passe :

  1. Le serveur d'API Kubernetes récupère le secret et la DEK chiffrés à partir d'etcd.

  2. Le serveur d'API Kubernetes vérifie la présence d'une entrée de mappage existante dans le cache et l'utilise pour déchiffrer le secret s'il en trouve une.

  3. En l'absence d'entrée de cache correspondante, le serveur d'API envoie la DEK à Azure Key Vault pour le déchiffrement à l'aide de la KEK. La DEK déchiffrée est ensuite utilisée pour déchiffrer le secret.

  4. Enfin, le serveur d'API Kubernetes renvoie le secret déchiffré au client.

Chiffrement de la configuration avec le pare-feu Key Vault

Si vous transmettez une clé publique pour le chiffrement, le compte principal de service n'a pas besoin d'être autorisé à chiffrer, mais il doit être autorisé à gérer les attributions de rôles. Pour ce faire, le moyen le plus simple consiste à attribuer le rôle intégré User Access Administrator Azure à votre compte principal de service.

Pour sécuriser davantage votre Azure Key Vault, vous pouvez activer le pare-feu Azure Key Vault. Anthos clusters on Azure peut ensuite utiliser une clé publique pour le chiffrement et éviter l'accès réseau au coffre de clés.

Pour configurer le pare-feu, téléchargez la clé Key Vault avec la CLI Azure. Vous transmettez la clé à --config-encryption-public-key lorsque vous créez un cluster avec l'outil de ligne de commande gcloud.

Vous devez toujours activer les points de terminaison de service pour Key Vault dans tous les sous-réseaux utilisés pour votre cluster. Pour plus d'informations, consultez la page Points de terminaison des services de réseau virtuel pour Azure Key Vault.

Authentification de l'API Anthos clusters on Azure

Vous utilisez l'API Anthos clusters on Azure pour créer, mettre à jour et supprimer des clusters et des pools de nœuds. Comme pour les autres API Google Cloud, vous pouvez l'utiliser avec REST, le SDK Cloud ou l'outil de ligne de commande gcloud. Vous vous authentifiez auprès des clusters Anthos sur l'API Azure de la même manière qu'avec les autres API Google Cloud.

Pour en savoir plus, consultez la présentation de l'authentification Google Cloud.

Authentification de l'API Kubernetes

Comme pour les distributions Kubernetes, vous utilisez l'outil de ligne de commande kubectl pour effectuer des opérations de cluster telles que le déploiement d'une charge de travail et la configuration d'un équilibreur de charge. L'outil kubectl se connecte à l'API Kubernetes sur le plan de contrôle de votre cluster. Pour appeler cette API, vous devez vous authentifier à l'aide des identifiants autorisés.

Pour obtenir des identifiants, vous pouvez utiliser l'outil gcloud ou OIDC, ou vous authentifier auprès d'Anthos Identity Service. Anthos Identity Service vous permet d'utiliser des fournisseurs d'identité tels queOkta, ADFS (Active Directory Federation Services) ou tout fournisseur d'identité conforme à OpenID Connect.

Accès administrateur

Par défaut, lorsque vous créez un cluster d'utilisateur, les clusters Anthos sur Azure créent un compte administrateur nommé kubernetes-admin dans le groupe system:masters. Vous pouvez obtenir les identifiants de ce compte avec la commande gcloud container azure clusters get-kubeconfig.

Vous contrôlez la liste des utilisateurs disposant de droits d'administrateur de cluster avec le champ authorization de la ressource AzureCluster. Les clusters Anthos sur Azure créent des liaisons de rôles de contrôle d'accès basé sur les rôles (RBAC, role-based access control) appropriées pour ces utilisateurs. Lorsque vous utilisez l'outil gcloud pour créer un cluster, les clusters Anthos sur Azure ajoutent votre compte utilisateur à authorization.adminUsers.

Pour afficher la configuration de l'accès de votre cluster, exécutez la commande suivante :

kubectl describe clusterrolebinding gke-multicloud-cluster-admin

Pour en savoir plus sur la connexion au cluster, consultez la section Se connecter au cluster et s'authentifier.

Contrôle des accès

Les clusters Anthos sur Azure proposent deux méthodes pour le contrôle des accès : l'API Anthos clusters on Azure et le contrôle des accès basé sur les rôles (RBAC). Cette section décrit les différences entre ces méthodes.

Contrôle des accès avec l'API Anthos clusters on Azure

L'API Anthos clusters on Azure permet aux administrateurs de cluster de créer, de mettre à jour et de supprimer des clusters et des pools de nœuds. Vous gérez les autorisations de l'API à l'aide d'Identity and Access Management (IAM). Pour utiliser l'API Anthos clusters on Azure, les utilisateurs doivent disposer des autorisations appropriées. Pour connaître les autorisations nécessaires pour chaque opération, consultez la page Rôles et autorisations des API. Cloud IAM vous permet de définir des rôles et de les attribuer à des comptes principaux. Un rôle est un ensemble d'autorisations qui, lorsqu'il est attribué à un compte principal, contrôle les accès à une ou plusieurs ressources Google Cloud.

Lorsque vous créez un cluster ou un pool de nœuds dans une organisation, un dossier ou un projet, les utilisateurs disposant des autorisations requises dans cette organisation, ce dossier ou ce projet peuvent modifier la ressource. Par exemple, si vous accordez à un utilisateur une autorisation de suppression de cluster au niveau d'un projet Google Cloud, cet utilisateur peut supprimer n'importe quel cluster de ce projet. Pour en savoir plus, consultez les pages Hiérarchie des ressources Google Cloud et Créer des stratégies IAM.

Contrôle des accès avec l'API Kubernetes

L'API Kubernetes vous permet de gérer les objets Kubernetes. Pour gérer le contrôle des accès sur l'API Kubernetes, vous utilisez le contrôle des accès basé sur les rôles (RBAC). Utilisez RBAC pour accorder aux développeurs l'accès aux clusters. Pour en savoir plus, consultez la page Configurer le contrôle des accès basé sur les rôles dans la documentation de GKE.

Confiance dans les clusters

Pour les clusters Anthos sur Azure, toutes les communications de cluster utilisent le protocole TLS (Transport Layer Security). Chaque cluster est provisionné avec les principales autorités de certification racine autosignées suivantes :

  • L'autorité de certification racine du cluster est utilisée pour valider les requêtes envoyées au serveur d'API.
  • L'autorité de certification racine etcd est utilisée pour valider les requêtes envoyées aux instances dupliquées etcd.

Anthos clusters on Azure provisionne chaque cluster avec une autorité de certification racine unique. Si l'autorité de certification d'un cluster est compromise, aucune autre autorité de certification de cluster n'est affectée. Toutes les autorités de certification racine ont une période de validité de 30 ans.

Sécuriser les nœuds

Anthos clusters on Azure déploie vos charges de travail sur des pools de nœuds des instances de VM Azure. La section suivante explique comment utiliser les fonctionnalités de sécurité au niveau du nœud dans les clusters Anthos sur Azure.

Ubuntu

Anthos clusters on Azure utilise une version optimisée d'Ubuntu comme système d'exploitation sur lequel exécuter le plan de contrôle et les nœuds Kubernetes. Ubuntu inclut un ensemble complet de fonctionnalités de sécurité modernes.

Les clusters Anthos sur Azure mettent en œuvre plusieurs de ces fonctionnalités de sécurité pour les clusters, y compris les suivantes :

Des guides de sécurité supplémentaires sont disponibles pour Ubuntu, tels que les suivants :

Sécuriser vos charges de travail

Kubernetes permet aux utilisateurs de provisionner, mettre à l'échelle et mettre à jour rapidement des charges de travail basées sur des conteneurs. Cette section décrit les tactiques que vous pouvez utiliser pour limiter les effets secondaires de l'exécution de conteneurs sur un cluster et les services Google Cloud.

Limiter les droits de processus en conteneur du pod

Limiter les droits des processus en conteneur est important pour la sécurité de votre cluster. Vous pouvez définir des options liées à la sécurité avec le contexte de sécurité des pods et des conteneurs. Ces paramètres vous permettent de modifier les paramètres de sécurité de vos processus, tels que les suivants :

  • Utilisateur et groupe exécutant le processus
  • Capacités Linux disponibles
  • Élévation des privilèges

Le système d'exploitation par défaut du nœud Anthos clusters on Azure, Ubuntu, applique les règles de sécurité Docker AppArmor par défaut à tous les conteneurs démarrés par Kubernetes. Vous pouvez consulter le modèle du profil sur GitHub. Entre autres choses, le profil refuse les capacités suivantes aux conteneurs :

  • Écrire dans des fichiers directement dans un répertoire d'ID de processus (/proc/)
  • Écrire dans des fichiers qui ne se trouvent pas dans /proc/
  • Écrire dans des fichiers dans /proc/sys autres que /proc/sys/kernel/shm*
  • Installer des systèmes de fichiers

Étape suivante