Skip to main content
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Gerencie a autorização e o controle de acesso do Trident

PDFs

Trident Protect utiliza o modelo Kubernetes de controle de acesso baseado em funções (RBAC). Por padrão, Trident Protect fornece um único namespace de sistema e sua respectiva conta de serviço padrão. Se sua organização possui muitos usuários ou necessidades de segurança específicas, você pode utilizar os recursos de RBAC do Trident Protect para obter um controle mais granular sobre o acesso a recursos e namespaces.

O administrador do cluster sempre tem acesso aos recursos no namespace padrão trident-protect e também pode acessar recursos em todos os outros namespaces. Para controlar o acesso a recursos e aplicativos, você precisa criar namespaces adicionais e adicionar recursos e aplicativos a esses namespaces.

Observe que nenhum usuário pode criar CRs de gerenciamento de dados de aplicativos no namespace `trident-protect`padrão. Você precisa criar CRs de gerenciamento de dados de aplicativos em um namespace de aplicativo (como prática recomendada, crie CRs de gerenciamento de dados de aplicativos no mesmo namespace do aplicativo associado).

Observação

Somente os administradores devem ter acesso aos objetos de recursos personalizados privilegiados do Trident Protect, que incluem:

  • AppVault: requer dados de credencial do bucket

  • AutoSupportBundle: coleta métricas, registros e outros dados confidenciais do Trident Protect

  • AutoSupportBundleSchedule: gerencia os agendamentos de coleta de logs

Como prática recomendada, use RBAC para restringir o acesso a objetos privilegiados a administradores.

Para obter mais informações sobre como o RBAC regula o acesso a recursos e namespaces, consulte o "Documentação do Kubernetes RBAC".

Para obter informações sobre contas de serviço, consulte o "Documentação da conta de serviço do Kubernetes".

Exemplo: gerenciar o acesso para dois grupos de usuários

Por exemplo, uma organização possui um administrador de cluster, um grupo de usuários de engenharia e um grupo de usuários de marketing. O administrador de cluster executaria as seguintes tarefas para criar um ambiente onde o grupo de engenharia e o grupo de marketing tenham acesso apenas aos recursos atribuídos aos seus respectivos namespaces.

Etapa 1: crie um espaço de nomes para conter os recursos de cada grupo

Criar um namespace permite separar recursos logicamente e controlar melhor quem tem acesso a esses recursos.

Passos

  1. Crie um namespace para o grupo de engenharia:

    kubectl create ns engineering-ns

  2. Crie um namespace para o grupo de marketing:

    kubectl create ns marketing-ns

Etapa 2: crie novas contas de serviço para interagir com os recursos em cada namespace

Cada novo namespace que você cria vem com uma conta de serviço padrão, mas você deve criar uma conta de serviço para cada grupo de usuários para que possa dividir ainda mais os privilégios entre grupos no futuro, se necessário.

Passos

  1. Crie uma conta de serviço para o grupo de engenharia:

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

  2. Crie uma conta de serviço para o grupo de marketing:

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

Etapa 3: crie um segredo para cada nova conta de serviço

Uma chave secreta da conta de serviço é usada para autenticar com a conta de serviço e pode ser facilmente excluída e recriada se for comprometida.

Passos

  1. Crie um segredo para a conta de serviço de engenharia:

    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. Crie um segredo para a conta do serviço de 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

Etapa 4: Crie um objeto RoleBinding para vincular o objeto ClusterRole a cada nova conta de serviço

Um objeto ClusterRole padrão é criado quando você instala Trident Protect. Você pode vincular esse ClusterRole à conta de serviço criando e aplicando um objeto RoleBinding.

Passos

  1. Vincule o ClusterRole à conta de serviço de engenharia:

    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. Vincule o ClusterRole à conta de serviço de 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

Etapa 5: testar permissões

Teste se as permissões estão corretas.

Passos

  1. Confirme se os usuários de engenharia podem acessar os recursos de engenharia:

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

  2. Confirme que os usuários de engenharia não podem acessar os recursos de marketing:

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

Etapa 6: conceder acesso a objetos AppVault

Para executar tarefas de gerenciamento de dados, como backups e snapshots, o administrador do cluster precisa conceder acesso a objetos AppVault a usuários individuais.

Passos

  1. Crie e aplique um arquivo YAML de combinação de AppVault e segredo que conceda a um usuário acesso a um AppVault. Por exemplo, o seguinte CR concede acesso a um AppVault ao usuário 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. Crie e aplique uma Role CR para permitir que os administradores do cluster concedam acesso a recursos específicos em um namespace. Por exemplo:

    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. Crie e aplique uma RoleBinding CR para vincular as permissões ao usuário eng-user. Por exemplo:

    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. Verifique se as permissões estão corretas.

    1. Tentativa de recuperar informações do objeto AppVault para todos os namespaces:

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

      Você deverá ver uma saída semelhante à seguinte:

      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. Teste para verificar se o usuário consegue obter as AppVault informações às quais agora tem permissão de acesso:

      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

      Você deverá ver uma saída semelhante à seguinte:

    yes
Resultado

Os usuários aos quais você concedeu permissões do AppVault devem poder usar objetos AppVault autorizados para operações de gerenciamento de dados do aplicativo e não devem poder acessar recursos fora dos namespaces atribuídos nem criar novos recursos aos quais não tenham acesso.