Roles y permisos

En esta página se proporciona información sobre los roles y permisos de Gestión de Identidades y Accesos (IAM) y sobre cómo se usan con las instancias de Cloud SQL.

Introducción

En esta página se describen los aspectos de IAM que son relevantes específicamente para Cloud SQL. Para obtener información detallada sobre IAM y sus funciones en general, consulta Gestión de identidades y accesos. En particular, consulta la sección Gestionar políticas de gestión de identidades y accesos. IAM te permite controlar quién tiene acceso a los recursos de tu Google Cloud proyecto. El conjunto de reglas de acceso que aplicas a un recurso se denomina política de gestión de identidades y accesos. Una política de gestión de identidades y accesos (IAM) aplicada a tu proyecto define las acciones que los usuarios pueden llevar a cabo en todos los recursos de tu proyecto.

Los miembros son el "quién" de IAM. Los miembros pueden ser usuarios individuales, grupos, dominios o incluso el público en general. A los miembros se les asignan roles, que les permiten realizar acciones en Cloud SQL, así como Google Cloud otras acciones más generales. Cada rol es un conjunto de uno o varios permisos. Los permisos son las unidades básicas de gestión de identidades y accesos: cada permiso te permite realizar una acción determinada. Consulta las listas completas de todos los roles y permisos disponibles en Cloud SQL en Roles de IAM en Cloud SQL y Permisos de IAM en Cloud SQL.

Cuando usas una cuenta para conectarte a una instancia de Cloud SQL, la cuenta debe tener el rol Cloud SQL > Cliente (roles/cloudsql.client), que incluye los permisos necesarios para conectarse.

Puedes añadir roles a una cuenta en la consola en la página Gestión de identidades y accesos y administración > Gestión de identidades y accesos y ver qué permisos pertenecen a cada rol en la página Gestión de identidades y accesos y administración > Roles.

Cloud SQL usa cuentas de servicio para la autenticación entre Cloud SQL y otros productos de Google Cloud . Las cuentas de servicio proporcionan credentials en formato JSON, que puedes descargar desde la consola y usar para la autenticación en varios casos.

Por ejemplo, si te conectas desde una aplicación que se ejecuta en un contenedor de Docker.

Roles y permisos de Cloud SQL con el proxy de autenticación de Cloud SQL

Si te conectas a una instancia de Cloud SQL desde una instancia de Compute Engine mediante el proxy de autenticación de Cloud SQL, puedes usar la cuenta de servicio predeterminada de Compute Engine asociada a la instancia de Compute Engine.

Al igual que todas las cuentas que se conectan a una instancia de Cloud SQL, la cuenta de servicio debe tener el rol Cloud SQL > Cliente.

Roles y permisos de Cloud SQL con opciones sin servidor

LasGoogle Cloud opciones sin servidor incluyen App Engine y Cloud Run.

Usa una cuenta de servicio para autorizar el acceso desde estas opciones. La cuenta de servicio autoriza el acceso a todas las instancias de Cloud SQL de un proyecto específico. Cuando creas una aplicación o una función de Cloud Run, este servicio crea esta cuenta por ti. Puedes encontrar la cuenta en la página IAM y administración > IAM , con el sufijo adecuado:

Opción sin servidor Sufijo de la cuenta de servicio
App Engine @gae-api-prod.google.com.iam.gserviceaccount.com
Cloud Run Functions @appspot.gserviceaccount.com
Cloud Run compute@developer.gserviceaccount.com
Al igual que todas las cuentas que se conectan a una instancia de Cloud SQL, la cuenta de servicio debe tener el rol Cloud SQL > Cliente.

Roles y permisos de Cloud SQL con Cloud Storage

Las funciones de importación y exportación de Cloud SQL funcionan conjuntamente. Las exportaciones escriben en Cloud Storage y las importaciones leen desde allí. Por este motivo, la cuenta de servicio que utilices para estas operaciones debe tener permisos de lectura y escritura en Cloud Storage:

Roles y permisos de Cloud SQL con la autenticación de grupos de gestión de identidades y accesos

Cuando usas la autenticación de grupos de gestión de identidades y accesos, creas grupos. Después, puedes usar los grupos para gestionar el acceso y los privilegios de base de datos de tus instancias de Cloud SQL.

En la siguiente tabla se indican los roles necesarios para gestionar la autenticación de grupos de gestión de identidades y accesos.

Acción Roles
Crear, ver y gestionar grupos.

roles/resourcemanager.organizationViewer

Consulta el registro de cambios de pertenencia a grupos de IAM.

roles/logging.viewer

Concede, consulta y define permisos de gestión de identidades y accesos a nivel de proyecto.

roles/resourcemanager.projectIamAdmin

Concede, consulta y define permisos de gestión de identidades y accesos a nivel de carpeta.

roles/resourcemanager.folderIamAdmin

El administrador puede conceder roles de Cloud SQL o permisos de Cloud SQL individuales a cada grupo. Los miembros de cada grupo heredan roles y permisos.

Roles y permisos de Cloud SQL para la integración de Dataplex Universal Catalog

Para proporcionar acceso a los metadatos de Cloud SQL en Universal Catalog de Dataplex, puedes conceder a un usuario el rol roles/cloudsql.schemaViewer o añadir el permiso cloudsql.schemas.view a un rol personalizado.

Para obtener más información, consulta el artículo sobre cómo gestionar recursos de Cloud SQL con Dataplex Universal Catalog.

Permiso para acceder a instancias privadas de Cloud SQL

Cuando otro servicio, como BigQuery, necesita comunicarse con tu instancia de Cloud SQL para acceder a los datos y hacer consultas sobre ellos a través de una conexión privada, el servicio usa una ruta interna en lugar de las direcciones IP privadas de la nube privada virtual (VPC). Google Cloud El tráfico no se puede controlar ni restringir con ninguna configuración a nivel de VPC, regla de cortafuegos, política de ruta o interrupción del peering.

En su lugar, Cloud SQL ofrece una marca de configuración en tu instancia para controlar si se activa o desactiva esta ruta interna para otros servicios de Google Cloud que accedan a tu base de datos.

Controlar y revocar el permiso

Cuando otro servicio, como BigQuery, intenta acceder a tu instancia privada de Cloud SQL, debe proporcionar una identidad legítima con el permiso de gestión de identidades y accesos cloudsql.instances.connect. Google Cloud

Normalmente, hay dos formas en las que un servicio puede conseguirlo:

  1. Reenvío de las credenciales del usuario. Un servicio puede reenviar la identidad de gestión de identidades y accesos del usuario a Cloud SQL para evaluar el permiso de acceso a una instancia. En este caso, el usuario debe tener permisos de gestión de identidades y accesos suficientes para que Cloud SQL pueda establecer una conexión correcta.

  2. Usar una cuenta de servicio. Un servicio, como BigQuery, puede usar una cuenta de servicio preconfigurada para conectarse a una instancia de Cloud SQL. En este caso, la cuenta de servicio debe tener los permisos de gestión de identidades y accesos suficientes.

    Por ejemplo, en el caso de la conexión federada entre BigQuery y Cloud SQL, se crea una cuenta de servicio llamada service-{PROJECT_NUMBER}@gcp-sa-bigqueryconnection.iam.gserviceaccount.com cuando se activa la API de conexión de BigQuery. Esta cuenta de servicio tiene dos permisos de Cloud SQL: cloudsql.instances.connect y cloudsql.instances.get. BigQuery usa estos permisos para acceder a una instancia privada de Cloud SQL a través de una ruta interna.

Para controlar el permiso de quién puede usar esta ruta interna, puedes conceder y revocar los permisos de gestión de identidades y accesos a la identidad de gestión de identidades y accesos del usuario que elGoogle Cloud servicio, como BigQuery, usa para conectarse a tu instancia de Cloud SQL. Para obtener más información sobre cómo conceder y revocar permisos en BigQuery, consulta Configurar el acceso a Cloud SQL.

Roles y permisos de Cloud SQL en otros casos prácticos

Cloud SQL interactúa con otros Google Cloud productos y herramientas. Estas interacciones también requieren roles y permisos específicos que pueden variar según el caso. En la documentación de Cloud SQL se proporciona información detallada sobre estos requisitos para cada caso:

Usar la gestión de identidades y accesos con proyectos

En las siguientes secciones se muestra cómo completar tareas básicas de gestión de identidades y accesos en proyectos.

Para completar las tareas siguientes, debes tener los permisos de gestión de identidades y accesos resourcemanager.projects.getIamPolicy y resourcemanager.projects.setIamPolicy.

Añadir un miembro a una política a nivel de proyecto

Para ver una lista de los roles asociados a Cloud SQL, consulta Roles de IAM.

Consola

  1. Ve a la página IAM y administración de la consola de Google Cloud .
  2. En el menú desplegable de proyectos de la barra superior, selecciona el proyecto al que quieras añadir un miembro.
  3. Haz clic en Añadir. Aparecerá el cuadro de diálogo Añadir miembros y roles al proyecto.
  4. En el campo Miembros nuevos, especifica el nombre de la entidad a la que quieres conceder acceso.
  5. En el menú desplegable Selecciona un rol, asigna el rol adecuado al miembro. Los roles que afectan a los recursos de Cloud SQL se encuentran en los submenús Proyecto y Cloud SQL.
  6. Haz clic en Guardar.

gcloud

Para añadir una política de gestión de identidades y accesos a nivel de proyecto, usa gcloud beta projects add-iam-policy-binding.

Ver la política de gestión de identidades y accesos de un proyecto

Consola

  1. Ve a la página IAM y administración de la consola de Google Cloud .
  2. En el menú desplegable de proyectos de la barra superior, selecciona el proyecto cuya política quieras ver.
  3. Hay dos formas de ver los permisos del proyecto:
    • Ver por Miembros: consulta la columna Rol asociada a cada miembro para ver qué roles tiene cada uno.
    • Ver por Roles: usa el menú desplegable asociado a cada rol para ver qué miembros lo tienen.

gcloud

Para ver la política de gestión de identidades y accesos de un proyecto, usa gcloud beta projects get-iam-policy.

Quitar un miembro de una política a nivel de proyecto

Consola

  1. Ve a la página IAM y administración de la consola de Google Cloud .
  2. En el menú desplegable de proyectos de la barra superior, selecciona el proyecto del que quieras quitar un miembro.
  3. Asegúrate de que estás viendo los permisos por Miembros y selecciona los miembros que quieras quitar.
  4. Haz clic en Quitar.
  5. En la ventana superpuesta que aparece, haz clic en Confirmar.

gcloud

Para eliminar una política de gestión de identidades y accesos a nivel de proyecto, usa gcloud beta projects remove-iam-policy-binding.

Prácticas recomendadas

IAM, al igual que cualquier otro ajuste administrativo, requiere una gestión activa para que sea eficaz. Antes de dar acceso a un recurso a otros usuarios, asegúrate de saber qué rol quieres que desempeñe cada uno de ellos. Con el tiempo, los cambios en la gestión de proyectos, los patrones de uso y la propiedad de la organización pueden requerir que modifiques la configuración de IAM en los proyectos, sobre todo si gestionas Cloud SQL en una organización grande o para un grupo grande de usuarios. Cuando evalúes y planifiques los ajustes de control de acceso, ten en cuenta las siguientes prácticas recomendadas:

  • Aplica el principio de mínimos accesos al conceder acceso. El principio de mínimos accesos es una directriz de seguridad para conceder acceso a tus recursos. Cuando concedes acceso según el principio de mínimos accesos, solo das a un usuario el acceso que necesita para completar la tarea asignada.

  • No concedas roles con permiso setIamPolicy a personas que no conozcas. Si se concede el permiso setIamPolicy, el usuario podrá cambiar los permisos y controlar los datos. Debes usar roles con setIamPolicy permisos solo cuando quieras delegar el control administrativo de objetos y contenedores.

  • Delega el control administrativo de tus recursos. Debes asegurarte de que otros miembros del equipo puedan seguir gestionando tus recursos si un usuario con acceso de administrador abandona el grupo. Estas son dos formas habituales de hacerlo:

    • Asigna el rol Administrador de Cloud SQL de tu proyecto a un grupo en lugar de a un usuario concreto.
    • Asigna el rol Administrador de Cloud SQL de tu proyecto a al menos dos personas.

Siguientes pasos