Skip to main content
Hay disponible una nueva versión de este producto.
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Administra la autorización y el control de acceso de Trident Protect

PDF

Trident Protect utiliza el modelo de Kubernetes de control de acceso basado en roles (RBAC). Por defecto, Trident Protect proporciona un único espacio de nombres del sistema y su cuenta de servicio predeterminada asociada. Si tienes una organización con muchos usuarios o necesidades de seguridad específicas, puedes usar las funciones de RBAC de Trident Protect para tener un control más granular sobre el acceso a los recursos y espacios de nombres.

El administrador del clúster siempre tiene acceso a los recursos en el espacio de nombres predeterminado trident-protect y también puede acceder a los recursos en todos los demás espacios de nombres. Para controlar el acceso a los recursos y aplicaciones, necesitas crear espacios de nombres adicionales y agregar recursos y aplicaciones a esos espacios de nombres.

Ten en cuenta que ningún usuario puede crear CR de gestión de datos de aplicaciones en el espacio de nombres predeterminado trident-protect. Necesitas crear CR de gestión de datos de aplicaciones en un espacio de nombres de aplicaciones (como mejor práctica, crea los CR de gestión de datos de aplicaciones en el mismo espacio de nombres que su aplicación asociada).

Nota

Solo los administradores deben tener acceso a los objetos de recursos personalizados privilegiados de Trident Protect, que incluyen:

  • AppVault: requiere datos de credenciales de cubo

  • AutoSupportBundle: recoge métricas, registros y otros datos confidenciales de Trident Protect

  • AutoSupportBundleSchedule: gestiona los calendarios de recogida de registros

Como mejor práctica, usa RBAC para restringir el acceso a objetos privilegiados a los administradores.

Para obtener más información sobre cómo RBAC regula el acceso a los recursos y espacios de nombres, consulta la "Documentación de Kubernetes RBAC".

Para más información sobre las cuentas de servicio, consulta el "Documentación de cuentas de servicio de Kubernetes".

Ejemplo: gestionar el acceso de dos grupos de usuarios

Por ejemplo, una organización tiene un administrador de clúster, un grupo de usuarios de ingeniería y un grupo de usuarios de marketing. El administrador de clúster realizaría las siguientes tareas para crear un entorno donde el grupo de ingeniería y el grupo de marketing tengan acceso solo a los recursos asignados a sus respectivos espacios de nombres.

Paso 1: crea un espacio de nombres para contener los recursos de cada grupo

Crear un espacio de nombres te permite separar lógicamente los recursos y controlar mejor quién tiene acceso a esos recursos.

Pasos

  1. Crea un espacio de nombres para el grupo de ingeniería:

    kubectl create ns engineering-ns

  2. Crea un espacio de nombres para el grupo de marketing:

    kubectl create ns marketing-ns

Paso 2: crea nuevas cuentas de servicio para interactuar con recursos en cada espacio de nombres

Cada nuevo espacio de nombres que crees viene con una cuenta de servicio por defecto, pero deberías crear una cuenta de servicio para cada grupo de usuarios para que puedas dividir aún más los privilegios entre grupos en el futuro si es necesario.

Pasos

  1. Crea una cuenta de servicio para el grupo de ingeniería:

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

  2. Crea una cuenta de servicio para el grupo de marketing:

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

Paso 3: crea un secreto para cada nueva cuenta de servicio

Un secreto de cuenta de servicio se usa para autenticarse con la cuenta de servicio y se puede borrar y recrear fácilmente si se ve comprometido.

Pasos

  1. Crea un secreto para la cuenta de servicio de ingeniería:

    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 secreto para la cuenta del servicio 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

Paso 4: crea un objeto RoleBinding para vincular el objeto ClusterRole a cada nueva cuenta de servicio

Se crea un objeto ClusterRole por defecto cuando instalas Trident Protect. Puedes vincular este ClusterRole a la cuenta de servicio creando y aplicando un objeto RoleBinding.

Pasos

  1. Vincula el ClusterRole a la cuenta de servicio de ingeniería:

    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. Vincula el ClusterRole a la cuenta de servicio 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

Paso 5: probar los permisos

Comprueba que los permisos son correctos.

Pasos

  1. Confirma que los usuarios de ingeniería pueden acceder a los recursos de ingeniería:

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

  2. Confirma que los usuarios de ingeniería no pueden acceder a los recursos de marketing:

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

Paso 6: concede acceso a los objetos de AppVault

Para realizar tareas de gestión de datos como copias de seguridad e instantáneas, el administrador del clúster debe conceder acceso a AppVault objetos a usuarios individuales.

Pasos

  1. Crea y aplica un archivo YAML de combinación de AppVault y secreto que le da a un usuario acceso a un AppVault. Por ejemplo, el siguiente CR da acceso a un AppVault al usuario 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. Crea y aplica un Role CR para permitir que los administradores de clúster otorguen acceso a recursos específicos en un namespace. Por ejemplo:

    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. Crea y aplica una CR RoleBinding para vincular los permisos al usuario eng-user. Por ejemplo:

    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. Verifica que los permisos sean correctos.

    1. Intenta recuperar la información del objeto AppVault para todos los espacios de nombres:

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

      Deberías ver una salida similar a la siguiente:

      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. Prueba para ver si el usuario puede obtener la información de AppVault que ahora tiene permiso para acceder:

      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

      Deberías ver una salida similar a la siguiente:

    yes
Resultado

Los usuarios a los que has concedido permisos de AppVault deberían poder usar los objetos autorizados de AppVault para operaciones de gestión de datos de la aplicación, y no deberían poder acceder a ningún recurso fuera de los espacios de nombres asignados ni crear nuevos recursos a los que no tengan acceso.