TKG sur le Superviseur prend en charge la sécurité de l'espace à l'aide du contrôleur d'admission de stratégie de sécurité de l'espace, qui est activé par défaut pour les clusters Tanzu Kubernetes à l'aide de TKR v1.24 et versions antérieures.

Condition préalable : TKR 1.24 et versions antérieures

Cette rubrique s'applique aux clusters TKG sur le Superviseur qui sont provisionnés avec TKR v1.24 et versions antérieures. Par défaut, ces Versions de Tanzu Kubernetes utilisent le contrôleur d'admission de stratégie de sécurité de l'espace.

Le successeur du contrôleur d'admission de stratégie de sécurité de l'espace est le contrôleur d'admission de sécurité de l'espace. Les clusters TKG sur le Superviseur provisionnés avec TKR v1.25 et versions ultérieures utilisent le contrôleur d'admission de sécurité de l'espace. Reportez-vous à la section Configurer PSA pour TKR 1.25 et versions ultérieures.

Contrôleur d'admission de stratégie de sécurité de l'espace

Les stratégies de sécurité de l'espace (PSP) Kubernetes sont des ressources au niveau du cluster qui contrôlent la sécurité des espaces. L'utilisation des PSP vous permet de contrôler les types d'espaces qui peuvent être déployés et les types de comptes qui peuvent les déployer.

Une ressource PodSecurityPolicy définit un ensemble de conditions qu'un espace doit respecter pour être déployé. Si les conditions ne sont pas remplies, l'espace ne peut pas être déployé. Une stratégie PodSecurityPolicy unique doit valider un espace dans son intégralité. Un espace ne peut pas avoir certaines de ses règles dans une stratégie et d'autres dans une autre stratégie. Pour plus d'informations, reportez-vous aux sections Pod Security Policies et RBAC de la documentation Kubernetes.

Il existe différentes façons d'implémenter l'utilisation de stratégies de sécurité de l'espace dans Kubernetes. L'approche classique consiste à utiliser des objets de contrôle d'accès basé sur les rôles (RBAC). ClusterRole et ClusterRoleBinding s'appliquent à l'échelle du cluster. Rôle et RoleBinding s'appliquent à un espace de noms spécifique. Si une liaison RoleBinding est utilisée, elle permet uniquement aux espaces d'être exécutés dans le même espace de noms que la liaison. Pour plus d'informations, reportez-vous à la section RBAC de la documentation Kubernetes.

Il existe deux façons de créer des espaces Kubernetes : directement ou indirectement. Créez un espace directement en déployant une spécification d'espace avec votre compte d'utilisateur. Créez un espace indirectement en définissant des ressources de niveau supérieur, telles que Deployment ou DaemonSet. Dans ce cas, un compte de service crée l'espace sous-jacent. Pour plus d'informations, reportez-vous à la section sur les comptes de service de la documentation Kubernetes.

Pour utiliser les PSP de manière efficace, vous devez tenir compte des deux workflows de création d'espace : direct et indirect. Si un utilisateur crée directement un espace, la PSP liée au compte d'utilisateur contrôle l'opération. Si un utilisateur crée un espace au moyen d'un compte de service, la PSP doit être liée au compte de service utilisé pour créer l'espace. Si aucun compte de service n'est spécifié dans la spécification d'espace, le compte de service par défaut de l'espace de noms est utilisé.

Stratégie PodSecurityPolicy par défaut pour les clusters TKG

Le tableau répertorie et décrit les stratégies de sécurité de l'espace par défaut privilégiées et restreintes pour les clusters TKG et le ClusterRole par défaut associé à chaque stratégie.
Tableau 1. PodSecurityPolicy par défaut avec ClusterRole associé
PSP par défaut Autorisation Description ClusterRole par défaut associé
vmware-system-privileged Exécuter comme n'importe lequel PSP permissive. Équivalente à l'exécution d'un cluster sans contrôleur d'admission PSP activé. psp:vmware-system-privileged pouvez utiliser cette PSP
vmware-system-restricted Doit être exécuté en tant que non-racine PSP restrictive. N'autorise pas l'accès privilégié aux conteneurs d'espaces, ce qui bloque les escalades possibles à la racine et nécessite l'utilisation de plusieurs mécanismes de sécurité. psp:vmware-system-restricted pouvez utiliser cette PSP

Liaisons de rôles et de ClusterRole pour les clusters TKG

TKG sur le Superviseur ne fournit pas de liaisons RoleBinding et ClusterRoleBinding par défaut pour les clusters TKG. Des exemples que vous pouvez utiliser sont fournis dans cette documentation. Reportez-vous à la section Appliquer la stratégie de sécurité de l'espace par défaut aux clusters de TKG.

Un utilisateur vCenter Single Sign-On disposant de l'autorisation Modification sur un Espace de noms vSphere est attribué au rôle cluster-admin pour tout cluster Tanzu Kubernetes déployé dans cet espace de noms. Un administrateur de cluster authentifié peut utiliser implicitement la PSP vmware-system-privileged. Bien qu'elle ne soit pas techniquement une liaison ClusterRoleBinding, son effet est identique.

L'administrateur de cluster doit définir des liaisons pour autoriser ou limiter les types d'espaces que les utilisateurs peuvent déployer sur un cluster. Si une liaison RoleBinding est utilisée, celle-ci permet uniquement aux espaces d'être exécutés dans le même espace de noms que la liaison. Cette opération peut être couplée avec des groupes de systèmes pour accorder l'accès à tous les espaces exécutés dans l'espace de noms. Le rôle authenticated est attribué aux utilisateurs non-administrateurs qui s'authentifient auprès du cluster et ceux-ci peuvent être liés à la PSP par défaut.

Le comportement suivant est appliqué pour tout cluster TKG nécessitant une stratégie de sécurité d'espace :
  • Un administrateur de cluster peut créer des espaces privilégiés directement dans n'importe quel espace de noms à l'aide de son compte d'utilisateur.
  • Un administrateur de cluster peut créer des ressources Deployments, StatefulSets et DaemonSet (chacune d'elles créant également des espaces privilégiés) dans l'espace de noms kube-system. Si vous souhaitez utiliser un espace de noms Kubernetes différent, créez une liaison RoleBinding pour celui-ci ou une liaison ClusterRoleBinding.
  • Un administrateur de cluster peut créer ses propres PSP (en plus des deux PSP par défaut) et lier ces PSP à tous les utilisateurs. Si vous définissez votre propre PSP, reportez-vous à Ordre des stratégies dans la documentation Kubernetes.
  • Aucun utilisateur authentifié ne peut créer des espaces privilégiés ou sans privilèges tant que l'administrateur du cluster n'a pas lié les PSP aux utilisateurs authentifiés.

Pour obtenir des exemples de liaison, reportez-vous à Appliquer la stratégie de sécurité de l'espace par défaut aux clusters de TKG.