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 de ámbito de 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.

Esta página está dirigida a audiencias del grupo de operadores de aplicaciones, como los responsables de operaciones de desarrollo o los científicos de datos, que necesitan gestionar y proteger recursos en proyectos de GDC. Para obtener más información, consulta Audiencias de la documentación aislada de GDC.

Antes de empezar

  • Pídele al administrador de gestión de identidades y accesos de tu organización que te conceda el rol Administrador de gestión de identidades y accesos de proyectos (project-iam-admin). Para obtener más información sobre los roles, consulta Definiciones de roles.
  • Instala la CLI de gdcloud si aún no lo has hecho.

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

Un usuario con el rol de administrador de gestión de identidades y accesos de proyecto (project-iam-admin) sigue estos pasos para 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 de gdcloud.

  2. Asigna al usuario el rol Administrador de clústeres (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, cluster-admin o cluster-developer).
    • 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 utilice dependerá de la configuración del IdP de tu organización. Consulta Conectarse a un proveedor de identidades para obtener más información.

    En el siguiente ejemplo se asigna el rol Administrador de clústeres 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=cluster-admin \
  --member=user:fop-user@example.com

Gestionar el acceso en el clúster estándar

Un usuario al que se le ha concedido el rol cluster-admin en la sección anterior sigue estos pasos:

  1. Inicia sesión con el proveedor de identidades configurado con la CLI de 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 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 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