Gestione dell'impersonificazione degli account di servizio

Questa pagina descrive come consentire alle entità e alle risorse di rubare l'identità o di agire come un account di servizio IAM (Identity and Access Management). Spiega anche come vedere quali entità sono in grado di impersonare un determinato account di servizio IAM.

Prima di iniziare

Autorizzazione delle entità a impersonare account di servizio

Esistono diversi ruoli predefiniti che consentono a un'entità di impersonare un account di servizio:

  • Utente account di servizio (roles/iam.serviceAccountUser): include l'autorizzazione iam.serviceAccounts.actAs, che consente alle entità di accedere indirettamente a tutte le risorse a cui l'account di servizio può accedere. Ad esempio, se un'entità ha il ruolo Utente account di servizio per un account di servizio e l'account di servizio ha il ruolo Amministratore Cloud SQL (roles/cloudsql.admin) nel progetto, l'entità può rappresentare l'account di servizio per creare un'istanza Cloud SQL.

    Questo ruolo consente inoltre alle entità di collegare un account di servizio a una risorsa, come spiegato in questa pagina.

    Questo ruolo non consente alle entità di creare credenziali di breve durata per gli account di servizio o di utilizzare il flag --impersonate-service-account per Google Cloud CLI. Per completare queste attività, devi avere anche il ruolo Creatore token account di servizio.

  • Creatore token account di servizio (roles/iam.serviceAccountTokenCreator): consente alle entità di impersonare account di servizio per creare token di accesso OAuth 2.0, utilizzabili per l'autenticazione con le API di Google. Consente inoltre ai provider di firmare token web JSON (JWT) e blob binari in modo che possano essere utilizzati per l'autenticazione. Per i dettagli, consulta Creazione delle credenziali dell'account di servizio di breve durata.

  • Utente Workload Identity (roles/iam.workloadIdentityUser): consente ai entità di impersonare account di servizio da carichi di lavoro GKE.

In alternativa, puoi concedere un ruolo predefinito diverso o un ruolo personalizzato, che include le stesse autorizzazioni di questi ruoli.

Le seguenti sezioni descrivono come concedere questi ruoli a progetti, cartelle e organizzazioni e come concederli nei singoli account di servizio. Scegli il livello in base al livello di accesso che vuoi concedere:

Autorizzazione di un'entità a utilizzare più account di servizio

Per consentire a un'entità di rappresentare tutti gli account di servizio creati in un progetto, una cartella o un'organizzazione, concedi un ruolo al progetto, alla cartella o all'organizzazione:

console

  1. Nella console, vai alla pagina IAM.

    Vai alla pagina IAM

  2. Dal selettore dei progetti nella parte superiore della pagina, scegli il progetto, la cartella o l'organizzazione a cui vuoi concedere il ruolo.

  3. Fai clic su Aggiungi.

  4. Inserisci l'indirizzo email dell'entità.

  5. Seleziona un ruolo che consenta all'entità di impersonare account di servizio. Consulta l'elenco dei ruoli per il furto d'identità degli account di servizio.

  6. Fai clic su Salva.

gcloud

Per concedere a un'entità un ruolo che gli consente di impersonare un account di servizio, modifica il criterio di autorizzazione per il progetto, la cartella o l'organizzazione.

  1. Leggi il criterio di autorizzazione per la risorsa:

    gcloud resource get-iam-policy resource-id \
        --format=json > policy.json
    

    Sostituisci i seguenti valori:

    • resource: tipo di risorsa per cui vuoi impostare il criterio Consenti. Questo valore deve essere uno dei seguenti: projects, resource-manager folders o organizations.
    • resource-id: l'ID della risorsa su cui vuoi impostare il criterio di autorizzazione.

    Il comando archivia il criterio di autorizzazione della risorsa in un file policy.json.

    Se è già impostato un criterio di autorizzazione nella risorsa, il file policy.json è simile al seguente:

    {
      "bindings": [
        {
          "members": [
            "user:hollis@example.com"
          ],
          "role": "roles/owner"
        }
      ],
      "etag": "BwUqLaVeua8=",
      "version": 1
    }
    

    Se non sono presenti criteri di autorizzazione per la risorsa, il file policy.json contiene solo l'impostazione predefinita etag.

    In assenza di un criterio di autorizzazione esistente, puoi crearlo manualmente utilizzando il file JSON nei passaggi seguenti come modello.

  2. Modifica il criterio di autorizzazione per concedere i ruoli appropriati alle entità. Per concedere un ruolo, procedi in uno dei seguenti modi:

    • Se non esiste un'associazione per il ruolo, aggiungi un oggetto all'array bindings che indichi il ruolo che vuoi concedere e l'entità a cui vuoi concederlo.
    • Se esiste già un'associazione per il ruolo, aggiungi la nuova entità all'elenco delle entità esistenti. Se il criterio di autorizzazione include associazioni di ruoli condizionali, assicurati anche che l'associazione abbia le condizioni appropriate prima di aggiungere l'entità.

    Se l'array bindings non esiste già, puoi crearlo.

    Esempio

    Per concedere il ruolo Utente account di servizio (roles/iam.serviceAccountUser) a robin@example.com, modifica l'esempio mostrato nel passaggio precedente come segue:

    {
      "bindings": [
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "user:robin@example.com"
          ]
        },
        {
          "role": "roles/owner",
          "members": [
            "user:hollis@example.com"
          ]
        }
      ],
      "etag": "BwUqLaVeua8=",
      "version": 1
    }
    
  3. Scrivi il criterio di autorizzazione aggiornato:

    gcloud resource set-iam-policy resource-id \
        policy-file
    

    Sostituisci i seguenti valori:

    • resource: tipo di risorsa per cui vuoi impostare il criterio Consenti. Questo valore deve essere uno dei seguenti: projects, resource-manager folders o organizations.
    • resource-id: l'ID della risorsa su cui vuoi impostare il criterio di autorizzazione.
    • policy-file: percorso del file contenente il criterio di autorizzazione aggiornato.

    Il comando stampa il criterio di autorizzazione aggiornato con un valore etag aggiornato.

REST

Per concedere un ruolo utilizzando l'API REST di Resource Manager, devi leggere il criterio di autorizzazione corrente per il progetto, la cartella o l'organizzazione, modificare il criterio di autorizzazione per concedere i ruoli desiderati e quindi scrivere il criterio di autorizzazione aggiornato.

Leggi il criterio di autorizzazione per la risorsa.

Il metodo getIamPolicy dell'API Resource Manager ottiene un criterio di autorizzazione per un progetto, una cartella o per un'organizzazione.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • API_VERSION: la versione API da utilizzare. Per progetti e organizzazioni, utilizza v1. Per le cartelle, utilizza v2.
  • RESOURCE_TYPE: il tipo di risorsa di cui vuoi gestire il criterio. Utilizza il valore projects, folders o organizations.
  • RESOURCE_ID: ID progetto, organizzazione o cartella di Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project. Gli ID delle cartelle e delle organizzazioni sono numerici, ad esempio 123456789012.
  • POLICY_VERSION: la versione del criterio da restituire. Le richieste devono specificare la versione più recente del criterio, ovvero la versione 3. Per maggiori dettagli, vedi Specificare la versione di un criterio durante l'acquisizione di un criterio.

Metodo HTTP e URL:

POST https://cloudresourcemanager.googleapis.com/API_VERSION/RESOURCE_TYPE/RESOURCE_ID:getIamPolicy

Corpo JSON richiesta:

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

La risposta contiene il criterio di autorizzazione della risorsa. Ad esempio:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/owner",
      "members": [
        "user:owner@example.com"
      ]
    }
  ]
}

In assenza di un criterio di autorizzazione esistente, la risposta contiene solo il valore predefinito etag. Se ottieni questa risposta, aggiungi un campo version, impostato su 3, e un campo bindings, impostato su un array vuoto.

Modifica il criterio di autorizzazione per concedere i ruoli appropriati alle entità.

Per concedere un ruolo, esegui una delle seguenti operazioni:

  • Se non esiste un'associazione per il ruolo, aggiungi un oggetto all'array bindings che indichi il ruolo che vuoi concedere e l'entità a cui vuoi concederlo.
  • Se esiste già un'associazione per il ruolo, aggiungi la nuova entità all'elenco delle entità esistenti.

Esempio:

Per concedere il ruolo Utente account di servizio (roles/iam.serviceAccountUser) a robin@example.com, modifica l'esempio riportato nel passaggio precedente come segue:

{
  "version": 1,
  "etag": "BwUqLaVeua8=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "user:robin@example.com"
      ]
    },
    {
      "role": "roles/owner",
      "members": [
        "user:owner@example.com"
      ]
    }
  ]
}

Scrivi il criterio di autorizzazione aggiornato.

Il metodo setIamPolicy dell'API Resource Manager imposta il criterio nella richiesta come nuovo criterio di autorizzazione per il progetto, la cartella o l'organizzazione.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • API_VERSION: la versione API da utilizzare. Per progetti e organizzazioni, utilizza v1. Per le cartelle, utilizza v2.
  • RESOURCE_TYPE: il tipo di risorsa di cui vuoi gestire il criterio. Utilizza il valore projects, folders o organizations.
  • RESOURCE_ID: ID progetto, organizzazione o cartella di Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project. Gli ID delle cartelle e delle organizzazioni sono numerici, ad esempio 123456789012.
  • POLICY: una rappresentazione JSON del criterio che vuoi impostare. Per ulteriori informazioni sul formato di un criterio, consulta il riferimento per i criteri.

    Ad esempio, per impostare il criterio di autorizzazione mostrato nel passaggio precedente, sostituisci POLICY con il seguente:

    {
      "version": 1,
      "etag": "BwUqLaVeua8=",
      "bindings": [
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "user:robin@example.com"
          ]
        },
        {
          "role": "roles/owner",
          "members": [
            "user:owner@example.com"
          ]
        }
      ]
    }
    

Metodo HTTP e URL:

POST https://iam.googleapis.com/API_VERSION/RESOURCE_TYPE/RESOURCE_ID:setIamPolicy

Corpo JSON richiesta:

{
  "policy": POLICY
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

La risposta contiene il criterio di autorizzazione aggiornato.

Autorizzazione di un'entità a utilizzare un solo account di servizio

Per consentire a un'entità di rappresentare un singolo account di servizio, concedi un ruolo all'account di servizio:

console

  1. Nella console, vai alla pagina Account di servizio.

    Vai alla pagina Account di servizio

  2. Seleziona un progetto.

  3. Fai clic sull'indirizzo email dell'account di servizio di cui vuoi consentire l'impersonificazione.

  4. Fai clic sulla scheda Autorizzazioni.

  5. In Entità con accesso a questo account di servizio, fai clic su Concedi l'accesso.

  6. Inserisci l'indirizzo email dell'entità.

  7. Seleziona un ruolo che autorizza l'entità a rappresentare gli account di servizio. Consulta l'elenco dei ruoli per il furto d'identità degli account di servizio.

  8. Fai clic su Salva per applicare il ruolo all'entità.

Per concedere i ruoli su più account di servizio, ripeti questi passaggi per ogni account di servizio.

gcloud

Per concedere a un'entità un ruolo che gli consente di impersonare un account di servizio, modifica il criterio di autorizzazione per il tuo account di servizio.

  1. Utilizza il comando service-accounts get-iam-policy per leggere il criterio di autorizzazione corrente:

    gcloud iam service-accounts get-iam-policy sa-id \
        --format=json > policy.json
    

    Sostituisci i seguenti valori:

    • sa-id: l'ID del tuo account di servizio. Può essere l'indirizzo email dell'account di servizio nel formato sa-name@project-id.iam.gserviceaccount.com o l'ID numerico univoco dell'account di servizio.

    Il comando archivia il criterio di autorizzazione dell'account di servizio in un file policy.json.

    Se è già impostato un criterio di autorizzazione nell'account di servizio, il file policy.json è simile al seguente:

    {
      "bindings": [
        {
          "members": [
            "user:hollis@example.com"
          ],
          "role": "roles/iam.serviceAccountAdmin"
        }
      ],
      "etag": "BwUqLaVeua8=",
      "version": 1
    }
    

    Se nell'account di servizio non è configurato alcun criterio di autorizzazione, il file policy.json contiene solo il valore predefinito di etag.

    In assenza di un criterio di autorizzazione esistente, puoi crearlo manualmente utilizzando il file JSON nei passaggi seguenti come modello.

  2. In un editor di testo, modifica l'array delle associazioni nel file policy.json per concedere i ruoli appropriati alle entità. Per concedere un ruolo, esegui una delle seguenti operazioni:

    • Se non esiste un'associazione per il ruolo, aggiungi un nuovo oggetto all'array di bindings che definisce il ruolo che vuoi concedere e l'entità a cui vuoi concederlo.
    • Se esiste già un'associazione per il ruolo, aggiungi la nuova entità all'elenco delle entità esistenti. Se il criterio di autorizzazione include associazioni di ruoli condizionali, assicurati anche che l'associazione abbia le condizioni appropriate prima di aggiungere l'entità.

    Se l'array bindings non esiste già, puoi crearlo.

    Esempio

    Per concedere il ruolo Utente account di servizio (roles/iam.serviceAccountUser) a robin@example.com, modifica l'esempio mostrato nel passaggio precedente come segue:

    {
      "bindings": [
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "user:robin@example.com"
          ]
        },
        {
          "role": "roles/iam.serviceAccountAdmin",
          "members": [
            "user:hollis@example.com"
          ]
        }
      ],
      "etag": "BwUqLaVeua8=",
      "version": 1
    }
    
  3. Utilizza il comando service-accounts set-iam-policy per scrivere il criterio di autorizzazione aggiornato:

    gcloud iam service-accounts set-iam-policy sa-id \
        policy-file
    

    Sostituisci i seguenti valori:

    • sa-id: l'ID del tuo account di servizio. Può essere l'indirizzo email dell'account di servizio nel formato sa-name@project-id.iam.gserviceaccount.com o l'ID numerico univoco dell'account di servizio.
    • policy-file: percorso del file contenente il criterio di autorizzazione aggiornato.

    Il comando stampa il criterio di autorizzazione aggiornato con un valore etag aggiornato.

REST

Per concedere un ruolo utilizzando l'API IAM IAM, devi leggere il criterio di autorizzazione corrente dell'account di servizio, modificarlo per concedere i ruoli desiderati e quindi scrivere il criterio di autorizzazione aggiornato.

Leggi le norme di autorizzazione dell'account di servizio.

Il metodo serviceAccounts.getIamPolicy riceve un criterio di autorizzazione dell'account di servizio.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project.
  • SA_ID: l'ID del tuo account di servizio. Può essere l'indirizzo email dell'account di servizio nel modulo SA_NAME@PROJECT_ID.iam.gserviceaccount.com o l'ID numerico univoco dell'account di servizio.

  • POLICY_VERSION: la versione del criterio da restituire. Le richieste devono specificare la versione più recente del criterio, ovvero la versione 3. Per maggiori dettagli, vedi Specificare la versione di un criterio durante l'acquisizione di un criterio.

Metodo HTTP e URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:getIamPolicy

Corpo JSON richiesta:

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

La risposta contiene il criterio di autorizzazione dell'account di servizio. Ad esempio:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

In assenza di un criterio di autorizzazione esistente, la risposta contiene solo il valore predefinito etag. Se ottieni questa risposta, aggiungi un campo version, impostato su 3, e un campo bindings, impostato su un array vuoto.

Modifica il criterio di autorizzazione per concedere i ruoli appropriati alle entità.

In un editor di testo, modifica l'array delle associazioni dal corpo della risposta per concedere i ruoli appropriati alle entità. Per concedere un ruolo, esegui una delle seguenti operazioni:

  • Se non esiste un'associazione per il ruolo, aggiungi un nuovo oggetto all'array di bindings che definisce il ruolo che vuoi concedere e l'entità a cui vuoi concederlo.
  • Se esiste già un'associazione per il ruolo, aggiungi la nuova entità all'elenco delle entità esistenti.

Esempio:

Per concedere il ruolo Utente account di servizio (roles/iam.serviceAccountUser) a robin@example.com, modifica l'esempio riportato nel passaggio precedente come segue:

{
  "version": 1,
  "etag": "BwUqLaVeua8=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "user:robin@example.com"
      ]
    },
    {
      "role": "roles/iam.serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Scrivi il criterio di autorizzazione aggiornato.

Il metodo serviceAccounts.setIamPolicy imposta un criterio di autorizzazione aggiornato per l'account di servizio.

Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

  • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project.
  • SA_ID: l'ID del tuo account di servizio. Può essere l'indirizzo email dell'account di servizio nel modulo SA_NAME@PROJECT_ID.iam.gserviceaccount.com o l'ID numerico univoco dell'account di servizio.

  • POLICY: una rappresentazione JSON del criterio che vuoi impostare. Per ulteriori informazioni sul formato di un criterio, consulta il riferimento per i criteri.

    Ad esempio, per impostare il criterio di autorizzazione mostrato nel passaggio precedente, sostituisci policy con il seguente:

    {
      "version": 1,
      "etag": "BwUqLaVeua8=",
      "bindings": [
        {
          "role": "roles/iam.serviceAccountUser",
          "members": [
            "user:robin@example.com"
          ]
        },
        {
          "role": "roles/serviceAccountAdmin",
          "members": [
            "user:admin@example.com"
          ]
        }
      ]
    }
    

Metodo HTTP e URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:setIamPolicy

Corpo JSON richiesta:

{
  "policy": POLICY
}

Per inviare la richiesta, espandi una delle seguenti opzioni:

La risposta contiene il criterio di autorizzazione aggiornato.

Entità dell'elenco che possono accedere a un account di servizio

Utilizza la console per visualizzare tutte le entità che hanno accesso a un account di servizio a causa dei ruoli concessi nell'account di servizio o per i ruoli concessi nel progetto, nella cartella o nell'organizzazione:

  1. Nella console, vai alla pagina Account di servizio.

    Vai a Account di servizio

  2. Seleziona un progetto.

  3. Fai clic sull'indirizzo email dell'account di servizio di cui vuoi consentire l'impersonificazione.

  4. Fai clic sulla scheda Autorizzazioni. La sezione Entità con accesso a questo account di servizio elenca le entità che possono accedere all'account di servizio.

Collegamento di un account di servizio a una risorsa

Per alcune risorse Google Cloud, puoi specificare un account di servizio gestito dall'utente che la risorsa utilizza come identità predefinita. Questa procedura è nota come collegamento dell'account di servizio alla risorsa o associazione dell'account di servizio alla risorsa.

Quando una risorsa deve accedere ad altri servizi e risorse Google Cloud, rappresenta l'account di servizio collegato a se stesso. Ad esempio, se colleghi un account di servizio a un'istanza di Compute Engine e le applicazioni sull'istanza utilizzano una libreria client per chiamare le API Google Cloud, tali applicazioni riproducono automaticamente l'account di servizio associato.

Nella maggior parte dei casi, devi collegare un account di servizio a una risorsa al momento della sua creazione. Dopo aver creato la risorsa, non puoi cambiarne l'account di servizio collegato. Le istanze Compute Engine sono un'eccezione a questa regola; puoi modificare l'account di servizio associato a un'istanza in base alle esigenze.

Prima di collegare un account di servizio a una risorsa, devi configurarlo. Questo processo varia a seconda che l'account di servizio e la risorsa si trovino nello stesso progetto o in progetti diversi. Dopo aver configurato l'account di servizio, puoi creare la risorsa e collegarla alla stessa.

Configurazione per una risorsa nello stesso progetto

Prima di collegare un account di servizio a un'altra risorsa nello stesso progetto, concedi i ruoli all'account di servizio in modo che possa accedere alle risorse appropriate, proprio come faresti per qualsiasi altro ruolo.

Configurazione per una risorsa in un progetto diverso

In alcuni casi, potresti dover collegare un account di servizio a una risorsa che si trova in un progetto diverso. Ad esempio, se crei tutti gli account di servizio in un unico progetto, potrebbe essere necessario collegarne uno a una nuova risorsa in un altro progetto.

Prima di collegare un account di servizio a una risorsa in un altro progetto:

  1. Nel progetto in cui si trova l'account di servizio, segui i passaggi descritti in questa pagina per attivare la rappresentazione dell'account di servizio nei progetti.
  2. Identifica il progetto in cui creerai la risorsa.
  3. Identifica il tipo di risorsa a cui collegherai l'account di servizio, nonché il servizio a cui appartiene.

    Ad esempio, se stai creando una sottoscrizione Pub/Sub, Pub/Sub è il servizio proprietario della risorsa.

  4. Trova l'indirizzo email dell'agente di servizio per il servizio.

    Servizi diversi utilizzano agenti di servizio diversi. Per maggiori dettagli, vedi Agenti di servizio.

  5. Concedi il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) agli agenti di servizio:

    console

    1. Nella console, vai alla pagina Account di servizio.

      Vai agli account di servizio

    2. Seleziona il progetto proprietario dell'account di servizio che collegherai a una risorsa.

    3. Trova l'account di servizio che collegherai a una risorsa e seleziona la relativa casella di controllo.

    4. Nel riquadro Autorizzazioni, fai clic su Aggiungi entità.

    5. Nel campo Nuove entità, inserisci l'indirizzo email dell'agente di servizio.

    6. Nell'elenco a discesa Seleziona un ruolo, digita Service Account Token Creator, quindi fai clic sul ruolo.

    7. Fai clic su Salva per salvare le modifiche.

    8. (Facoltativo) Se devi concedere il ruolo a un altro agente di servizio, ripeti i passaggi precedenti.

    gcloud

    Utilizza il comando gcloud iam service-accounts add-iam-policy-binding:

    gcloud iam service-accounts add-iam-policy-binding \
        user-sa-name@project-id.iam.gserviceaccount.com \
        --member=serviceAccount:service-agent-email \
        --role=roles/iam.serviceAccountTokenCreator
    

    Sostituisci i seguenti valori:

    • user-sa-name: nome dell'account di servizio gestito dall'utente che stai collegando a una risorsa.
    • project-id: l'ID progetto in cui si trova l'account di servizio gestito dall'utente.
    • service-agent-email: l'indirizzo email dell'agente di servizio.

    Il comando stampa il criterio di autorizzazione aggiornato per l'account di servizio gestito dall'utente.

    Facoltativo: se devi concedere il ruolo a un altro agente di servizio, esegui di nuovo il comando.

    REST

    Per concedere questo ruolo, utilizza il pattern di lettura, modifica e scrittura per aggiornare il criterio di autorizzazione per il tuo account di servizio gestito dall'utente.

    Per prima cosa, leggi il criterio di autorizzazione per l'account di servizio gestito dall'utente:

    Il metodo projects.serviceAccounts.getIamPolicy restituisce il criterio di autorizzazione per l'account di servizio.

    Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

    • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project.
    • USER_SA_NAME: nome dell'account di servizio gestito dall'utente che stai associando a una risorsa.

    Metodo HTTP e URL:

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

    Corpo JSON richiesta:

    {
      "requestedPolicyVersion": 3
    }
    

    Per inviare la richiesta, espandi una delle seguenti opzioni:

    Dovresti ricevere una risposta JSON simile alla seguente:

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

    Quindi, modifica il criterio di autorizzazione per concedere il ruolo Creatore token account di servizio all'agente di servizio. Sostituisci SERVICE_AGENT_EMAIL con l'indirizzo email dell'agente di servizio:

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

    Infine, scrivi la norma di autorizzazione aggiornata:

    Il metodo projects.serviceAccounts.setIamPolicy aggiorna il criterio di autorizzazione per il tuo account di servizio.

    Prima di utilizzare i dati della richiesta, effettua le seguenti sostituzioni:

    • PROJECT_ID: ID progetto Google Cloud. Gli ID progetto sono stringhe alfanumeriche, ad esempio my-project.
    • USER_SA_NAME: nome dell'account di servizio gestito dall'utente che stai associando a una risorsa.
    • SERVICE_AGENT_EMAIL: indirizzo email dell'agente di servizio che creerà token di accesso per il tuo account di servizio gestito dall'utente.

    Metodo HTTP e URL:

    POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/USER_SA_NAME@PROJECT_ID.iam.gserviceaccount.com:setIamPolicy

    Corpo JSON richiesta:

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

    Per inviare la richiesta, espandi una delle seguenti opzioni:

    Dovresti ricevere una risposta JSON simile alla seguente:

    {
      "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.iam.gserviceaccount.com"
          ]
        }
      ]
    }
    

Collegamento dell'account di servizio alla nuova risorsa

Dopo aver configurato l'account di servizio gestito dall'utente, puoi creare una nuova risorsa e collegare l'account di servizio alla risorsa. Assicurati di creare la nuova risorsa nel progetto appropriato.

Consulta le istruzioni per il tipo di risorsa che vuoi creare:

Collegamento di un account di servizio durante la creazione di una risorsa
AI Platform Prediction Versioni del modello
AI Platform Training Job
Ambiente standard di App Engine Versioni dell'app
Ambiente flessibile di App Engine Versioni dell'app
Cloud Composer Ambienti
Cloud Functions Funzione Cloud
Cloud Life Sciences Pipeline
Cloud Run Servizi
Cloud Scheduler Job
Cloud Source Repositories
Compute Engine
Dataflow Job
Datalab Istanze
Dataproc Cluster
Google Kubernetes Engine
Notebooks Istanze blocco note
Pub/Sub Abbonamenti
Vertex AI
Workflows Workflows

Dopo aver creato la risorsa e collegato l'account di servizio alla risorsa, puoi concedere ruoli all'account di servizio in modo che possa accedere alle risorse appropriate. Questa procedura è uguale a quella concessa a un qualsiasi altro ruolo.

Per informazioni su come concedere i ruoli, consulta Concedere, modificare e revocare l'accesso alle risorse.

Interpretare gli audit log

Gli audit log di Cloud ti aiutano a rispondere alle domande "chi ha fatto cosa, dove e quando?" per le risorse Google Cloud.

Quando utilizzi credenziali di breve durata per impersonare un account di servizio, la maggior parte dei servizi Google Cloud crea voci di log che mostrano le seguenti identità:

  • L'account di servizio che le credenziali di breve durata usano per furto d'identità
  • L'identità che ha creato le credenziali di breve durata

Puoi utilizzare queste voci di log per identificare l'entità che ha creato le credenziali di breve durata, nonché l'account di servizio che ha rappresentato l'entità.

Per esempi di voci di log di controllo che mostrano la rappresentazione dell'account di servizio, consulta la pagina Impersonare un account di servizio per accedere a Google Cloud.

Abilita la rappresentazione dell'account di servizio nei progetti

Per impostazione predefinita, non puoi creare un account di servizio in un progetto e collegarlo a una risorsa in un altro progetto. Se vuoi mantenere tutti gli account di servizio in un progetto, devi aggiornare il criterio dell'organizzazione per quel progetto.

Nel criterio dell'organizzazione relativo al progetto in cui si trovano gli account di servizio, verifica i seguenti vincoli booleani:

  • Assicurati che il vincolo booleano iam.disableCrossProjectServiceAccountUsage non sia applicato per il progetto.

    Questo vincolo booleano controlla se puoi collegare un account di servizio a una risorsa in un altro progetto. Il vincolo viene applicato per impostazione predefinita.

    Quando questo vincolo non viene applicato, IAM aggiunge un pezzo progetto che ne impedisce l'eliminazione. Questo blocco ha l'origine iam.googleapis.com/cross-project-service-accounts. Ti sconsigliamo vivamente di eliminare questo blocco.

  • Opzione consigliata: assicurati che il vincolo booleano iam.restrictCrossProjectServiceAccountLienRemoval sia applicato per il progetto.

    Questo vincolo booleano assicura che le entità possano rimuovere il blocco progetto solo se dispongono dell'autorizzazione resourcemanager.projects.updateLiens a livello di organizzazione. Se questo vincolo non viene applicato, le entità possono rimuovere il blocco progetto se hanno questa autorizzazione a livello di progetto.

Per scoprire come visualizzare o modificare un vincolo booleano in un criterio dell'organizzazione, consulta la sezione Impostazione di un vincolo booleano.

Disabilita la rappresentazione dell'account di servizio nei progetti

Se in precedenza hai attivato la rappresentazione dell'account di servizio nei progetti, ti sconsigliamo vivamente di disattivare questa funzionalità, soprattutto negli ambienti di produzione.

Nello specifico, nel progetto in cui si trovano i tuoi account di servizio non devi apportare nessuna di queste modifiche:

  • Non aggiornare il criterio dell'organizzazione del progetto per applicare il vincolo booleano iam.disableCrossProjectServiceAccountUsage.
  • Non aggiornare il criterio dell'organizzazione del progetto per non applicare il vincolo booleano iam.restrictCrossProjectServiceAccountLienRemoval.
  • Non rimuovere il pezzo del progetto con l'origine iam.googleapis.com/cross-project-service-accounts, per evitare che venga eliminato.
  • Non eliminare il progetto.

Se vuoi accettare il rischio di disattivare questa funzionalità, puoi ridurre il rischio disattivando gli account di servizio che stai utilizzando nei progetti e monitorando l'ambiente Google Cloud per individuare eventuali problemi. In caso di problemi, puoi riattivare gli account di servizio. Se non vedi problemi, potresti non disporre di risorse Google Cloud che dipendono da un account di servizio in un altro progetto.

Passaggi successivi