Utilisation de politiques de sécurité de pod avec Kubernetes Engine (OKE)

Pour créer une politique de sécurité pour les pods d'application, créez un rôle pour accéder à la politique de sécurité de pod et créez une liaison de rôle pour permettre aux pods d'application d'utiliser la politique de sécurité de pod :

1. Créez la politique de sécurité de pod pour les pods d'application :

   1. Définissez la politique de sécurité de pod et enregistrez-la dans un fichier. Par exemple, dans acme-app-psp.yaml.

      À titre d'exemple, cette politique (tirée de la documentation de Kubernetes) empêche simplement la création de pods préférés :

      
      apiVersion: policy/v1beta1
      kind: PodSecurityPolicy
      metadata:
        name: acme-app-psp
      spec:
        privileged: false  # Don't allow privileged pods!
        # The rest fills in some required fields.
        seLinux:
          rule: RunAsAny
        supplementalGroups:
          rule: RunAsAny
        runAsUser:
          rule: RunAsAny
        fsGroup:
          rule: RunAsAny
        volumes:
        - '*'

   2. Entrez la commande suivante pour créer la politique de sécurité de pod :

      kubectl create -f <filename>.yaml

      Par exemple :

      kubectl create -f acme-app-psp.yaml

2. Créez le rôle (ou rôle de grappe) pour accéder à la politique de sécurité de pod :

   1. Définissez un rôle (ou rôle de grappe) et enregistrez-le dans un fichier. Par exemple, dans acme-app-psp-crole.yaml.

      Par exemple :

      # Cluster role which grants access to the app pod security policy
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: acme-app-psp-crole
      rules:
      - apiGroups:
        - policy
        resourceNames:
        - acme-app-psp
        resources:
        - podsecuritypolicies
        verbs:
        - use
      

   2. Entrez la commande suivante pour créer le rôle de grappe :

      kubectl create -f <filename>.yaml

      Par exemple :

      kubectl create -f acme-app-psp-crole.yaml

3. Créez la liaison de rôle de grappe pour autoriser les pods d'application à utiliser la politique de sécurité de pod :

   1. Définissez la liaison de rôle de grappe et enregistrez-la dans un fichier. Par exemple, dans acme-app-psp-crole-bind.yaml.

      Par exemple :

      
      # Role binding which grants access to the app pod security policy
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: acme-app-psp-binding
        namespace: acme-namespace
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: acme-app-psp-crole
      subjects:
      # For all service accounts in acme-namespace
      - apiGroup: rbac.authorization.k8s.io
        kind: Group
        name: system:serviceaccounts:acme-namespace

   2. Entrez la commande suivante pour créer la liaison de rôle de grappe :

      kubectl create -f <filename>.yaml

      Par exemple :

      kubectl create -f acme-app-psp-crole-bind.yaml

Après avoir défini une politique de sécurité de pod et autorisé les pods d'application à l'utiliser en créant un rôle de grappe et une liaison de rôle de grappe, activez le contrôleur d'application PodSecurityPolicy pour appliquer la politique de sécurité de pod (s'il n'est pas déjà activé).

Pour activer le contrôleur d'admission PodSecurityPolicy lors de la création de nouvelles grappes à l'aide de la console :

1. Connectez-vous à la console.

2. Pour créer une grappe, suivez les instructions sous Utilisation de la console pour créer une grappe avec des paramètres définis explicitement dans le flux de création personnalisée, sélectionnez Afficher les options avancées et sélectionnez l'option Politiques de sécurité des pods - Mise en oeuvre. Cette option active le contrôleur d'admission PodSecurityPolicy.

   Aucun pod d'application ne sera accepté dans la nouvelle grappe, sauf si les politiques de sécurité de pod appropriées existent, ainsi que les rôles de grappe et les liaisons de rôle de grappe associant les pods aux politiques.

3. Suivez les instructions pour définir les détails restants de la grappe et sélectionnez Créer une grappe pour créer la nouvelle grappe.

4. Suivez les instructions décrites dans Création d'une politique de sécurité de pod pour les pods d'application afin de créer des politiques de sécurité des pods pour le contrôleur d'admission PodSecurityPolicy à appliquer lors de l'acceptation de pods dans la nouvelle grappe.

Pour activer le contrôleur d'admission PodSecurityPolicy dans des grappes existantes au moyen de la console :

1. Suivez les instructions décrites dans Création d'une politique de sécurité de pod pour les pods d'application afin de créer des politiques de sécurité de pods pour le contrôleur d'admission PodSecurityPolicy à appliquer lors de l'acceptation de pods dans la grappe existante.

   Nous vous recommandons vivement de vérifier d'abord les politiques de sécurité des pods dans un environnement de développement ou de test. Cela vous permettra de vérifier que les politiques de sécurité des pods fonctionnent comme vous l'attendez et autorisent (ou interdisent) correctement le démarrage des pods dans la grappe.

2. Dans la page de liste Grappes, sélectionnez le nom de la grappe à modifier. Si vous avez besoin d'aide pour trouver la page de liste ou la grappe, voir Liste des grappes.
3. Dans l'onglet Détails de la grappe, sélectionnez Pas de mise en oeuvre à côté de Politiques de sécurité des pods.

4. Dans la fenêtre Politiques de sécurité des pods, sélectionnez Mise en oeuvre.

   Dorénavant, aucun nouveau pod d'application ne sera accepté dans la grappe, sauf si les politiques de sécurité des pods appropriées existent, ainsi que les rôles de grappe et les liaisons de rôle de grappe associant les pods aux politiques. Notez que tous les pods en cours continueront de s'exécuter.

5. Sélectionnez Enregistrer les modifications.

Pour désactiver le contrôleur d'admission PodSecurityPolicy dans les grappes où il était précédemment activé :

1. Dans la page de liste Grappes, sélectionnez le nom de la grappe à modifier. Si vous avez besoin d'aide pour trouver la page de liste ou la grappe, voir Liste des grappes.
2. Dans l'onglet Détails de la grappe, sélectionnez Mise en oeuvre à côté de Politiques de sécurité des pods.

3. Dans la fenêtre Politiques de sécurité des pods, sélectionnez Non mis en oeuvre.

   À partir de maintenant, les nouveaux pods d'application seront acceptés dans la grappe sans que les politiques de sécurité des pods, les rôles de grappe et les liaisons de rôle de grappe soient requis. Notez que tous les pods en cours continueront de s'exécuter.

4. Sélectionnez Enregistrer les modifications.

Pour plus d'informations sur l'utilisation de l'API et sur les demandes de signature, voir la documentation de l'API REST et Données d'identification de sécurité. Pour plus d'informations sur les trousses SDK, voir Trousses SDK et interface de ligne de commande.

Pour activer le contrôleur d'admission PodSecurityPolicy, utilisez l'une des opérations suivantes :

• Opération CreateCluster lors de la création de nouvelles grappes
• Opération Update Cluster lors de la modification de grappes existantes

La politique de sécurité de pod, ainsi que le rôle de grappe et la liaison de rôle de grappe associés, pour les pods privilégiés du système Kubernetes sont créés automatiquement lors de l'activation du contrôleur d'admission PodSecurityPolicy d'une grappe. Ils permettent l'exécution de tout pod dans l'espace de noms kube-system. Ils sont créés à partir des définitions dans le fichier kube-system.yaml indiqué ci-dessous :

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  annotations:
    # See https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
  name: oke-privileged
spec:
  allowedCapabilities:
  - '*'
  allowPrivilegeEscalation: true
  fsGroup:
    rule: 'RunAsAny'
  hostIPC: true
  hostNetwork: true
  hostPID: true
  hostPorts:
  - min: 0
    max: 65535
  privileged: true
  readOnlyRootFilesystem: false
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  volumes:
  - '*'
  
---
  
# Cluster role which grants access to the privileged pod security policy
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: oke-privileged-psp
rules:
- apiGroups:
  - policy
  resourceNames:
  - oke-privileged
  resources:
  - podsecuritypolicies
  verbs:
  - use
  
---
  
# Role binding for kube-system - allow kube-system service accounts - should take care of CNI i.e. flannel running in the kube-system namespace
# Assumes access to the kube-system is restricted
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kube-system-psp
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: oke-privileged-psp
subjects:
# For all service accounts in the kube-system namespace
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts:kube-system