Skip to main content
Une version plus récente de ce produit est disponible.
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 Trident et le contrôle d'accès

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 espace de noms système unique et son compte de service par défaut associé. Si votre organisation compte de nombreux utilisateurs ou a 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 de l'accès aux ressources et aux espaces de noms.

L'administrateur du cluster a toujours accès aux ressources dans l' `trident-protect`namespace par défaut, et peut également accéder aux ressources dans tous les autres namespaces. Pour contrôler l'accès aux ressources et aux applications, vous devez créer des namespaces supplémentaires et ajouter des ressources et des applications à ces namespaces.

Notez qu'aucun utilisateur ne peut créer des CR de gestion des données d'application dans l' `trident-protect`espace de noms par défaut. Vous devez créer des CR de gestion des données d'application dans un espace de noms d'application (comme bonne pratique, créez 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 privilégiés de Trident Protect, notamment :

  • AppVault : Nécessite des identifiants de compartiment

  • AutoSupportBundle : Collecte des métriques, des journaux et d'autres données sensibles Trident Protect

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

En tant que bonne pratique, utilisez le RBAC pour limiter l'accès aux objets privilégiés aux administrateurs.

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

Pour plus d'informations sur les comptes de service, veuillez vous référer au "Documentation du compte de service Kubernetes".

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

Par exemple, une organisation dispose d'un administrateur du cluster, d'un groupe d'utilisateurs ingénieurs et d'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 ont chacun accès uniquement 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 a accès à ces ressources.

Étapes

  1. Créer 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 dans 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 devez créer un compte de service pour chaque groupe d'utilisateurs afin de pouvoir diviser 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 service account

Un secret de compte de service est utilisé pour s'authentifier avec le compte de service et peut facilement être 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. Liez 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. Liez 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

Testez que les autorisations sont correctes.

Étapes

  1. Confirmez 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. Confirmez que les utilisateurs ingénieurs ne peuvent pas accéder 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 à chaque utilisateur.

Étapes

  1. Créez et appliquez un fichier YAML de combinaison AppVault et secret qui accorde à un utilisateur l'accès à un AppVault. Par exemple, le CR suivant accorde l'accès à un AppVault à l'utilisateur 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 Role CR pour permettre aux administrateurs du 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 un CR 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 d'objet AppVault pour tous les espaces de noms :

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

      Vous devriez voir une sortie similaire à la suivante :

      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 obtenir les informations AppVault auxquelles il a désormais accès :

      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 voir une sortie similaire à la suivante :

    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.