Asociar cuentas de servicio a recursos

En algunos Trusted Cloud recursos, puedes especificar una cuenta de servicio gestionada por el usuario que el recurso utilice como identidad predeterminada. Este proceso se conoce como asignación de la cuenta de servicio al recurso o asociación de la cuenta de servicio al recurso. Cuando el código que se ejecuta en el recurso accede a Trusted Cloud servicios y recursos, utiliza la cuenta de servicio asociada al recurso como identidad. Por ejemplo, si asocias una cuenta de servicio a una instancia de Compute Engine y las aplicaciones de la instancia usan una biblioteca de cliente para llamar a las APIs Trusted Cloud , esas aplicaciones usarán automáticamente la cuenta de servicio asociada para la autenticación y la autorización.

En esta página se describe cómo configurar cuentas de servicio para poder asociarlas a recursos.

Antes de empezar

Roles obligatorios

Para obtener el permiso que necesitas para asociar una cuenta de servicio a un recurso, pide a tu administrador que te conceda el rol de gestión de identidades y accesos Usuario de cuenta de servicio (roles/iam.serviceAccountUser) en la cuenta de servicio. Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

Este rol predefinido contiene el permiso iam.serviceAccounts.actAs , que es necesario para asignar una cuenta de servicio a un recurso.

También puedes obtener este permiso con roles personalizados u otros roles predefinidos.

Asociar una cuenta de servicio a un recurso

En la mayoría de los casos, debes asociar una cuenta de servicio a un recurso cuando crees ese recurso. Una vez creado el recurso, no se puede cambiar la cuenta de servicio asociada. Las instancias de Compute Engine son una excepción a esta regla. Puedes cambiar la cuenta de servicio que está asociada a una instancia según sea necesario.

Antes de asociar una cuenta de servicio a un recurso, debes configurarla. Este proceso varía en función de si la cuenta de servicio y el recurso están en el mismo proyecto o en proyectos diferentes. Después de configurar la cuenta de servicio, puedes crear el recurso y adjuntarle la cuenta de servicio.

Configurar un recurso del mismo proyecto

Antes de vincular una cuenta de servicio a otro recurso del mismo proyecto, concede roles a la cuenta de servicio para que pueda acceder a los recursos adecuados, al igual que harías con cualquier otra entidad.

Configurar un recurso de otro proyecto

En algunos casos, es posible que tengas que vincular una cuenta de servicio a un recurso que se encuentre en otro proyecto. Por ejemplo, si crea todas sus cuentas de servicio en un solo proyecto, es posible que tenga que vincular una de ellas a un nuevo recurso de otro proyecto.

Antes de vincular una cuenta de servicio a un recurso de otro proyecto, haz lo siguiente:

  1. En el proyecto en el que se encuentra la cuenta de servicio, sigue los pasos que se indican en esta página para permitir que las cuentas de servicio se adjunten a otros proyectos.
  2. Identifica el proyecto en el que crearás el recurso.
  3. Identifica el tipo de recurso al que vas a asociar la cuenta de servicio, así como el servicio propietario de ese tipo de recurso.

    Por ejemplo, si estás creando una suscripción de Pub/Sub, Pub/Sub es el servicio propietario del recurso.

  4. Busca la dirección de correo del agente del servicio.

    Cada servicio usa un agente de servicio diferente. Para obtener más información, consulta Agentes de servicio.

  5. Asigna el rol Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) a los agentes de servicio:

    Consola

    1. En la Trusted Cloud consola, ve a la página Cuentas de servicio.

      Ir a Cuentas de servicio

    2. Selecciona el proyecto propietario de la cuenta de servicio que vas a asociar a un recurso.

    3. Haz clic en la dirección de correo de la cuenta de servicio que vas a asociar a un recurso.

    4. Ve a la pestaña Permisos y busca la sección Principales con acceso a esta cuenta de servicio.

    5. Haz clic en Dar acceso y, a continuación, introduce la dirección de correo del agente del servicio.

    6. Haz clic en Selecciona un rol, escribe Service Account Token Creator y haz clic en el rol.

    7. Haz clic en Guardar para guardar los cambios.

    8. Opcional: Si necesitas asignar el rol a otro agente de servicio, repite los pasos anteriores.

    gcloud

    Usa el comando gcloud iam service-accounts add-iam-policy-binding:

    gcloud iam service-accounts add-iam-policy-binding \
        SERVICE_ACCOUNT_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com \
        --member=serviceAccount:SERVICE_AGENT_EMAIL \
        --role=roles/iam.serviceAccountTokenCreator

    Sustituye los siguientes valores:

    • SERVICE_ACCOUNT_NAME: nombre de la cuenta de servicio gestionada por el usuario que vas a asociar a un recurso.
    • PROJECT_ID: ID del proyecto en el que se encuentra la cuenta de servicio gestionada por el usuario.
    • SERVICE_AGENT_EMAIL: la dirección de correo del agente del servicio.

    El comando imprime la política de permisos actualizada para la cuenta de servicio gestionada por el usuario.

    Opcional: Si necesitas conceder el rol a otro agente de servicio, vuelve a ejecutar el comando.

    REST

    Para asignar este rol, usa el patrón de lectura, modificación y escritura para actualizar la política de autorización de tu cuenta de servicio gestionada por el usuario.

    Primero, lee la política de autorización de la cuenta de servicio gestionada por el usuario:

    El método projects.serviceAccounts.getIamPolicy devuelve la política de autorización de la cuenta de servicio.

    Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

    • PROJECT_ID: tu ID de proyecto. Trusted Cloud Los IDs de proyecto son cadenas alfanuméricas, como my-project.
    • USER_SA_NAME: el nombre de la cuenta de servicio gestionada por el usuario que vas a vincular a un recurso.

    Método HTTP y URL:

    POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/USER_SA_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com:getIamPolicy

    Cuerpo JSON de la solicitud:

    {
      "requestedPolicyVersion": 3
    }
    

    Para enviar tu solicitud, despliega una de estas opciones:

    Deberías recibir una respuesta JSON similar a la siguiente:

    {
      "version": 1,
      "etag": "BwWl3KCTUMY=",
      "bindings": [
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "serviceAccount:my-service-account@my-project.s3ns-system.iam.gserviceaccount.com"
          ]
        }
      ]
    }
    

    A continuación, modifica la política de permiso para asignar el rol Creador de tokens de cuenta de servicio al agente de servicio.

    {
      "version": 1,
      "etag": "BwWl3KCTUMY=",
      "bindings": [
        {
          "role": "roles/iam.serviceAccountTokenCreator",
          "members": [
            "serviceAccount:SERVICE_AGENT_EMAIL"
          ]
        },
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com"
          ]
        }
      ]
    }

    Haz los cambios siguientes:

    • SERVICE_AGENT_EMAIL: dirección de correo del agente de servicio
    • SERVICE_ACCOUNT_NAME: nombre de la cuenta de servicio gestionada por el usuario.
    • PROJECT_ID: ID del proyecto en el que se encuentra la cuenta de servicio gestionada por el usuario.

    Por último, escribe la política de permiso actualizada:

    El método projects.serviceAccounts.setIamPolicy actualiza la política de permisos de tu cuenta de servicio.

    Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

    • PROJECT_ID: tu ID de proyecto. Trusted Cloud Los IDs de proyecto son cadenas alfanuméricas, como my-project.
    • USER_SERVICE_ACCOUNT_NAME: el nombre de la cuenta de servicio gestionada por el usuario que vas a vincular a un recurso.
    • SERVICE_AGENT_EMAIL: la dirección de correo del agente de servicio que creará tokens de acceso para tu cuenta de servicio gestionada por el usuario.

    Método HTTP y URL:

    POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com:setIamPolicy

    Cuerpo JSON de la solicitud:

    {
      "policy": {
        "version": 1,
        "etag": "BwWl3KCTUMY=",
        "bindings": [
          {
            "role": "roles/iam.serviceAccountTokenCreator",
            "members": [
              "serviceAccount:SERVICE_AGENT_EMAIL"
            ]
          },
          {
            "role": "roles/iam.serviceAccountUser",
            "members": [
              "serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com"
            ]
          }
        ]
      }
    }
    

    Para enviar tu solicitud, despliega una de estas opciones:

    Deberías recibir una respuesta JSON similar a la siguiente:

    {
      "version": 1,
      "etag": "BwWo331TkHE=",
      "bindings": [
        {
          "role": "roles/iam.serviceAccountTokenCreator",
          "members": [
            "serviceAccount:SERVICE_AGENT_EMAIL"
          ]
        },
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "serviceAccount:my-service-account@my-project.s3ns-system.iam.gserviceaccount.com"
          ]
        }
      ]
    }
    

Asocia la cuenta de servicio al nuevo recurso.

Una vez que hayas configurado la cuenta de servicio gestionada por el usuario, podrás crear un recurso y asociarle la cuenta de servicio. Asegúrate de crear el nuevo recurso en el proyecto adecuado.

Consulta las instrucciones del tipo de recurso que quieras crear:

Asociar una cuenta de servicio al crear un recurso
Compute Engine
Google Kubernetes Engine
Pub/Sub Suscripciones

Una vez que hayas creado el recurso y hayas asociado la cuenta de servicio a ese recurso, puedes asignar roles a la cuenta de servicio para que pueda acceder a los recursos adecuados. Este proceso es el mismo que el de conceder un rol a cualquier otro principal.

Para saber cómo conceder roles, consulta Conceder, cambiar y revocar el acceso a los recursos.

Vincular una cuenta de servicio a un recurso de otro proyecto

De forma predeterminada, no se puede crear una cuenta de servicio en un proyecto y vincularla a un recurso de otro proyecto. Si quieres tener todas tus cuentas de servicio en un solo proyecto, deberás actualizar la política de organización de ese proyecto.

Habilitar la vinculación de cuentas de servicio entre proyectos

Para permitir que los usuarios vinculen cuentas de servicio de un proyecto a recursos de otro proyecto, comprueba las siguientes restricciones booleanas en la política de organización del proyecto en el que se encuentran tus cuentas de servicio:

  • Asegúrate de que la iam.disableCrossProjectServiceAccountUsagerestricción booleana no se aplique al proyecto.

    Esta restricción booleana controla si puedes asociar una cuenta de servicio a un recurso de otro proyecto. Se aplica de forma predeterminada y solo se puede configurar a nivel de proyecto, no de carpeta ni de organización.

    Si no se aplica esta restricción, Gestión de Identidades y Accesos añade una retención del proyecto que impide que se elimine. Esta carga tiene el origen iam.googleapis.com/cross-project-service-accounts. Te recomendamos que no elimines esta retención.

  • Recomendación: asegúrate de que la iam.restrictCrossProjectServiceAccountLienRemovalrestricción booleanase aplique al proyecto.

    Esta restricción booleana asegura que las entidades solo puedan quitar la retención del proyecto si tienen el permiso resourcemanager.projects.updateLiens a nivel de organización. Si no se aplica esta restricción, las entidades pueden quitar la retención del proyecto si tienen este permiso a nivel de proyecto.

Para saber cómo ver o cambiar una restricción booleana en una política de organización, consulta el artículo Crear y gestionar políticas de organización.

Inhabilitar la vinculación de cuentas de servicio entre proyectos

Si ya ha habilitado la opción para adjuntar cuentas de servicio a varios proyectos, le recomendamos que no la inhabilite, sobre todo en entornos de producción.

En concreto, en el proyecto en el que se encuentran tus cuentas de servicio, no debes hacer ninguno de estos cambios:

  • No actualices la política de organización del proyecto para aplicar la restricción booleana iam.disableCrossProjectServiceAccountUsage.
  • No actualices la política de organización del proyecto para no aplicar la restricción booleana iam.restrictCrossProjectServiceAccountLienRemoval.
  • No elimines el lien del proyecto con el origen iam.googleapis.com/cross-project-service-accounts, ya que te impide eliminar el proyecto.
  • No elimines el proyecto.

Si quieres asumir el riesgo de inhabilitar esta función, puedes reducirlo inhabilitando las cuentas de servicio que estés usando en todos los proyectos y, a continuación, monitorizando tu entorno Trusted Cloud para detectar problemas. Si detectas algún problema, puedes volver a habilitar las cuentas de servicio. Si no ves ningún problema, es posible que no tengas ningún Trusted Cloud recurso que dependa de una cuenta de servicio en otro proyecto.

Registros de auditoría para adjuntar cuentas de servicio

Cuando un principal usa el permiso iam.serviceAccounts.actAs para asociar una cuenta de servicio a un recurso, IAM genera un registro de auditoría. Este registro de auditoría contiene la siguiente información:

  • Dirección de correo del principal que ha asociado la cuenta de servicio al recurso
  • Detalles sobre la cuenta de servicio que se adjuntó al recurso

Para ver una lista de los recursos a los que puedes asociar cuentas de servicio, consulta la sección Asociar la cuenta de servicio al nuevo recurso de esta página.

Para ver un ejemplo de este tipo de registro de auditoría, consulta Registros de uso del permiso iam.serviceAccounts.actAs. Para obtener más información sobre los registros de auditoría en general, consulta la descripción general de los registros de auditoría de Cloud.

Siguientes pasos