Administra el acceso a los clústeres estándar

En este documento, se explica cómo administrar los permisos para los clústeres estándar en Google Distributed Cloud (GDC) aislados con la CLI de gdcloud. Los clústeres estándar son entornos de Kubernetes configurables y con alcance a nivel del proyecto que incluyen servicios predeterminados mínimos y ofrecen mayor flexibilidad y control para las 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 públicos dentro del grupo de operadores de aplicaciones, como los operadores de desarrolladores o los científicos de datos, que necesitan administrar y proteger los recursos dentro de los proyectos de GDC. Para obtener más información, consulta Públicos de la documentación de Google Distributed Cloud aislado.

Antes de comenzar

  • Pídele al administrador de IAM de la organización que te otorgue el rol de administrador de IAM del proyecto (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 hiciste.

Otorga permisos para el acceso estándar al clúster

Un usuario con el rol de administrador de IAM del proyecto (project-iam-admin) realiza los siguientes pasos para otorgar a otros usuarios los roles necesarios para administrar el acceso dentro de los clústeres estándar:

  1. Accede con tu proveedor de identidad configurado a través de la CLI de gdcloud.

  2. Otorga al usuario el rol de administrador del clúster (cluster-admin) para el proyecto. Este comando vincula al usuario con el rol, lo que le permite administrar el acceso dentro del clúster estándar.

    Consulta las descripciones de los roles predefinidos y las definiciones de roles para proyectos para obtener más información sobre los roles.

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

    Reemplaza las siguientes variables:

    • PROJECT: Es el nombre del proyecto en el que existe el clúster estándar.
    • ROLE: Es el nombre del rol que deseas otorgar (como cluster-admin o cluster-developer).
    • USER_ACCOUNT: Es la cuenta de usuario para la que deseas otorgar el rol, incluido el prefijo del proveedor de identidad asociado a tu organización (como idpprefix-user@example.com). El prefijo específico que se usa depende de la configuración del IdP de tu organización. Consulta Conéctate a un proveedor de identidad para obtener más información.

    En el siguiente ejemplo, se otorga el rol de administrador del clúster a user@example.com, suponiendo que el prefijo del proveedor de identidad es fop- para el proyecto foo:

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

Administra el acceso dentro del clúster estándar

Un usuario al que se le otorgó el rol de cluster-admin en la sección anterior realiza los siguientes pasos:

  1. Accede con tu proveedor de identidad configurado a través de la CLI de gdcloud.

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

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

    Reemplaza las siguientes variables:

    • KUBECONFIG_FILE: Es la ruta de acceso al archivo kubeconfig, como standard-cluster-kubeconfig.yaml.
    • STANDARD_CLUSTER_NAME: Es el nombre del clúster estándar.
    • PROJECT: Es el nombre del proyecto en el que existe el clúster estándar.
  3. Define permisos dentro del clúster estándar con kubectl.

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

    En el siguiente ejemplo, se usa kubectl para crear un Role personalizado de muestra 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. Otorga permisos al usuario alice@example.com con el prefijo del proveedor de identidad 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