Cette page explique comment utiliser des règles PodSecurityPolicy dans Google Kubernetes Engine.
Présentation
Une règle PodSecurityPolicy est une ressource de contrôleur d'admission que vous créez afin qu'elle valide les requêtes de création ou de mise à jour de pod sur votre cluster. PodSecurityPolicy définit un ensemble de conditions que les pods doivent remplir pour être acceptés par le cluster. Lorsqu'une requête de création ou de mise à jour d'un pod ne remplit pas les conditions de PodSecurityPolicy, cette requête est rejetée et une erreur est renvoyée.
Pour utiliser PodSecurityPolicy, vous devez commencer par créer et définir les règles que les nouveaux pods ou les pods mis à jour doivent respecter. Ensuite, vous devez activer le contrôleur d'admission PodSecurityPolicy, qui valide les requêtes de création ou de mise à jour de pod par rapport aux règles définies.
Lorsque plusieurs règles PodSecurityPolicy sont disponibles, le contrôleur d'admission utilise la première règle validée avec succès. Les règles sont classées par ordre alphabétique et le contrôleur privilégie les règles qui n'entraînent pas de mutations dans le pod par rapport aux autres règles.
PodSecurityPolicy est disponible dans les clusters GKE exécutant Kubernetes version 1.8.6 ou ultérieure.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Activez l'API Google Kubernetes Engine. Activer l'API Google Kubernetes Engine
- Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI.
- Assurez-vous de bien maîtriser le contrôle des accès basé sur les rôles dans GKE.
Définir des règles PodSecurityPolicy
Avant que le contrôleur PodSecurityPolicy puisse valider des pods et les accepter dans votre cluster, vous devez définir les ressources PodSecurityPolicy à utiliser dans ce cluster.
Une règle PodSecurityPolicy spécifie la liste des restrictions, des exigences et des valeurs par défaut applicables aux pods créés selon cette règle. Il s'agira par exemple de restreindre l'utilisation des conteneurs privilégiés, des volumes hostPath
et du réseau hôte, ou d'indiquer que tous les conteneurs s'exécutent par défaut avec un profil seccomp. Le contrôleur d'admission PodSecurityPolicy valide les requêtes par rapport aux règles PodSecurityPolicy disponibles.
L'exemple de règle PodSecurityPolicy suivant (my-psp.yaml
) empêche simplement la création de pods privilégiés : Cette règle affecte également plusieurs autres aspects du contrôle, tels que l'autorisation d'accès à tous les volumes disponibles :
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: my-psp
spec:
privileged: false # Prevents creation of privileged Pods
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
volumes:
- '*'
La spécification PodSecurityPolicy permet de sécuriser de nombreux aspects du contrôle. Les aspects du contrôle qui sont spécifiés dans cet exemple (supplementalGroups
, runAsUser
et fsGroup
) sont tous définis sur RunAsAny
, ce qui indique que toute valeur valide pour ces champs peut être utilisée avec cette règle.
Pour plus d'informations sur les règles PodSecurityPolicy et leurs aspects de contrôle, consultez les sections Qu'est-ce qu'une règle de sécurité de pod ? et la Référence des règles dans la documentation de Kubernetes.
Pour créer cette ressource, utilisez l'outil de ligne de commande kubectl
:
kubectl apply -f my-psp.yaml
Pour plus d'exemples de configuration de règles PodSecurityPolicy, consultez la section Exemple de la page "PodSecurityPolicy" dans la documentation de Kubernetes.
Autoriser les règles
Les comptes dotés du rôle cluster-admin peuvent utiliser le contrôle d'accès basé sur les rôles pour créer un rôle ou un ClusterRole permettant aux comptes de service souhaités d'accéder aux règles PodSecurityPolicy. Un objet ClusterRole accorde des autorisations à l'échelle du cluster, tandis qu'un objet Role accorde des autorisations dans un espace de noms que vous définissez.
Dans l'exemple qui suit, l'objet ClusterRole my-clusterrole.yaml
accorde un accès à la règle PodSecurityPolicy my-psp
comme indiqué par verb: use
:
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: my-clusterrole
rules:
- apiGroups:
- policy
resources:
- podsecuritypolicies
verbs:
- use
resourceNames:
- my-psp
Créez l'objet ClusterRole en exécutant la commande suivante :
kubectl apply -f my-clusterrole.yaml
Après avoir créé un objet Role (ou ClusterRole), vous l'associez aux comptes de service souhaités en créant une ressource RoleBinding (ou ClusterRoleBinding).
Dans l'exemple qui suit, la ressource RoleBinding my-rolebinding.yaml
lie l'objet ClusterRole my-clusterrole
aux comptes de service d'un espace de noms spécifique, my-namespace
:
# Bind the ClusterRole to the desired set of service accounts.
# Policies should typically be bound to service accounts in a namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: my-rolebinding
namespace: my-namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: my-clusterrole
subjects:
# Example: All service accounts in my-namespace
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts
# Example: A specific service account in my-namespace
- kind: ServiceAccount # Omit apiGroup
name: default
namespace: my-namespace
Dans cette ressource RoleBinding :
- Le champ
subjects
spécifie les comptes auxquels l'objet ClusterRole est lié. - Le premier élément Subject est le groupe
system:serviceaccounts
, qui englobe tous les comptes de service du cluster. - Le second élément Subject est l'objet ServiceAccount individuel
default
, qui spécifie le compte de service par défaut dans l'espace de noms.
Créez la ressource RoleBinding en exécutant la commande suivante :
kubectl apply -f my-rolebinding.yaml
Pour plus d'informations sur le contrôle des accès basé sur les rôles (RBAC), consultez la page Utiliser l'autorisation RBAC.
Activer le contrôleur PodSecurityPolicy
Pour utiliser le contrôleur d'admission PodSecurityPolicy, vous devez créer un cluster ou mettre à jour un cluster existant en spécifiant l'option --enable-pod-security-policy
.
Pour créer un cluster doté de PodSecurityPolicy, exécutez la commande suivante :
gcloud beta container clusters create cluster-name --enable-pod-security-policy
Pour mettre à jour un cluster existant :
gcloud beta container clusters update cluster-name --enable-pod-security-policy
Désactiver le contrôleur PodSecurityPolicy
Pour désactiver le contrôleur PodSecurityPolicy, exécutez la commande suivante :
gcloud beta container clusters update cluster-name --no-enable-pod-security-policy
La désactivation du contrôleur empêche le cluster d'appliquer les conditions de validation et les valeurs par défaut des règles existantes, mais elle ne supprime pas ces règles. Les liaisons ne sont pas supprimées non plus.
Utiliser une règle NetworkPolicy
Si vous utilisez une règle NetworkPolicy et que vous avez un pod soumis à une règle PodSecurityPolicy, créez un objet RBAC Role ou ClusterRole autorisé à utiliser la règle PodSecurityPolicy. Liez ensuite Role ou ClusterRole au compte de service du pod. Accorder des autorisations aux comptes utilisateur n'est pas suffisant dans ce cas. Pour plus d'informations, consultez la section Autoriser les règles.
Étapes suivantes
- Approfondissez vos connaissances sur le contrôle des accès basé sur les rôles.
- Découvrez comment sécuriser votre cluster à l'aide de la gestion de l'authentification et des accès.
- Apprenez-en plus sur l'isolation d'une charge de travail avec GKE Sandbox.