Skip to main content
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 Protect.

Colaboradores netapp-aruldeepa
PDFs

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

O administrador do cluster sempre tem acesso aos recursos no ambiente padrão. trident-protect namespace, 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 solicitações de configuração (CRs) de gerenciamento de dados de aplicativos no ambiente padrão. trident-protect espaço de nomes. Você precisa criar solicitações de configuração (CRs) de gerenciamento de dados de aplicativos em um namespace de aplicativo (como prática recomendada, crie as CRs de gerenciamento de dados de aplicativos no mesmo namespace do aplicativo associado).

Observação

Somente os administradores devem ter acesso a objetos de recursos personalizados protegidos por privilégios do Trident , que incluem:

  • AppVault: Requer dados de credenciais do bucket

  • Pacote de Suporte Automático: Coleta métricas, registros e outros dados confidenciais do Trident Protect.

  • AutoSupportBundleSchedule: Gerencia os agendamentos de coleta de logs

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

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

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 do cluster deverá executar 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 espaço de nomes permite separar recursos logicamente e controlar melhor quem tem acesso a esses recursos.

Passos

  1. Crie um espaço de nomes para o grupo de engenharia:

    kubectl create ns engineering-ns

  2. Crie um espaço de nomes 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 os 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. Criar 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 caso seja comprometida.

Passos

  1. Crie um segredo para a conta do 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 o Trident Protect. Você pode vincular essa ClusterRole à conta de serviço criando e aplicando um objeto RoleBinding.

Passos

  1. Vincule a funçã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 a função ClusterRole à conta do 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

Verifique 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 têm acesso aos 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: Conceda acesso aos objetos do AppVault

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

Passos

  1. Crie e aplique um arquivo YAML de combinação de AppVault e segredo que conceda ao usuário acesso a um AppVault. Por exemplo, a seguinte solicitação de configuração (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 solicitação de configuração (CR) de função 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 solicitação de configuração (CR) de vinculação de função (RoleBinding) para associar 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 de objetos do 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 informações do AppVault às quais agora possui 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 autorizados do AppVault 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.