Skip to main content
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Gestisci l'autorizzazione di protezione e il controllo degli accessi Trident

Collaboratori netapp-aruldeepa
PDF

Trident Protect utilizza il modello Kubernetes di controllo degli accessi basato sui ruoli (RBAC). Per impostazione predefinita, Trident Protect fornisce un singolo namespace di sistema e il relativo account di servizio predefinito. Se la tua organizzazione ha molti utenti o esigenze di sicurezza specifiche, puoi utilizzare le funzionalità RBAC di Trident Protect per ottenere un controllo più granulare sull'accesso alle risorse e agli spazi dei nomi.

L'amministratore del cluster ha sempre accesso alle risorse predefinite trident-protect namespace e può anche accedere alle risorse in tutti gli altri namespace. Per controllare l'accesso alle risorse e alle applicazioni, è necessario creare namespace aggiuntivi e aggiungere risorse e applicazioni a tali namespace.

Si noti che nessun utente può creare CR di gestione dei dati delle applicazioni nell'impostazione predefinita trident-protect spazio dei nomi. È necessario creare CR di gestione dei dati dell'applicazione in uno spazio dei nomi dell'applicazione (come buona pratica, creare CR di gestione dei dati dell'applicazione nello stesso spazio dei nomi dell'applicazione associata).

Nota

Solo gli amministratori dovrebbero avere accesso agli oggetti di risorse personalizzati protetti Trident privilegiati, tra cui:

  • AppVault: richiede i dati delle credenziali del bucket

  • AutoSupportBundle: raccoglie metriche, registri e altri dati sensibili Trident Protect

  • AutoSupportBundleSchedule: Gestisce le pianificazioni della raccolta dei log

Come buona pratica, utilizzare RBAC per limitare l'accesso agli oggetti privilegiati ai soli amministratori.

Per ulteriori informazioni su come RBAC regola l'accesso alle risorse e agli spazi dei nomi, fare riferimento a "Documentazione di Kubernetes RBAC" .

Per informazioni sugli account di servizio, fare riferimento a "Documentazione dell'account di servizio Kubernetes" .

Esempio: Gestire l'accesso per due gruppi di utenti

Ad esempio, un'organizzazione ha un amministratore del cluster, un gruppo di utenti di ingegneria e un gruppo di utenti di marketing. L'amministratore del cluster dovrebbe completare le seguenti attività per creare un ambiente in cui il gruppo di ingegneria e il gruppo di marketing abbiano accesso solo alle risorse assegnate ai rispettivi namespace.

Passaggio 1: creare uno spazio dei nomi per contenere le risorse per ciascun gruppo

La creazione di uno spazio dei nomi consente di separare logicamente le risorse e di controllare meglio chi ha accesso a tali risorse.

Passi

  1. Creare uno spazio dei nomi per il gruppo di ingegneria:

    kubectl create ns engineering-ns

  2. Crea uno spazio dei nomi per il gruppo di marketing:

    kubectl create ns marketing-ns

Passaggio 2: creare nuovi account di servizio per interagire con le risorse in ogni spazio dei nomi

Ogni nuovo namespace creato è dotato di un account di servizio predefinito, ma è consigliabile creare un account di servizio per ogni gruppo di utenti, in modo da poter suddividere ulteriormente i privilegi tra i gruppi in futuro, se necessario.

Passi

  1. Creare un account di servizio per il gruppo di ingegneria:

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

  2. Crea un account di servizio per il gruppo marketing:

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

Passaggio 3: creare un segreto per ogni nuovo account di servizio

Un segreto dell'account di servizio viene utilizzato per l'autenticazione con l'account di servizio e può essere facilmente eliminato e ricreato se compromesso.

Passi

  1. Crea un segreto per l'account del servizio di ingegneria:

    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. Crea un segreto per l'account del servizio di 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

Passaggio 4: creare un oggetto RoleBinding per associare l'oggetto ClusterRole a ciascun nuovo account di servizio

Quando si installa Trident Protect, viene creato un oggetto ClusterRole predefinito. È possibile associare questo ClusterRole all'account di servizio creando e applicando un oggetto RoleBinding.

Passi

  1. Associare ClusterRole all'account del servizio di ingegneria:

    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. Associa ClusterRole all'account del servizio di 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

Passaggio 5: testare le autorizzazioni

Verificare che i permessi siano corretti.

Passi

  1. Verificare che gli utenti di ingegneria possano accedere alle risorse di ingegneria:

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

  2. Verificare che gli utenti di ingegneria non possano accedere alle risorse di marketing:

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

Passaggio 6: Concedi l'accesso agli oggetti AppVault

Per eseguire attività di gestione dei dati quali backup e snapshot, l'amministratore del cluster deve concedere l'accesso agli oggetti AppVault ai singoli utenti.

Passi

  1. Crea e applica un file YAML con combinazione di AppVault e segreto che garantisce a un utente l'accesso a un AppVault. Ad esempio, il seguente CR concede l'accesso a un AppVault all'utente 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. Creare e applicare un CR di ruolo per consentire agli amministratori del cluster di concedere l'accesso a risorse specifiche in uno spazio dei nomi. Per esempio:

    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. Creare e applicare un CR RoleBinding per associare le autorizzazioni all'utente eng-user. Per esempio:

    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. Verificare che le autorizzazioni siano corrette.

    1. Tentativo di recuperare le informazioni sugli oggetti AppVault per tutti gli spazi dei nomi:

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

      Dovresti vedere un output simile al seguente:

      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. Prova a verificare se l'utente riesce a ottenere le informazioni di AppVault a cui ora ha l'autorizzazione ad accedere:

      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

      Dovresti vedere un output simile al seguente:

    yes
Risultato

Gli utenti a cui hai concesso le autorizzazioni AppVault devono essere in grado di utilizzare oggetti AppVault autorizzati per le operazioni di gestione dei dati dell'applicazione e non devono essere in grado di accedere a risorse esterne agli spazi dei nomi assegnati o di creare nuove risorse a cui non hanno accesso.