Ce document explique comment renforcer la sécurité de vos clusters Anthos clusters on bare metal.
Sécuriser vos conteneurs à l'aide de SELinux
Vous pouvez sécuriser vos conteneurs en activant SELinux, qui est compatible avec Red Hat Enterprise Linux (RHEL) et CentOS. Si vos machines hôtes exécutent RHEL ou CentOS et que vous souhaitez activer SELinux pour votre cluster, vous devez activer SELinux sur toutes vos machines hôtes. Pour en savoir plus, consultez la section Sécuriser vos conteneurs à l'aide de SELinux.
Ne pas exécuter de conteneurs en tant qu'utilisateur root
Par défaut, les processus des conteneurs s'exécutent en tant que root. Cela pose un problème potentiel en termes de sécurité, car si un processus s'échappe du conteneur, il s'exécute en tant que racine sur la machine hôte. Il est donc conseillé d'exécuter toutes vos charges de travail en tant qu'utilisateur non racine.
Les sections suivantes décrivent deux manières d'exécuter des conteneurs en tant qu'utilisateur non racine.
Méthode 1 : ajouter une instruction USER dans Dockerfile
Cette méthode utilise un Dockerfile pour garantir que les conteneurs ne s'exécutent pas en tant qu'utilisateur root. Dans un Dockerfile, vous pouvez spécifier en tant que quel utilisateur le processus à l'intérieur d'un conteneur doit être exécuté. L'extrait suivant d'un Dockerfile montre comment procéder :
....
#Add a user with userid 8877 and name nonroot
RUN useradd −u 8877 nonroot
#Run Container as nonroot
USER nonroot
....
Dans cet exemple, la commande Linux useradd -u crée un utilisateur appelé nonroot dans le conteneur. Cet utilisateur possède l'ID utilisateur (UID) 8877.
La ligne suivante du Dockerfile exécute la commande USER nonroot. Cette commande spécifie qu'à partir de ce point de l'image, les commandes sont exécutées en tant qu'utilisateur nonroot.
Attribuez des autorisations à l'UID 8877 de sorte que les processus du conteneur puissent s'exécuter correctement pour nonroot.
Méthode 2 : ajouter des champs securityContext dans le fichier manifeste Kubernetes
Cette méthode utilise un fichier manifeste Kubernetes pour s'assurer que les conteneurs ne s'exécutent pas en tant qu'utilisateur root. Les paramètres de sécurité sont spécifiés pour un pod, et ces paramètres de sécurité sont à leur tour appliqués à tous les conteneurs du pod.
L'exemple suivant montre un extrait d'un fichier manifeste pour un pod donné :
apiVersion: v1
kind: Pod
metadata:
name: name-of-pod
spec:
securityContext:
runAsUser: 8877
runAsGroup: 8877
....
Le champ runAsUser spécifie que pour tous les conteneurs du pod, tous les processus s'exécutent avec l'ID utilisateur 8877. Le champ runAsGroup spécifie que ces processus ont l'ID de groupe (GID) principal 8877. N'oubliez pas d'accorder les autorisations nécessaires et suffisantes à l'UID 8877 afin que les processus de conteneur puissent s'exécuter correctement.
Cela garantit que les processus d'un conteneur sont exécutés en tant qu'UID 8877, qui dispose de privilèges moindres que l'utilisateur racine.
Les conteneurs système dans Anthos clusters on bare metal utilisent des UID et des GID compris entre 2000 et 4999. Par conséquent, utilisez des UID et des GID qui ne font pas partie de cette plage réservée lorsque vous attribuez des autorisations à des charges de travail utilisateur.
Restreindre les capacités d'automodification des charges de travail
Certaines charges de travail Kubernetes, en particulier les charges de travail système, sont autorisées à s'automodifier. Par exemple, certaines charges de travail effectuent des autoscaling verticaux sur elle-mêmes. Bien que cette capacité soit pratique, elle peut permettre à un pirate informatique ayant déjà compromis un nœud de passer au niveau supérieur dans le cluster. Par exemple, un pirate informatique peut faire en sorte qu'une charge de travail sur le nœud se modifie pour s'exécuter en tant que compte de service plus privilégié qui existe dans le même espace de noms.
Idéalement, les charges de travail ne doivent pas être autorisées à se modifier elles-mêmes. Lorsque l'automodification est nécessaire, vous pouvez limiter les autorisations en appliquant des contraintes Gatekeeper ou Policy Controller, telles que NoUpdateServiceAccount de la bibliothèque Open Source Gatekeeper, qui offre plusieurs règles de sécurité utiles.
Lorsque vous déployez des règles, il est généralement nécessaire de permettre aux contrôleurs qui gèrent le cycle de vie du cluster de contourner les règles. Cela est nécessaire pour que les contrôleurs puissent apporter des modifications au cluster, telles que l'application de mises à niveau de cluster. Par exemple, si vous déployez la règle NoUpdateServiceAccount sur Anthos Clusters sur solution Bare Metal, vous devez définir les paramètres suivants dans Constraint :
parameters:
allowedGroups:
- system:masters
allowedUsers: []
Maintenance
La surveillance des bulletins de sécurité et la mise à niveau de vos clusters sont des mesures de sécurité importantes à prendre en compte une fois que vos clusters sont opérationnels.
Surveiller les bulletins de sécurité
L'équipe de sécurité Anthos publie des bulletins de sécurité pour les failles de gravité élevée et critique.
Ces bulletins suivent un schéma commun de numérotation des failles Google Cloud, et sont accessibles à partir de la page principale des bulletins Google Cloud et des notes de version d'Anthos clusters on bare metal. Utilisez ce flux XML pour vous abonner aux bulletins de sécurité pour Anthos clusters on bare metal et les produits associés :
https://cloud.google.com/feeds/anthos-gke-security-bulletins.xml 
Lorsque la réaction du client est requise pour remédier à ces failles critiques, Google contacte les clients par e-mail. Google peut également contacter les clients par le biais de contrats d'assistance via des canaux d'assistance.
Pour en savoir plus sur la manière dont Google gère les failles et les correctifs de sécurité pour GKE et Anthos, consultez la page Correctifs de sécurité.
Mettre à niveau les clusters
Kubernetes introduit régulièrement de nouvelles fonctionnalités de sécurité et fournit des correctifs de sécurité. Les versions Anthos clusters on bare metal intègrent des améliorations de sécurité de Kubernetes qui corrigent des failles de sécurité susceptibles d'affecter vos clusters.
Vous êtes responsable du maintien à jour de vos clusters Anthos. Pour chaque version, consultez les notes de version. Pour minimiser les risques de sécurité de vos clusters Anthos, prévoyez une mise à jour tous les mois pour les nouvelles versions de patch, et tous les trois mois pour les versions mineures.
L'un des nombreux avantages de mettre à niveau un cluster est que l'opération actualise automatiquement le fichier kubeconfig du cluster. Le fichier kubeconfig authentifie un utilisateur auprès d'un cluster. Le fichier kubeconfig est ajouté au répertoire du cluster lorsque vous le créez avec bmctl. Le nom et le chemin d'accès par défaut sont bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Lorsque vous mettez à niveau un cluster, le fichier kubeconfig de ce cluster est automatiquement renouvelé. Sinon, le fichier kubeconfig expire un an après sa création.
Pour en savoir plus sur la mise à niveau de vos clusters, consultez la page Mettre à niveau vos clusters.