Utiliser PodSecurityPolicies

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.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

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.