Service Tanzu Kubernetes Grid provisionne des clusters Tanzu Kubernetes avec contrôleur d'admission PodSecurityPolicy activé. Cela signifie que la stratégie de sécurité de l'espace est requise pour déployer des charges de travail. Les administrateurs de cluster peuvent déployer des espaces à partir de leur compte d'utilisateur dans n'importe quel espace de noms et à partir de comptes de service dans l'espace de noms kube-system. Pour tous les autres cas d’utilisation, vous devez explicitement vous lier à un objet PodSecurityPolicy. Les clusters incluent des stratégies de sécurité d'espace par défaut auxquelles vous pouvez vous lier. Vous pouvez aussi créer votre propre stratégie de sécurité d'espace.
À propos des stratégies de sécurité de l'espace Kubernetes
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.
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.
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 utiliser les PSP de manière efficace, vous devez tenir compte des deux workflows de création d'espace. 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é.
Pour plus d'informations, consultez les Stratégies de sécurité de l'espace, RBAC et les Comptes de service dans la documentation Kubernetes.
Stratégie PodSecurityPolicy par défaut pour les clusters Tanzu Kubernetes
| 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 |
Aucune liaison par défaut pour les clusters Tanzu Kubernetes
Service Tanzu Kubernetes Grid ne fournit pas de liaisons RoleBinding et ClusterRoleBinding par défaut pour les clusters Tanzu Kubernetes.
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. Reportez-vous à la section Accorder aux développeurs l'accès aux clusters Tanzu Kubernetes.
Effet de la stratégie PodSecurityPolicy par défaut sur les clusters Tanzu Kubernetes
- 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 différent, reportez-vous à la section Didacticiel Tanzu Kubernetes Guestbook.
- 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. Reportez-vous à la section Didacticiel Tanzu Kubernetes Guestbook.
