Sécurité de l'espace

Cette rubrique explique comment configurer des contrôleurs d'admission de sécurité des espaces (PSA) pour sécuriser les clusters de charge de travail déployés par Tanzu Kubernetes Grid (TKG).

Pour les clusters ou les espaces de noms dans les clusters exécutant Kubernetes v1.23 et versions ultérieures, TKG prend en charge l'application de stratégies de sécurité des espaces de type privileged, baseline ou restricted via le contrôleur d'admission de sécurité des espaces (PSA).

Arrière-plan : Contrôleurs PSA

Dans Kubernetes, les contrôleurs PSA vous permettent de configurer des stratégies de sécurité de charge de travail selon deux axes :

Les profils désignent les niveaux d'autorisation auxquels l'espace de charge de travail peut s'exécuter : privileged, baseline et restricted, du moins au plus restrictif.
Les Modes spécifient les actions déclenchées lorsqu'une tentative de création de l'espace enfreint un profil : warn génère un avertissement, audit ajoute une entrée de journal d'audit et enforce bloque la création de l'espace.

Vous pouvez configurer des contrôleurs PSA pour qu'ils fonctionnent sur des espaces de noms spécifiques ou à l'échelle du cluster. Par exemple, vous pouvez configurer un cluster pour qu'il déclenche un journal d'audit lorsqu'un espace baseline enfreint une stratégie de sécurité, et bloquer un espace restricted s'il enfreint la stratégie.

Pour plus d'informations, reportez-vous à la section Normes de sécurité des espaces dans la documentation de Kubernetes.

Migration à partir des stratégies de sécurité des espaces

Le système PSA remplace les stratégies de sécurité des espaces (PSP), qui ont été déconseillées dans Kubernetes v1.21 et supprimées dans la version v1.25, comme décrit dans les notes de mise à jour de Kubernetes v1.25.

Les PSP pour les nœuds ont été déconseillées dans TKG v2.1, afin de refléter leur obsolescence dans Kubernetes. Pour savoir comment migrer des espaces à partir de PSP vers le contrôleur PSA, reportez-vous à la section Migrer depuis PodSecurityPolicy vers le contrôleur d'admission PodSecurity intégré.

Configuration de PSA dans TKG

Les paramètres PSA par défaut pour un cluster de charge de travail TKG dépendent de la version de Kubernetes qu'il exécute :

Kubernetes v1.26 et v1.27, natif à TKG v2.3 et v2.4 :
- Modes warn et audit : restricted
- Mode enforce : aucun paramètre
Kubernetes v1.25 et v1.24, natif vers TKG v2.2 et v2.1 :
- Modes warn et audit : baseline
- Mode enforce : aucun paramètre

Les paramètres PSA par défaut pour les clusters exécutant les versions natives de Kubernetes dans TKG 2.4, v2.3, v2.2 et v2.1 garantissent que les espaces continuent à s'exécuter lors de la migration des PSP vers la PSA, même s'ils génèrent des avertissements sur la violation de la stratégie :

À partir de TKG v2.2, tous les composants TKG internes sont conformes au profil PSA restricted.

Configuration d'une PSA à l'échelle du cluster

Vous pouvez configurer un nouveau cluster avec la PSA à l'échelle du cluster ou modifier la PSA d'un cluster existant.

PSA à l'échelle du cluster pour un nouveau cluster

Pour configurer une PSA à l'échelle du cluster pour un nouveau cluster de charge de travail, définissez POD_SECURITY_STANDARD_DEACTIVATED dans son fichier de configuration de cluster sur false et définissez les autres variables POD_SECURITY_STANDARD_*, comme décrit dans le tableau Normes de sécurité des espaces de la Référence de variable de fichier de configuration.

POD_SECURITY_STANDARD_DEACTIVATED
POD_SECURITY_STANDARD_AUDIT
POD_SECURITY_STANDARD_WARN
POD_SECURITY_STANDARD_ENFORCE

Vous pouvez également générer le manifeste du cluster comme étape 1 du processus en deux étapes décrit dans la section Créer un cluster basé sur une classe, puis modifier les valeurs de variables podSecurityStandard dans la spécification Cluster de la section Modifier la PSA pour un cluster basé sur une classe existante ci-dessous avant de créer le cluster à l'étape 2.

Modifier la PSA pour un cluster basé sur une classe existante

Pour modifier la configuration PSA d'un cluster basé sur une classe existante :

Ouvrez la spécification d'objet Cluster dans un éditeur :
```
kubectl edit -namespace NAMESPACE CLUSTER
```
Modifiez les valeurs du bloc podSecurityStandard sous spec.topology.variables :
```
- name: podSecurityStandard

  value:
    deactivated: DEACTIVATED
    audit: AUDIT-PROFILE
    enforce: ENFORCE-PROFILE
    warn: WARN-PROFILE
    auditVersion: AUDIT-VERSION
    enforceVersion: ENFORCE-VERSION
    warnVersion: WARN-VERSION
    exemptions:
      namespaces: [EXEMPT-NS]
```
Où :
- DEACTIVATED est false pour appliquer une PSA à l'échelle du cluster et true par ailleurs
- AUDIT-PROFILE, ENFORCE-PROFILE et WARN-PROFILE sont les profils PSA de chaque mode, qui peuvent être "privileged", "baseline" ou "restricted". La valeur par défaut est "privileged".
- Les valeurs de VERSION correspondent à la version de Kubernetes pour les trois modes, par exemple "v1.26".
- EXEMPT-NS est une liste séparée par des virgules d'espaces de noms à exclure du contrôle PSA.
Remarque : Les espaces de noms système kube-system et tkg-system seront toujours exclus du contrôle PSA.
Une fois que vous avez appliqué la spécification d'objet Cluster, les modifications doivent être appliquées aux nœuds de plan de contrôle du cluster.

Modifier la PSA d'un cluster hérité existant

Pour modifier la configuration PSA d'un cluster hérité existant :

Récupérez le fichier de spécification AdmissionConfiguraton actuel à partir de l'objet KubeadmControlPlane et enregistrez-le localement, par exemple :

kubectl get kcp my-cluster-control-plane --template='{{ range $v := .spec.kubeadmConfigSpec.files }}{{ if eq $v.path "/etc/kubernetes/admission-control-config.yaml" }}{{ $v.content }}{{ end }}{{ end }}' > admission-config.yaml

Modifiez le fichier admission-config.yaml dans la nouvelle configuration. Par exemple, le suivant définit enforce sur baseline et conserve les modes audit et warn à restricted:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
  apiVersion: pod-security.admission.config.k8s.io/v1beta1
  kind: PodSecurityConfiguration
  defaults:
    enforce: "baseline"
    enforce-version: "v1.24"
    audit: "restricted"
    audit-version: "v1.24"
    warn: "restricted"
    warn-version: "v1.24"
  exemptions:
    usernames: []
    runtimeClasses: []
    namespaces: ["kube-system", "tkg-system"]

Modifiez la spécification d'objet KubeadmControlPlane et remplacez son entrée de tableau dans spec.kubeadmConfigSpec.files par notre nouveau fichier de configuration.
Une fois que vous avez appliqué la spécification d'objet KubeadmControlPlane, les modifications doivent être appliquées aux nœuds de plan de contrôle du cluster.

Vérifier la conformité avant d'ajouter ou de modifier une configuration PSA

Avant d'ajouter ou de modifier une PSA, évitez les interruptions de service inattendues en vous assurant que toutes les charges de travail existantes dans le cluster ou l'espace de noms de la PSA seront conformes aux nouveaux paramètres de la stratégie.

Vous pouvez évaluer si les espaces s'exécutant dans un espace de noms existant sont conformes à une stratégie donnée en exécutant kubectl label --overwrite --dry-run=server:

kubectl label --overwrite --dry-run=server namespace <namespace> pod-security.kubernetes.io/enforce=<policy>

Les mêmes informations sont écrites dans les journaux d'audit, lors de la configuration du mode audit de l'admission de la sécurité des espaces ou lors de l'application de ressources à un cluster et de la configuration du mode warn.

Des informations à jour sur les différents profils pour la sécurité des espaces sont disponibles dans la documentation de Kubernetes.