Gestionar el acceso a clústeres estándar

En este documento se explica cómo gestionar los permisos de los clústeres estándar en Google Distributed Cloud (GDC) aislado mediante la CLI de gdcloud. Los clústeres estándar son entornos de Kubernetes configurables y específicos de un proyecto con servicios predeterminados mínimos que ofrecen mayor flexibilidad y control para cargas de trabajo personalizadas.

Para obtener más información sobre los clústeres estándar y otros tipos de clústeres, consulta Configuraciones de clústeres de Kubernetes.

Este documento está dirigido a los usuarios del grupo de operadores de aplicaciones, como los desarrolladores de operaciones o los científicos de datos, que necesitan gestionar y proteger los recursos de los proyectos de GDC. Para obtener más información, consulta Audiencias de la documentación aislada de GDC.

Antes de empezar

Antes de gestionar el acceso a clústeres estándar, debes tener los permisos necesarios y preparar tu entorno.

Solicitar roles de gestión de identidades y accesos

Ponte en contacto con el administrador de gestión de identidades y accesos de tu organización para solicitar los siguientes roles en función de las tareas que tengas que realizar:

  • Administrador de gestión de identidades y accesos de proyectos (project-iam-admin): crea, actualiza y elimina enlaces de roles para clústeres estándar de un proyecto.
  • Administrador de clúster estándar (standard-cluster-admin): crea, actualiza y elimina enlaces de roles en un clúster estándar específico.

Prepara tu entorno

Conceder permisos para el acceso estándar a clústeres

Un usuario con el rol Administrador de gestión de identidades y accesos del proyecto (project-iam-admin) puede conceder a otros usuarios los roles necesarios para gestionar el acceso en clústeres estándar:

  1. Inicia sesión con el proveedor de identidades configurado con la CLI gdcloud.

  2. Concede al usuario el rol Administrador de clústeres estándar (standard-cluster-admin) del proyecto. Este comando vincula al usuario con el rol, lo que le permite gestionar el acceso en el clúster estándar.

    Para obtener más información sobre los roles, consulta las descripciones de los roles predefinidos y las definiciones de los roles de los proyectos.

    gdcloud projects add-iam-policy-binding PROJECT \
  --role=ROLE \
  --member=user:USER_ACCOUNT

    Sustituye las siguientes variables:

    • PROJECT: el nombre del proyecto en el que se encuentra el clúster estándar.
    • ROLE: el nombre del rol que quieres asignar (por ejemplo, standard-cluster-admin).
    • USER_ACCOUNT: la cuenta de usuario a la que quieres asignar el rol, incluido el prefijo del proveedor de identidades asociado a tu organización (por ejemplo, idpprefix-user@example.com). El prefijo específico que se utiliza depende de la configuración del IdP de tu organización. Para obtener más información, consulta el artículo Conectarse a un proveedor de identidades.

    En el siguiente ejemplo, se asigna el rol Administrador de clúster estándar a user@example.com. Se presupone que el prefijo del proveedor de identidades es fop- para el proyecto foo:

    gdcloud projects add-iam-policy-binding foo \
  --role=standard-cluster-admin \
  --member=user:fop-user@example.com

Gestionar el acceso en el clúster estándar

Un usuario con el rol Administrador de clúster estándar (standard-cluster-admin) puede conceder acceso en un clúster estándar:

  1. Inicia sesión con el proveedor de identidades configurado con la CLI gdcloud.

  2. Genera un archivo kubeconfig para un clúster estándar con la marca --standard. Esta marca es obligatoria para orientar a un clúster estándar.

    export KUBECONFIG=KUBECONFIG_FILE
gdcloud clusters get-credentials STANDARD_CLUSTER_NAME --standard --project=PROJECT

    Sustituye las siguientes variables:

    • KUBECONFIG_FILE: la ruta al archivo kubeconfig, como standard-cluster-kubeconfig.yaml.
    • STANDARD_CLUSTER_NAME: el nombre del clúster estándar.
    • PROJECT: el nombre del proyecto en el que se encuentra el clúster estándar.

  3. Define los permisos en el clúster estándar mediante kubectl.

    Los usuarios con permisos de standard-cluster-admin pueden crear objetos Role y ClusterRole personalizados. Para conceder estos permisos, pueden crear los objetos Rolebinding y ClusterRoleBinding correspondientes para vincular los roles a temas específicos, como usuarios o cuentas de servicio.

    En el siguiente ejemplo se usa kubectl para crear un Role personalizado de ejemplo llamado test-role en el espacio de nombres test:

    kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test-role
  namespace: test
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
EOF

    En el siguiente ejemplo se crea el RoleBinding para el Role llamado test-role en el espacio de nombres test. Concede permisos al usuario alice@example.com con el prefijo de proveedor de identidades fop-, así como a un ServiceAccount llamado my-service-account en el espacio de nombres default:

    kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-role-binding
  namespace: test
subjects:
- kind: User
  name: fop-alice@example.com
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: my-service-account
  namespace: default
roleRef:
  kind: Role
  name: test-role
  apiGroup: rbac.authorization.k8s.io
EOF