Les clusters de service TKG utilisant TKR 1.24 et versions antérieures incluent une stratégie de sécurité de l'espace par défaut à laquelle vous pouvez vous lier pour le déploiement de la charge de travail privilégiée et restreinte.

Application de la stratégie de sécurité de l'espace par défaut à l'aide de liaisons de rôles et de ClusterRole

vSphere IaaS control plane fournit la Stratégie de sécurité de l'espace par défaut que vous pouvez appliquer aux clusters TKG sur le Superviseur exécutant TKR 1.24 et versions antérieures. Pour ce faire, créez des objets RoleBinding et ClusterRoleBinding qui font référence à la Stratégie de sécurité de l'espace par défaut.
Note : Reportez-vous à la documentation de Kubernetes pour créer votre propre stratégie de sécurité de l'espace.

Une liaison RoleBinding accorde des autorisations dans un espace de noms spécifique. Une liaison ClusterRoleBinding accorde des autorisations à l'échelle du cluster. La décision d'utiliser RoleBindings ou ClusterRoleBinding dépend de votre cas d'utilisation . Par exemple, si vous utilisez une liaison ClusterRoleBinding et configurez des sujets pour qu'ils utilisent system:serviceaccounts:<namespace>, vous pouvez établir une liaison à un PSP avant la création de l'espace de noms. Pour plus d'informations, consultez RoleBinding et ClusterRoleBinding dans la documentation de Kubernetes.

Les sections suivantes fournissent des commandes YAML et CLI pour la création d'objets RoleBinding et ClusterRoleBinding qui autorisent l'utilisation de la Stratégie de sécurité de l'espace par défaut.

Exemple 1 : ClusterRoleBinding pour exécuter un ensemble privilégié de charges de travail

La commande kubectl suivante crée une liaison ClusterRoleBinding qui accorde aux utilisateurs authentifiés un accès à un ensemble de charges de travail à l'aide de la PSP par défaut ( vmware-system-privileged).
Avertissement : L'application de l'exemple 1, de manière déclarative ou impérative, permet le déploiement de charges de travail privilégiées à l'échelle du cluster. En effet, l'exemple 1 désactive les contrôles de sécurité natifs et doit être utilisé avec précaution et connaissance complète des implications. Pour une sécurité renforcée, reportez-vous aux exemples 2, 3 et 4. 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: psp:privileged
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  resourceNames:
  - vmware-system-privileged
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: all:psp:privileged
roleRef:
  kind: ClusterRole
  name: psp:privileged
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io
Plutôt que d'appliquer le fichier YAML, vous pouvez exécuter la commande kubectl suivante. 
kubectl create clusterrolebinding default-tkg-admin-privileged-binding --clusterrole=psp:vmware-system-privileged --group=system:authenticated

Exemple 2 : RoleBinding pour exécuter un ensemble privilégié de charges de travail

La commande kubectl suivante crée une liaison RoleBinding qui accorde l'accès à tous les comptes de service dans l'espace de noms par défaut afin d'exécuter un ensemble privilégié de charges de travail à l'aide de la PSP par défaut ( vmware-system-privileged). 
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: rolebinding-default-privileged-sa-ns_default
  namespace: default
roleRef:
  kind: ClusterRole
  name: psp:vmware-system-privileged
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts
Plutôt que d'appliquer le fichier YAML, vous pouvez exécuter la commande kubectl suivante. 
kubectl create rolebinding rolebinding-default-privileged-sa-ns_default --namespace=default --clusterrole=psp:vmware-system-privileged --group=system:serviceaccounts

Exemple 3 : ClusterRoleBinding pour exécuter un ensemble restreint de charges de travail

Le fichier YAML suivant crée une liaison ClusterRoleBinding qui accorde aux utilisateurs authentifiés un accès à l'échelle du cluster afin d'exécuter un ensemble restreint de charges de travail à l'aide de la PSP par défaut (vmware-system-restricted).

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: psp:authenticated
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp:vmware-system-restricted

Plutôt que d'appliquer le fichier YAML, vous pouvez exécuter la commande kubectl suivante.

kubectl create clusterrolebinding psp:authenticated --clusterrole=psp:vmware-system-restricted --group=system:authenticated

Exemple 4 : RoleBinding pour exécuter un ensemble restreint de charges de travail

Le fichier YAML suivant crée une liaison RoleBinding qui accorde l'accès à tous les comptes de service dans un espace de noms spécifique afin d'exécuter un ensemble restreint de charges de travail à l'aide de la PSP par défaut (vmware-system-restricted).

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: psp:serviceaccounts
  namespace: some-namespace
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp:vmware-system-restricted
Plutôt que d'appliquer le fichier YAML, vous pouvez exécuter la commande kubectl suivante.
Note : Remplacez « some-namespace » par l'espace de noms cible. 
kubectl create rolebinding psp:serviceaccounts --clusterrole=psp:vmware-system-restricted --group=system:serviceaccounts -n some-namespace

Exemple de rôle pour la stratégie de sécurité de l'espace

Si vous définissez votre propre stratégie de sécurité d'espace (PSP) pour déployer des charges de travail, reportez-vous à cet exemple pour créer un rôle ou ClusterRole faisant référence à la PSP personnalisée.

L'exemple montre un rôle lié à une stratégie PodSecurityPolicy. Dans la définition du rôle, le verbe use est accordé au rôle example-role pour une ressource PSP personnalisée que vous définissez. Vous pouvez également utiliser l'une des PSP par défaut. Créez ensuite une liaison.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: example-role
  namespace: tkgs-cluster-ns
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create
  - get
  - list
  - watch
  - update
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - update
  - patch
- apiGroups: 
  - extensions
  resourceNames:
  - CUSTOM-OR-DEFAULT-PSP
  resources:
  - podsecuritypolicies
  verbs:
  - use