Conceder y obtener acceso a segmentos de almacenamiento de proyectos

En esta página se explica cómo gestionar el acceso a los segmentos de almacenamiento en proyectos aislados de Google Distributed Cloud (GDC) para que las personas adecuadas tengan los permisos necesarios. Se indican los requisitos previos y los pasos para obtener y conceder acceso a usuarios y cuentas de servicio mediante vinculaciones de roles y roles predefinidos. Esta información te permite controlar de forma eficaz el acceso a tus recursos de almacenamiento y mantener la seguridad y la eficiencia operativa.

Esta página está dirigida a usuarios como los administradores de TI del grupo de operadores de infraestructura o los desarrolladores del grupo de operadores de aplicaciones que gestionan la configuración de acceso a los segmentos de almacenamiento en entornos GDC aislados. Para obtener más información, consulta el artículo sobre los destinatarios de la documentación de GDC aislado.

Antes de empezar

Un espacio de nombres de proyecto gestiona los recursos de segmento en el servidor de la API Management. Debes tener un proyecto para trabajar con segmentos y objetos.

Conceder acceso a un segmento

Puedes conceder acceso a recursos de la API de S3, como segmentos y objetos de esos segmentos, a sujetos User y ServiceAccount creando y aplicando RoleBindings que hagan referencia a roles predefinidos en el servidor de API Management.

Nota: Group no se admiten sujetos para conceder permisos de la API de S3. Si especificas un sujeto Group en un RoleBinding, no se concederán permisos de la API de S3 a los miembros del grupo, pero sí se podrán aplicar permisos de la API de Kubernetes a los sujetos Group de esta forma.

Nota: El sistema de control de acceso a objetos no admite el acceso a grupos. Solo reconoce y actúa sobre sujetos de los tipos User o ServiceAccount.

Roles predefinidos

• project-bucket-object-viewer: permite a un usuario ver todos los segmentos del proyecto, los objetos de esos segmentos y los objetos y metadatos de objetos. No permite realizar operaciones de escritura en objetos. Por ejemplo, subir, sobrescribir o eliminar. Tiene acceso de solo lectura a los segmentos de doble zona de la organización y sus proyectos, así como a los objetos de esos segmentos.

• project-bucket-object-admin: permite a un usuario ver todos los segmentos del proyecto y realizar operaciones de escritura y lectura en objetos. Por ejemplo, subir, sobrescribir o eliminar. Tiene acceso de solo lectura a los segmentos de doble zona de la organización y sus proyectos, así como acceso de lectura y escritura a los objetos de esos segmentos.

• project-bucket-admin: permite a los usuarios gestionar todos los segmentos del espacio de nombres especificado, así como todos los objetos de esos segmentos. Tiene acceso de solo lectura a los segmentos de doble zona de la organización y sus proyectos, así como acceso de lectura y escritura a los objetos de esos segmentos.

Para ver una lista completa de los permisos concedidos para los roles anteriores, consulta la sección Permisos de roles predefinidos.

Para crear vinculaciones de roles en un proyecto, debes tener el rol de administrador de IAM del proyecto. A continuación, se muestra un ejemplo de cómo crear un recurso RoleBinding que concede acceso a un usuario y a una cuenta de servicio:

1. Crea un archivo YAML en tu sistema, como rolebinding-object-admin-all-buckets.yaml.

   # Example file name:
   # rolebinding-object-admin-all-buckets.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     namespace: PROJECT_NAMESPACE
     name: readwrite-all-buckets
   roleRef:
     kind: Role
     name: project-bucket-object-admin
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: ServiceAccount
     namespace: PROJECT_NAMESPACE
     name: SA_NAME
   - kind: User
     namespace: PROJECT_NAMESPACE
     name: [e-mail]
     apiGroup: rbac.authorization.k8s.io
     # Could be bob or [e-mail] based on your organization settings.
   

   Haz los cambios siguientes:

   • PROJECT_NAMESPACE: el nombre del espacio de nombres del proyecto
   • SA_NAME: el nombre de la cuenta de servicio

2. Aplica el archivo YAML:

   kubectl apply \
   -f rolebinding-object-admin-all-buckets.yaml
   

Obtener credenciales de acceso a un segmento

Cuando concedes acceso a un segmento, se crean las credenciales de acceso en un secreto.

El formato del nombre del secreto es object-storage-key-STORAGE_CLASS-SUBJECT_TYPE-SUBJECT_HASH.

• Los valores de STORAGE_CLASS son los siguientes:
  • std para la clase de almacenamiento Standard.
• Los valores de SUBJECT_TYPE son los siguientes:
  • user para usuario.
  • sa para cuenta de servicio.
• SUBJECT_HASH es el hash SHA256 codificado en base32 del nombre del sujeto.

Por ejemplo, el usuario [e-mail] tiene dos secretos con los siguientes nombres:

1. object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja

Obtener acceso de usuario

En el caso de un sujeto de usuario, el secreto se encuentra en el espacio de nombres object-storage-access-keys del servidor de la API de gestión.

1. Ejecuta el siguiente comando para buscar el nombre del secreto:

   kubectl auth can-i --list --namespace object-storage-access-keys | grep "object-storage-key-"
   

   Recibirás un resultado similar al siguiente:

   secrets        []        [object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja]        [get]
   

2. Obtén el contenido del secreto correspondiente para acceder a los segmentos de la clase de almacenamiento Standard:

   kubectl get -o yaml --namespace object-storage-access-keys secret object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja
   

   Recibirás un resultado similar al siguiente:

   data:
     access-key-id: MEhYM08wWUMySjcyMkVKTFBKRU8=
     create-time: MjAyMi0wNy0yMiAwMTowODo1OS40MTQyMTE3MDMgKzAwMDAgVVRDIG09KzE5OTAuMzQ3OTE2MTc3
     secret-access-key: Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==
   

3. Decodifica el ID de clave de acceso y el secreto:

   echo "MEhYM08wWUMySjcyMkVKTFBKRU8=" | base64 -d \
       && echo \
       && echo "Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==" | base64 -d
   

   Recibirás un resultado similar al siguiente:

   0HX3O0YC2J722EJLPJEO
   Rjt1TeySxJhBIRanigT00m2YsB/FRUzwjGBnaXbT
   

4. Sigue las instrucciones de la sección Configurar la CLI gdcloud con la información resultante.

Obtener acceso de cuenta de servicio

Las credenciales secretas de S3 solo se crean y están disponibles para obtenerse si hay un segmento en el espacio de nombres del proyecto.

Nota: Los usuarios no pueden ejecutar cargas de trabajo, que se ejecutan como cuentas de servicio, en el servidor de la API de gestión donde se crearon inicialmente los secretos de clave de acceso de las cuentas de servicio. Los usuarios no podrán conceder acceso a esas cargas de trabajo a esos secretos en el servidor de la API de gestión. Esos secretos se propagarán a los espacios de nombres del proyecto en los clústeres de usuario correspondientes, donde los usuarios podrán acceder a ellos (si tienen los roles de RBAC adecuados en ese proyecto).

En el caso de un sujeto de cuenta de servicio (SA), busca el nombre del secreto en el clúster de usuario.

1. En el caso de la clase de almacenamiento estándar, ejecuta el siguiente comando para obtener el nombre del secreto:

   kubectl get -n=<PROJECT-NAME> serviceaccount <SA-NAME> -o json | jq -r '.secrets[] | select(.name | test("object-storage-key-std"))'
   

2. A continuación, puedes buscar manualmente entre los nombres de secretos que se muestran o usar grep para encontrar object-storage-key-(std|nl). Para la segunda opción, ejecuta lo siguiente:

   kubectl get -n=<PROJECT-NAME> serviceaccount <SA-NAME> -o=jsonpath='{.secrets}{"\n"}' | grep object-storage-key-(std|nl)
   

3. Puedes hacer referencia al secreto en tu pod como variables de entorno o archivos.

Permisos de roles predefinidos

Los roles predefinidos están disponibles en el servidor de la API global para el acceso administrativo y operativo a los segmentos de doble zona. Estos roles también conceden acceso a los segmentos zonales, pero solo si se usa un recurso IAMRoleBinding en lugar de un recurso RoleBinding o ClusterRoleBinding. Para obtener más información sobre las vinculaciones de roles, consulta el artículo sobre cómo conceder y revocar acceso.

Permisos de project-bucket-object-viewer

Este rol concede permisos para obtener y ver objetos y metadatos de objetos en el segmento.

A continuación, se muestra una lista de todos los permisos de almacenamiento de objetos que concede el rol project-bucket-object-viewer Role:

• Permisos de la API de segmentos:

  1. get
  2. list
  3. watch

• Permisos de almacenamiento de objetos de S3:

  1. GetObject
  2. GetObjectAcl
  3. GetObjectLegalHold
  4. GetObjectRetention
  5. GetObjectTagging
  6. GetObjectVersion
  7. GetObjectVersionTagging
  8. ListBucket
  9. ListBucketVersions
  10. ListBucketMultipartUploads
  11. ListMultipartUploadParts

Permisos de project-bucket-object-admin

Este rol concede permisos para colocar y eliminar objetos, versiones de objetos y etiquetas en el segmento. Además, también concede todos los permisos de project-bucket-object-viewer.

A continuación, se muestra una lista de todos los permisos de almacenamiento de objetos adicionales que concede el Role son los siguientes:

• Permisos de almacenamiento de objetos de S3:

  1. AbortMultipartUpload
  2. DeleteObject
  3. DeleteObjectTagging
  4. DeleteObjectVersion
  5. DeleteObjectVersionTagging
  6. PutObject
  7. PutObjectTagging
  8. PutObjectVersionTagging
  9. PutOverwriteObject
  10. RestoreObject

Permisos de project-bucket-admin

Este rol concede permisos para crear, actualizar o eliminar recursos Bucket en el espacio de nombres del proyecto. Además, también concede todos los permisos de project-bucket-object-admin.

A continuación, se muestra una lista de los permisos adicionales que Role concede:

• Permisos de la API de segmentos:

  1. Create
  2. Actualizar
  3. Delete