Utilisation des stratégies de sécurité de pod avec Kubernetes Engine (OKE)

Afin de créer une stratégie de sécurité de pod pour les pods d'application, créez un rôle permettant d'accéder à la stratégie de sécurité de pod et créez une liaison de rôle pour autoriser les pods d'application à utiliser cette stratégie :

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

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

      Par exemple, cette stratégie (issue de la documentation Kubernetes) empêche simplement la création de pods dotés de privilèges :

      
      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. Saisissez la commande suivante pour créer la stratégie 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 clusterrole) pour accéder à la stratégie de sécurité de pod :

   1. Définissez et enregistrez un rôle (ou clusterrole) 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. Saisissez la commande suivante pour créer le rôle (ou clusterrole) :

      kubectl create -f <filename>.yaml

      Par exemple :

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

3. Créez la liaison de rôle (ou clusterrolebinding) pour autoriser les pods d'application à utiliser la stratégie de sécurité de pod :

   1. Définissez et enregistrez la liaison de rôle (ou clusterrolebinding) 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. Saisissez la commande suivante pour créer la liaison de rôle (ou clusterrolebinding) :

      kubectl create -f <filename>.yaml

      Par exemple :

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

Après avoir défini une stratégie de sécurité de pod et autorisé les pods d'application à l'utiliser en créant un objet role et un objet rolebinding (ou clusterrole et clusterrolebinding), activez le contrôleur d'admission PodSecurityPolicy du cluster (s'il n'est pas déjà activé) afin d'appliquer la stratégie de sécurité de pod.

Pour activer le contrôleur d'admission PodSecurityPolicy lors de la création de clusters via la console, procédez comme suit :

1. Connectez-vous à la console.

2. Suivez les instructions de création d'un cluster dans Utilisation de la console pour créer un cluster avec les paramètres définis explicitement dans le workflow Création personnalisée, sélectionnez Afficher les options avancées, puis sélectionnez l'option Stratégies de sécurité de Pod - Appliqué. Cette option active le contrôleur d'admission PodSecurityPolicy.

   Aucun pod d'application ne sera accepté dans le nouveau cluster, sauf s'il existe des stratégies de sécurité de pod appropriées, ainsi que des rôles (ou clusterroles) et des liaisons de rôle (ou clusterrolebindings) permettant d'associer les pods aux stratégies.

3. Suivez les instructions pour définir les autres détails du cluster, puis sélectionnez Créer un cluster afin de créer le cluster.

4. Suivez les instructions dans Création d'une stratégie de sécurité de pod pour les pods d'application afin de créer des stratégies de sécurité de pod pour le contrôleur d'admission PodSecurityPolicy, à appliquer lors de l'acceptation de pods dans le nouveau cluster.

Pour activer le contrôleur d'admission PodSecurityPolicy dans des clusters existants via la console, procédez comme suit :

1. Suivez les instructions dans Création d'une stratégie de sécurité de pod pour les pods d'application afin de créer des stratégies de sécurité de pod pour le contrôleur d'admission PodSecurityPolicy, à appliquer lors de l'acceptation de pods dans le cluster existant.

   Nous vous recommandons vivement de vérifier d'abord les stratégies de sécurité de pod dans un environnement de développement ou de test. De cette façon, vous pouvez être sûr que les stratégies de sécurité de pod fonctionnent comme vous le souhaitez et autorisent correctement les pods à démarrer sur le cluster (ou le leur interdisent).

2. Ouvrez le menu de navigation et sélectionnez Services de développeur. Sous Conteneurs et artefacts, sélectionnez Clusters Kubernetes (OKE).
3. Choisissez un compartiment sur lequel vous êtes autorisé à travailler.
4. Sur la page Liste des groupes, sélectionnez le nom du cluster à modifier.
5. Dans l'onglet Détails du cluster, sélectionnez Non appliqué en regard de Stratégies de sécurité de Pod.

6. Dans la fenêtre Stratégies de sécurité de pod, sélectionnez Appliqué.

   Désormais, aucun nouveau pod d'application ne sera accepté dans le cluster, sauf s'il existe des stratégies de sécurité de pod appropriées, ainsi que des objets roles (ou clusterroles) et rolebindings (ou clusterrolebindings) permettant d'associer les pods aux stratégies. Tous les pods actuellement en cours d'exécution continueront de l'être.

7. Sélectionnez Enregistrer les modifications.

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

1. Ouvrez le menu de navigation et sélectionnez Services de développeur. Sous Conteneurs et artefacts, sélectionnez Clusters Kubernetes (OKE).
2. Choisissez un compartiment sur lequel vous êtes autorisé à travailler.
3. Sur la page Liste des groupes, sélectionnez le nom du cluster à modifier.
4. Dans l'onglet Détails du cluster, sélectionnez Non appliqué en regard de Stratégies de sécurité de Pod.

5. Dans la fenêtre Stratégies de sécurité de Pod, sélectionnez Non appliqué.

   A partir de maintenant, les nouveaux pods d'application seront acceptés dans le cluster sans que des stratégies de sécurité de pod, des rôles (ou clusterroles) et des liaisons de rôle (ou clusterrolebindings) soient requis. Tous les pods actuellement en cours d'exécution continueront de l'être.

6. Sélectionnez Enregistrer les modifications.

Pour plus d'informations sur l'utilisation de l'API et la signature des demandes, reportez-vous à la documentation relative à l'API REST et à Informations d'identification de sécurité. Pour plus d'informations sur les kits SDK, reportez-vous à Kits SDK et interface de ligne de commande.

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

• Opération CreateCluster lors de la création de clusters.
• Opération UpdateCluster lors de la modification de clusters existants.

La stratégie de sécurité pod, ainsi que les objets clusterrole et clusterrolebinding associés, des pods du système Kubernetes dotés de privilèges sont automatiquement créés lorsque vous activez le contrôleur d'admission PodSecurityPolicy d'un cluster. Cela autorise l'exécution de tous les pods 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