Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Gérer l'autorisation et le contrôle d'accès Trident Protect

Contributeurs netapp-aruldeepa
PDF

Trident Protect utilise le modèle Kubernetes de contrôle d'accès basé sur les rôles (RBAC). Par défaut, Trident Protect fournit un seul espace de noms système et son compte de service par défaut associé. Si vous avez une organisation avec de nombreux utilisateurs ou des besoins de sécurité spécifiques, vous pouvez utiliser les fonctionnalités RBAC de Trident Protect pour obtenir un contrôle plus précis sur l'accès aux ressources et aux espaces de noms.

L'administrateur du cluster a toujours accès aux ressources par défaut trident-protect espace de noms, et peut également accéder aux ressources de tous les autres espaces de noms. Pour contrôler l'accès aux ressources et aux applications, vous devez créer des espaces de noms supplémentaires et y ajouter des ressources et des applications.

Notez qu'aucun utilisateur ne peut créer de demandes de changement (CR) de gestion des données d'application par défaut. trident-protect espace de noms. Vous devez créer des CR de gestion des données d'application dans un espace de noms d'application (il est recommandé de créer les CR de gestion des données d'application dans le même espace de noms que leur application associée).

Remarque

Seuls les administrateurs devraient avoir accès aux objets de ressources personnalisés protégés par Trident , notamment :

  • AppVault : Nécessite des données d'identification de compartiment

  • AutoSupportBundle : Collecte les métriques, les journaux et autres données sensibles protégées par Trident

  • AutoSupportBundleSchedule : Gère les planifications de collecte des journaux

Il est recommandé d'utiliser le contrôle d'accès basé sur les rôles (RBAC) pour limiter l'accès aux objets privilégiés aux seuls administrateurs.

Pour plus d'informations sur la manière dont le RBAC régule l'accès aux ressources et aux espaces de noms, consultez la documentation. "Documentation RBAC Kubernetes" .

Pour plus d'informations sur les comptes de service, veuillez consulter le "Documentation des comptes de service Kubernetes" .

Exemple : Gérer l'accès pour deux groupes d'utilisateurs

Par exemple, une organisation possède un administrateur de cluster, un groupe d'utilisateurs ingénieurs et un groupe d'utilisateurs marketing. L'administrateur du cluster effectuerait les tâches suivantes pour créer un environnement où le groupe d'ingénierie et le groupe marketing n'auraient accès qu'aux ressources attribuées à leurs espaces de noms respectifs.

Étape 1 : Créer un espace de noms pour contenir les ressources de chaque groupe

La création d'un espace de noms vous permet de séparer logiquement les ressources et de mieux contrôler qui y a accès.

Étapes

  1. Créez un espace de noms pour le groupe d'ingénierie :

    kubectl create ns engineering-ns

  2. Créez un espace de noms pour le groupe marketing :

    kubectl create ns marketing-ns

Étape 2 : Créez de nouveaux comptes de service pour interagir avec les ressources de chaque espace de noms

Chaque nouvel espace de noms que vous créez est fourni avec un compte de service par défaut, mais vous devriez créer un compte de service pour chaque groupe d'utilisateurs afin de pouvoir répartir davantage les privilèges entre les groupes à l'avenir si nécessaire.

Étapes

  1. Créer un compte de service pour le groupe d'ingénierie :

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: eng-user
  namespace: engineering-ns

  2. Créer un compte de service pour le groupe marketing :

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: mkt-user
  namespace: marketing-ns

Étape 3 : Créez un secret pour chaque nouveau compte de service

Un secret de compte de service est utilisé pour s'authentifier auprès du compte de service et peut être facilement supprimé et recréé en cas de compromission.

Étapes

  1. Créez un secret pour le compte du service d'ingénierie :

    apiVersion: v1
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: eng-user
  name: eng-user-secret
  namespace: engineering-ns
type: kubernetes.io/service-account-token

  2. Créez un secret pour le compte du service marketing :

    apiVersion: v1
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: mkt-user
  name: mkt-user-secret
  namespace: marketing-ns
type: kubernetes.io/service-account-token

Étape 4 : Créez un objet RoleBinding pour lier l’objet ClusterRole à chaque nouveau compte de service.

Un objet ClusterRole par défaut est créé lors de l'installation de Trident Protect. Vous pouvez lier ce ClusterRole au compte de service en créant et en appliquant un objet RoleBinding.

Étapes

  1. Associez le rôle ClusterRole au compte de service d'ingénierie :

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: engineering-ns-tenant-rolebinding
  namespace: engineering-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: trident-protect-tenant-cluster-role
subjects:
- kind: ServiceAccount
  name: eng-user
  namespace: engineering-ns

  2. Associez le rôle ClusterRole au compte de service marketing :

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: marketing-ns-tenant-rolebinding
  namespace: marketing-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: trident-protect-tenant-cluster-role
subjects:
- kind: ServiceAccount
  name: mkt-user
  namespace: marketing-ns

Étape 5 : Tester les autorisations

Vérifiez que les autorisations sont correctes.

Étapes

  1. Confirmer que les utilisateurs ingénieurs peuvent accéder aux ressources d'ingénierie :

    kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get applications.protect.trident.netapp.io -n engineering-ns

  2. Confirmer que les utilisateurs ingénieurs n'ont pas accès aux ressources marketing :

    kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get applications.protect.trident.netapp.io -n marketing-ns

Étape 6 : Accorder l’accès aux objets AppVault

Pour effectuer des tâches de gestion des données telles que les sauvegardes et les instantanés, l'administrateur du cluster doit accorder l'accès aux objets AppVault aux utilisateurs individuels.

Étapes

  1. Créez et appliquez un fichier YAML combinant AppVault et secret, qui accorde à un utilisateur l'accès à un AppVault. Par exemple, la demande de changement suivante accorde à l'utilisateur l'accès à un AppVault eng-user :

    apiVersion: v1
data:
  accessKeyID: <ID_value>
  secretAccessKey: <key_value>
kind: Secret
metadata:
  name: appvault-for-eng-user-only-secret
  namespace: trident-protect
type: Opaque
---
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
  name: appvault-for-eng-user-only
  namespace: trident-protect # Trident protect system namespace
spec:
  providerConfig:
    azure:
      accountName: ""
      bucketName: ""
      endpoint: ""
    gcp:
      bucketName: ""
      projectID: ""
    s3:
      bucketName: testbucket
      endpoint: 192.168.0.1:30000
      secure: "false"
      skipCertValidation: "true"
  providerCredentials:
    accessKeyID:
      valueFromSecret:
        key: accessKeyID
        name: appvault-for-eng-user-only-secret
    secretAccessKey:
      valueFromSecret:
        key: secretAccessKey
        name: appvault-for-eng-user-only-secret
  providerType: GenericS3

  2. Créez et appliquez un rôle CR pour permettre aux administrateurs de cluster d'accorder l'accès à des ressources spécifiques dans un espace de noms. Par exemple:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: eng-user-appvault-reader
  namespace: trident-protect
rules:
- apiGroups:
  - protect.trident.netapp.io
  resourceNames:
  - appvault-for-enguser-only
  resources:
  - appvaults
  verbs:
  - get

  3. Créez et appliquez une ressource personnalisée RoleBinding pour lier les autorisations à l'utilisateur eng-user. Par exemple:

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: eng-user-read-appvault-binding
  namespace: trident-protect
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: eng-user-appvault-reader
subjects:
- kind: ServiceAccount
  name: eng-user
  namespace: engineering-ns

  4. Vérifiez que les autorisations sont correctes.

    1. Tentative de récupération des informations des objets AppVault pour tous les espaces de noms :

      kubectl get appvaults -n trident-protect --as=system:serviceaccount:engineering-ns:eng-user

      Vous devriez obtenir un résultat similaire à celui-ci :

      Error from server (Forbidden): appvaults.protect.trident.netapp.io is forbidden: User "system:serviceaccount:engineering-ns:eng-user" cannot list resource "appvaults" in API group "protect.trident.netapp.io" in the namespace "trident-protect"

    2. Vérifiez si l'utilisateur peut accéder aux informations AppVault auxquelles il est désormais autorisé à accéder :

      kubectl auth can-i --as=system:serviceaccount:engineering-ns:eng-user get appvaults.protect.trident.netapp.io/appvault-for-eng-user-only -n trident-protect

      Vous devriez obtenir un résultat similaire à celui-ci :

    yes
Résultat

Les utilisateurs auxquels vous avez accordé des autorisations AppVault doivent pouvoir utiliser les objets AppVault autorisés pour les opérations de gestion des données d'application, et ne doivent pas pouvoir accéder à des ressources en dehors des espaces de noms attribués ni créer de nouvelles ressources auxquelles ils n'ont pas accès.