Policy di Principal Access Boundary

Le policy di Principal Access Boundary (PAB) ti consentono di definire le risorse a cui le entità possono accedere.

Ad esempio, puoi utilizzare le policy di Principal Access Boundary per impedire alle tue entità di accedere alle risorse di altre organizzazioni, il che può contribuire a prevenire attacchi di phishing o l'esfiltrazione di dati.

Per scoprire gli altri tipi di criteri di controllo dell'accesso dell'accesso offerti da Identity and Access Management (IAM), consulta la sezione Tipi di criteri.

Come funzionano le policy di Principal Access Boundary

Per impostazione predefinita, le entità sono idonee ad accedere a qualsiasi risorsa. Google Cloud Ciò significa che se un'entità dispone di un'autorizzazione per la risorsa e non le è stata negata l'autorizzazione, può utilizzarla per accedere alla risorsa.

Con le policy di Principal Access Boundary, puoi definire le risorse a cui un'entità può accedere. Se un criterio di Principal Access Boundary rende un'entità non idonea ad accedere a una risorsa, il suo accesso a quella risorsa è limitato, indipendentemente dai ruoli che le sono stati concessi.

Quando le entità tentano di accedere a risorse a cui non hanno diritto, le policy di Principal Access Boundary possono bloccare alcune, ma non tutte, le autorizzazioni IAM (Identity and Access Management). Per scoprire di più su quali autorizzazioni vengono bloccate, consulta Autorizzazioni che Principal Access Boundary può bloccare.

Le policy di Principal Access Boundary sono costituite da regole di Principal Access Boundary. Ogni regola Principal Access Boundary definisce un insieme di risorse a cui le entità interessate possono accedere. Puoi creare fino a 1000 policy di Principal Access Boundary nella tua organizzazione.

Dopo aver creato una policy di Principal Access Boundary, crea un'associazione policy per applicare la policy a un insieme di entità.

Un'entità può essere soggetta a una o più policy di Principal Access Boundary. Ogni entità può accedere solo alle risorse elencate in queste policy. Per tutte le altre risorse, l'accesso dell'entità a quella risorsa è limitato, anche se concedi ruoli all'entità su quella risorsa.

Poiché le policy di Principal Access Boundary sono associate alle entità e non alle risorse, puoi utilizzarle per impedire alle entità di accedere alle risorse che non ti appartengono. Ad esempio, considera lo scenario seguente:

• Il preside Tal (tal@example.com) fa parte dell'organizzazione Google Workspace example.com.
• A Tal viene concesso il ruolo di amministratore di Storage (roles/storage.admin) in un bucket Cloud Storage in un'altra organizzazione, cymbalgroup.com. Questo ruolo contiene l'autorizzazione storage.objects.get, necessaria per visualizzare gli oggetti nel bucket.
• Non esistono policy di negazione in cymbalgroup.com che impediscono a Tal di utilizzare l'autorizzazione storage.objects.get.

Con le sole norme di autorizzazione e negazione, example.com non può impedire a Tal di visualizzare gli oggetti in questo bucket esterno. Nessuna entità example.com ha l'autorizzazione per modificare il criterio di autorizzazione del bucket, pertanto non può revocare il ruolo di Tal. Inoltre, non ha l'autorizzazione per creare criteri di negazione in cymbalgroup.com, pertanto non può utilizzare un criterio di negazione per impedire a Tal di accedere al bucket.

Tuttavia, con i criteri di Principal Access Boundary, gli amministratori di example.com possono assicurarsi che Tal non possa visualizzare gli oggetti nel bucket cymbalgroup.com o in qualsiasi bucket al di fuori di example.com. A questo scopo, gli amministratori possono creare una policy di Principal Access Boundary che stabilisca che le entità example.com sono idonee ad accedere alle risorse solo in example.com. Poi possono creare un'associazione di criteri per collegare questi criteri a tutte le entità dell'organizzazione example.com. Con un criterio di questo tipo, Tal non potrà visualizzare gli oggetti nel bucket cymbalgroup.com, anche se gli è stato concesso il ruolo di amministratore Storage nel bucket.

Valutazione con esito negativo

Le policy di Principal Access Boundary non sono riuscite. Ciò significa che, se IAM non riesce a valutare un criterio del limite di accesso all'entità quando valuta l'accesso di un'entità, impedisce all'entità di accedere alla risorsa.

Il motivo più comune per cui IAM non è in grado di valutare le policy di Principal Access Boundary è che i dettagli di un'entità sono ancora in fase di propagazione nel sistema. Ciò si verifica più probabilmente per gli utenti appena creati. Per risolvere il problema, chiedi alla nuova entità di attendere e di provare ad accedere di nuovo alla risorsa in un secondo momento.

Autorizzazioni bloccate dalle policy di Principal Access Boundary

Quando le entità tentano di accedere a una risorsa a cui non possono accedere, i criteri di Principal Access Boundary impediscono loro di utilizzare alcune, ma non tutte, le autorizzazioni Identity and Access Management (IAM) per accedere alla risorsa.

Se un criterio di Principal Access Boundary blocca un'autorizzazione, IAM applica i criteri di Principal Access Boundary per quell'autorizzazione. In altre parole, impedisce a qualsiasi entità che non ha l'idoneità per accedere a una risorsa di utilizzare questa autorizzazione per accedere alla risorsa.

Se una policy di Principal Access Boundary non blocca un'autorizzazione, le policy di Principal Access Boundary non influiscono sulla possibilità delle entità di utilizzare l'autorizzazione.

Ad esempio, supponiamo che a un'entità, Lee (lee@example.com), venga concesso il ruolo Sviluppatore Dataflow (roles/dataflow.developer). Questo ruolo include l'autorizzazione dataflow.jobs.snapshot, che consente a Lee di creare snapshot dei job Dataflow. Lee è anche soggetto a una policy di Principal Access Boundary che lo rende non idoneo ad accedere alle risorse al di fuori di example.com. Tuttavia, se i criteri perimetrali di accesso del principal non bloccano l'autorizzazione dataflow.jobs.snapshot, Lee può comunque acquisire snapshot dei job Dataflow nelle organizzazioni al di fuori di example.com.

Le autorizzazioni bloccate da un criterio di Principal Access Boundary dipendono dalla versione dell'applicazione del Principal Access Boundary.

Versioni di applicazione di Principal Access Boundary

Ogni criterio di Principal Access Boundary specifica una versione di applicazione, che identifica un elenco predefinito di autorizzazioni IAM che il criterio di Principal Access Boundary può bloccare. Specifichi la versione di applicazione quando crei o aggiorni una policy di Principal Access Boundary. Se non specifichi una versione dell'applicazione, IAM utilizza l'ultima versione dell'applicazione e continuerà a utilizzarla finché non la aggiorni.

Periodicamente, IAM aggiunge nuove versioni dell'applicazione dei limiti di accesso all'entità che possono bloccare autorizzazioni aggiuntive. Ogni nuova versione può anche bloccare tutte le autorizzazioni della versione precedente.

Per bloccare le autorizzazioni in una nuova versione di applicazione, devi aggiornare i criteri del perimetro di accesso del principal in modo che utilizzino la nuova versione. Se vuoi che la versione di applicazione venga aggiornata automaticamente man mano che vengono rilasciate nuove versioni, puoi utilizzare il valore latest durante la creazione del criterio. Tuttavia, sconsigliamo di utilizzare questo valore perché potrebbe causare la perdita imprevista dell'accesso alle risorse da parte dei principal.

Per un elenco completo delle autorizzazioni bloccate da ogni versione di applicazione, consulta Autorizzazioni bloccate dai criteri di Principal Access Boundary.

Associa le policy di Principal Access Boundary ai set di entità

Per associare una policy di Principal Access Boundary a un set di entità, crea un'associazione policy che specifica sia la policy di Principal Access Boundary che vuoi applicare sia il set di entità per cui vuoi applicarla. Dopo aver associato il criterio a un insieme di entità, le entità di questo insieme possono accedere solo alle risorse incluse nelle regole del criterio di Principal Access Boundary.

Puoi associare una policy di Principal Access Boundary a un numero qualsiasi di set di entità. A ogni insieme di entità possono essere associate fino a 10 policy di Principal Access Boundary.

Puoi creare associazioni solo per le policy di Principal Access Boundary esistenti. Il tentativo di creare un'associazione per una policy di Principal Access Boundary eliminata non andrà a buon fine. Se hai eliminato di recente una policy di Principal Access Boundary, a volte puoi creare un'associazione, ma l'associazione non avrà alcun effetto. IAM pulisce automaticamente questi binding.

Per scoprire come gestire le policy di Principal Access Boundary, consulta Creare e applicare policy di Principal Access Boundary.

Set di entità supportati

La tabella seguente elenca i tipi di insiemi di entità a cui puoi associare le policy di Principal Access Boundary. Ogni riga contiene quanto segue:

• Il tipo di set di entità
• Le entità in quel tipo di set di entità
• Il formato degli ID per quel tipo di set di entità
• La risorsa Resource Manager (progetto, cartella o organizzazione) che contiene le associazioni di policy per quel tipo di set di entità

Associazioni di policy condizionali per le policy di Principal Access Boundary

Puoi utilizzare le espressioni di condizione nelle associazioni di policy per le policy di Principal Access Boundary per perfezionare ulteriormente le entità a cui si applica la policy.

Le espressioni di condizione per le associazioni di policy sono costituite da una o più istruzioni unite da un massimo di 10 operatori logici (&&, || o !). Ogni istruzione esprime una regola di controllo basata sugli attributi che si applica all'associazione di policy e determina se la policy si applica.

Puoi utilizzare gli attributi principal.type e principal.subject nelle condizioni per i vincoli dei criteri. Nessun altro attributo è supportato nelle condizioni per i binding delle norme.

• L'attributo principal.type indica il tipo di entità presente nella richiesta, ad esempio service account o identità in un pool di identità per i workload. Puoi utilizzare le condizioni con questo attributo per controllare a quali tipi di entità si applica una policy di Principal Access Boundary.

  Ad esempio, se aggiungi la seguente espressione di condizione a un'associazione per un criterio di Principal Access Boundary, il criterio si applica solo ai service account:

  principal.type == 'iam.googleapis.com/ServiceAccount'
  

• L'attributo principal.subject indica l'identità del principal nella richiesta, ad esempio cruz@example.com. Puoi utilizzare le condizioni con questo attributo per controllare esattamente quali entità sono soggette a un criterio di Principal Access Boundary.

  Ad esempio, se aggiungi la seguente espressione di condizione a un'associazione per una policy di Principal Access Boundary, la policy non verrà applicata all'utente special-admin@example.com:

  principal.subject != 'special-admin@example.com'
  

Per scoprire di più sui valori che puoi utilizzare per queste condizioni, consulta il riferimento all'attributo condizioni.

Esempio: utilizza le condizioni per ridurre le risorse a cui un'entità può accedere

Uno dei modi in cui puoi utilizzare le condizioni nei binding delle policy di Principal Access Boundary è ridurre le risorse a cui una singola entità può accedere.

Supponiamo che tu abbia un account di servizio, dev-project-service-account, con l'indirizzo email dev-project-service-account@dev-project.iam.gserviceaccount.com. Questo account di servizio è soggetto a un criterio di Principal Access Boundary che rende le entità idonee ad accedere a tutte le risorse dell'organizzazione example.com. Questo criterio è associato al set di entità dell'organizzazione example.com.

Decidi che dev-project-service-account non deve avere l'idoneità per accedere a tutte le risorse in example.com, ma solo a quelle in dev-project. Tuttavia, non vuoi modificare le risorse a cui possono accedere le altre entità nel set di entità example.com.

Per apportare questa modifica, segui la procedura per ridurre le risorse a cui le entità possono accedere, ma aggiungi una condizione al binding del criterio anziché eliminarlo:

1. Confermi che l'unica policy di Principal Access Boundary a cui dev-project-service-account è soggetta è la policy che rende le entità idonee ad accedere a tutte le risorse in example.com.

2. Crea una nuova policy di Principal Access Boundary che renda le entità idonee ad accedere alle risorse in dev-project e collegala al set di entità per dev-project. Utilizza la seguente condizione nel binding della policy per assicurarti che la policy venga applicata solo per dev-project-service-account:

   "condition": {
     "title": "Only dev-project-service-account",
     "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.iam.gserviceaccount.com'"
   }
   

3. Esoneri dev-project-service-account dalla policy di Principal Access Boundary che rende le entità idonee ad accedere a tutte le risorse in example.com. Per farlo, aggiungi la seguente condizione all'associazione di policy che collega la policy di Principal Access Boundary al set di entità dell'organizzazione:

   "condition": {
     "title": "Exempt dev-project-service-account",
     "expression": "principal.subject != 'dev-project-service-account@dev-project.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
   }
   

   Per scoprire come aggiornare le policy di Principal Access Boundary esistenti, consulta Modificare le policy di Principal Access Boundary.

Dopo aver aggiunto questa condizione all'associazione di policy, dev-project-service-account non è più idoneo ad accedere a tutte le risorse in example.com, ma solo a quelle in dev-project.

Associazioni di criteri tra organizzazioni

Non puoi creare un'associazione di policy cross-organization per una policy di Principal Access Boundary. Un'associazione di criteri tra organizzazioni è un'associazione di criteri che associa un criterio di un'organizzazione a un set di entità di un'altra organizzazione.

IAM elimina periodicamente tutti i binding dei criteri tra organizzazioni esistenti. I binding dei criteri tra organizzazioni possono verificarsi quando sposti un progetto da un'organizzazione a un'altra. Ad esempio, considera la seguente situazione:

• Hai un progetto, example-project, nell'organizzazione example.com.
• Vuoi che le entità in example-project siano idonee ad accedere alle risorse in example.com. A questo scopo, crea una policy di Principal Access Boundary in example.com che renda le entità idonee ad accedere alle risorse in example.com e associa questa policy al set di entità per example-project.
• Sposti example-project da example.com a cymbalgroup.com.

In questa situazione, lo spostamento del progetto creerebbe un'associazione di policy tra organizzazioni. Questo perché la policy di Principal Access Boundary in example.com sarebbe associata a un set di entità in cymbalgroup.com. Se non elimini manualmente l'associazione, IAM la eliminerà automaticamente. L'eliminazione di questa associazione contribuisce a garantire che gli amministratori di cymbalgroup.com abbiano accesso a tutti i criteri di Principal Access Boundary associati alle loro entità.

Interazioni tra policy

IAM valuta ogni policy di Principal Access Boundary in combinazione con le tue policy di autorizzazione e negazione e con le altre policy di Principal Access Boundary. Tutte queste policy vengono utilizzate per determinare se un'entità può accedere a una risorsa.

Interazione con altri tipi di norme

Quando un'entità tenta di accedere a una risorsa, IAM valuta tutte le policy di autorizzazione, negazione e Principal Access Boundary pertinenti per verificare se l'entità è autorizzata ad accedere alla risorsa. Se uno qualsiasi di questi criteri indica che l'entità non deve essere in grado di accedere alla risorsa, IAM impedisce l'accesso.

Di conseguenza, se una policy di Principal Access Boundary impedisce a un'entità di accedere a una risorsa, IAM le impedisce di accedere a quella risorsa, indipendentemente dai criteri di autorizzazione e negazione collegati alla risorsa.

Inoltre, le policy di Principal Access Boundary da sole non concedono alle entità l'accesso alle risorse. Sebbene le policy di Principal Access Boundary possano rendere un'entità idonea ad accedere a una risorsa, solo le policy di autorizzazione possono effettivamente concedere all'entità l'accesso alla risorsa.

Per saperne di più sulla valutazione delle policy IAM, consulta Valutazione delle policy.

Interazione tra le policy di Principal Access Boundary

Se una policy di Principal Access Boundary rende un'entità idonea ad accedere a una risorsa, l'entità è idonea ad accedere a quella risorsa, indipendentemente dalle altre policy di Principal Access Boundary a cui è soggetta. Di conseguenza, se un'entità è già soggetta a una policy di Principal Access Boundary, non puoi aggiungere policy di Principal Access Boundary per ridurre l'accesso di un'entità.

Ad esempio, supponiamo che un'entità, Dana (dana@example.com), sia soggetta a un'unica policy di Principal Access Boundary, prod-projects-policy. Questo criterio rende le entità idonee ad accedere alle risorse in prod-project. Dana è soggetta a questa policy perché è associata al set di entità della sua organizzazione.

Crea un nuovo criterio di Principal Access Boundary, dev-staging-projects-policy, che rende le entità idonee ad accedere alle risorse in dev-project e staging-project, quindi lo associa al set di entità dell'organizzazione.

In seguito a queste policy di Principal Access Boundary, Dana può accedere alle risorse in dev-project, staging-project e prod-project.

Se vuoi ridurre le risorse a cui Dana può accedere, devi modificare o rimuovere i criteri di Principal Access Boundary a cui è soggetta Dana.

Ad esempio, puoi modificare dev-staging-projects-policy in modo che non renda i principal idonei ad accedere alle risorse in dev-project. In questo caso, Dana potrà accedere solo alle risorse in staging-project e prod-project.

In alternativa, puoi rimuovere prod-projects-policy eliminando l'associazione di criteri che lo associa al set di entità dell'organizzazione. In questo modo, Dana potrà accedere solo alle risorse in dev-project e staging-project.

Tuttavia, queste modifiche non riguardano solo Dana, ma anche le altre entità soggette ai binding e alle policy di Principal Access Boundary modificate. Se vuoi ridurre le risorse a cui una singola entità può accedere, utilizza i binding dei criteri condizionali.

Ereditarietà delle norme

Le policy di Principal Access Boundary sono associate a insiemi di entità, non a risorse Resource Manager. Di conseguenza, non vengono ereditati tramite la gerarchia delle risorse nello stesso modo in cui vengono ereditati i criteri di autorizzazione e negazione.

Tuttavia, i set di entità per le risorse padre di Resource Manager, ovvero cartelle e organizzazioni, includono sempre tutte le entità nei set di entità dei relativi discendenti. Ad esempio, se un'entità è inclusa nel set di entità di un progetto, è inclusa anche nei set di entità di eventuali cartelle o organizzazioni padre.

Ad esempio, considera un'organizzazione, example.com. Questa organizzazione è associata al dominio example.com e dispone delle seguenti risorse Resource Manager:

• Un'organizzazione, example.com
• Un progetto, project-1, figlio dell'organizzazione
• Una cartella, folder-a, che è una cartella secondaria dell'organizzazione
• Due progetti, project-2 e project-3, che sono figli di folder-a

I set di entità principali di queste risorse contengono le seguenti identità:

Di conseguenza, le seguenti entità sono interessate dalle seguenti policy di Principal Access Boundary:

• Un'identità Google Workspace nel dominio example.com si trova nell'insieme di entità per example.com e sarà interessata dai criteri di confine dell'accesso dell'entità associati a quell'insieme di entità.

• Un account di servizio in project-1 si trova negli insiemi di entità per project-1 e example.com e sarà interessato dai criteri di confine dell'accesso dell'entità associati a uno di questi insiemi di entità.

• Un account di servizio in project-3 si trova negli insiemi di entità per project-3, folder-a e example.com e sarà interessato dai criteri di confine dell'accesso dell'entità associati a uno qualsiasi di questi insiemi di entità.

Policy di Principal Access Boundary e risorse memorizzate nella cache

Alcuni Google Cloud servizi memorizzano nella cache le risorse visibili pubblicamente. Ad esempio, Cloud Storage memorizza nella cache gli oggetti leggibili pubblicamente.

La possibilità che il limite di accesso dell'entità impedisca alle entità non idonee di visualizzare una risorsa visibile pubblicamente dipende dalla memorizzazione nella cache della risorsa:

• Se la risorsa è memorizzata nella cache, il limite di accesso all'entità non può impedire alle entità di visualizzare la risorsa
• Se la risorsa non è memorizzata nella cache, il limite di accesso all'entità impedisce alle entità non idonee di visualizzare la risorsa

In tutti i casi, le policy di Principal Access Boundary impediscono alle entità non idonee di modificare o eliminare risorse visibili pubblicamente.

Struttura di una policy di Principal Access Boundary

Un criterio di Principal Access Boundary è una raccolta di metadati e dettagli del criterio di Principal Access Boundary. I metadati forniscono informazioni come il nome della norma e la data di creazione. I dettagli dei criteri definiscono cosa fanno i criteri, ad esempio le risorse a cui le entità interessate possono accedere.

Ad esempio, la seguente policy di Principal Access Boundary rende le entità soggette alla policy idonee ad accedere alle risorse nell'organizzazione con l'ID 0123456789012.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Le sezioni seguenti descrivono i campi nei metadati e nei dettagli di un criterio di Principal Access Boundary.

Metadati

Le policy di Principal Access Boundary contengono i seguenti metadati:

• name: il nome della policy di Principal Access Boundary. Questo nome ha il formato organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, dove ORGANIZATION_ID è l'ID numerico dell'organizzazione in cui è stata creata la policy di Principal Access Boundary e PAB_POLICY_ID è l'ID alfanumerico della policy di Principal Access Boundary.
• uid: un ID univoco assegnato alla policy di Principal Access Boundary.
• etag: un identificatore per lo stato attuale della norma. Questo valore cambia quando aggiorni il criterio. Per evitare aggiornamenti in conflitto, il valore di etag deve corrispondere al valore memorizzato in IAM. Se i valori etag non corrispondono, la richiesta non riesce.
• displayName: un nome leggibile per la policy dei limiti di accesso all'entità.
• annotations: (Facoltativo). Un elenco di coppie chiave-valore definite dall'utente. Puoi utilizzare queste annotazioni per aggiungere metadati aggiuntivi alla norma, ad esempio chi l'ha creata o se è stata implementata da una pipeline automatica. Per ulteriori informazioni sulle annotazioni, consulta la sezione Annotazioni.
• createTime: l'ora in cui è stata creata la policy di Principal Access Boundary.
• updateTime: l'ora in cui la policy di Principal Access Boundary è stata aggiornata l'ultima volta.

Dettagli

Ogni policy di Principal Access Boundary contiene un campo details. Questo campo contiene le regole di Principal Access Boundary e la versione di applicazione:

• rules: un elenco di regole di Principal Access Boundary, che definiscono le risorse a cui le entità interessate possono accedere. Ogni regola contiene i seguenti campi:

  • description: una descrizione leggibile della regola.

  • resources: un elenco di risorse Resource Manager (progetti, cartelle e organizzazioni) a cui vuoi che le entità possano accedere. Qualsiasi entità soggetta a queste norme è idonea ad accedere a queste risorse.

    Ogni policy di Principal Access Boundary può fare riferimento a un massimo di 500 risorse in tutte le regole della policy.

  • effect: La relazione che le entità hanno con le risorse elencate nel campo resources. L'unico effetto che puoi specificare nelle regole Principal Access Boundary è "ALLOW". Questa relazione rende le entità idonee ad accedere alle risorse elencate nella regola.

• enforcementVersion: la versione di applicazione utilizzata da IAM quando applica il criterio. La versione del criterio di Principal Access Boundary determina quali autorizzazioni può bloccare il criterio di Principal Access Boundary.

  Per saperne di più sulle versioni delle policy di Principal Access Boundary, consulta la sezione Versioni dell'applicazione di Principal Access Boundary in questa pagina.

Struttura di un'associazione di policy

Un'associazione di policy per una policy di Principal Access Boundary contiene il nome di una policy, il nome dell'insieme di entità a cui associare la policy e i metadati che descrivono l'associazione di policy. Può anche contenere condizioni che modificano i principal esatti a cui si applica la policy.

Ad esempio, il seguente binding della policy associa la policy example-policy a tutte le entità nell'organizzazione example.com, che ha l'ID 0123456789012. L'associazione di criteri contiene anche una condizione che impedisce l'applicazione dei criteri per l'entità super-admin@example.com.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for super-admin@example.com",
    "expression": "principal.subject != 'super-admin@example.com'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

Ogni binding di policy contiene i seguenti campi:

• name: il nome dell'associazione di policy. Questo nome ha il formato RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, dove RESOURCE_TYPE/RESOURCE_ID è il tipo e l'ID della risorsa padre del binding dei criteri e BINDING_ID è l'ID alfanumerico del binding dei criteri.
• uid: un ID univoco assegnato all'associazione di policy.
• etag: un identificatore per lo stato attuale della norma. Questo valore cambia quando aggiorni il criterio. Per evitare aggiornamenti in conflitto, il valore di etag deve corrispondere al valore memorizzato in IAM. Se i valori etag non corrispondono, la richiesta non riesce.
• displayName: Un nome leggibile per l'associazione delle policy.
• annotations: (Facoltativo). Un elenco di coppie chiave-valore definite dall'utente. Puoi utilizzare queste annotazioni per aggiungere metadati aggiuntivi al binding della norma, ad esempio chi ha creato il binding della norma o se è stato implementato da una pipeline automatizzata. Per ulteriori informazioni sulle annotazioni, consulta la sezione Annotazioni.

• target: il set di entità a cui associare la policy. Il valore ha il formato {"principalSet": PRINCIPAL_SET}, dove PRINCIPAL_SET è l'ID del set di entità a cui vuoi associare il criterio.

  Ogni target può avere fino a 10 criteri associati.

• policyKind: Il tipo di policy a cui fa riferimento l'associazione di policy. Per le associazioni di policy per le policy di Principal Access Boundary, questo valore è sempre PRINCIPAL_ACCESS_BOUNDARY.

• policy: la policy di Principal Access Boundary da associare al set di entità di destinazione.

• policyUid: un ID univoco assegnato alla policy di Principal Access Boundary a cui viene fatto riferimento nel campo policy.

• condition: (Facoltativo). Un'espressione logica che influisce sulle entità per le quali IAM applica il criterio. Se la condizione restituisce il valore true o non può essere valutata, Identity and Access Management applica il criterio all'entità che effettua la richiesta. Se la condizione restituisce il valore false, Identity and Access Management non applica il criterio per l'entità. Per ulteriori informazioni, consulta la sezione Limiti e condizioni di Principal Access Boundary in questa pagina.

• createTime: l'ora in cui è stata creata l'associazione di policy.

• updateTime: l'ora dell'ultimo aggiornamento dell'associazione di criteri.

Casi d'uso

Di seguito sono riportate situazioni comuni in cui potresti voler utilizzare le policy di Principal Access Boundary ed esempi di policy di Principal Access Boundary e associazioni di policy che potresti creare in ogni situazione. Per scoprire come creare policy di Principal Access Boundary e associarle a insiemi di entità, consulta Creare e applicare policy di Principal Access Boundary.

Rendere le entità idonee ad accedere alle risorse della tua organizzazione

Puoi utilizzare una policy di Principal Access Boundary per rendere le entità della tua organizzazione idonee ad accedere alle risorse all'interno dell'organizzazione. Se questo è l'unico criterio di Principal Access Boundary a cui sono soggette le entità della tua organizzazione, il criterio di Principal Access Boundary renderà le entità della tua organizzazione non idonee ad accedere alle risorse al di fuori della tua organizzazione.

Ad esempio, supponiamo che tu voglia rendere tutti i principal dell'organizzazione example.com idonei ad accedere alle risorse all'interno di example.com e non idonei ad accedere alle risorse in altre organizzazioni. Le entità in example.com includono tutte le identità nel dominio example.com, tutti i pool di identità della forza lavoro in example.com e tutti i service account e i pool di identità del workload in qualsiasi progetto in example.com.

Non hai criteri di Principal Access Boundary che si applicano a nessuna delle entità della tua organizzazione. Di conseguenza, tutte le entità sono idonee ad accedere a tutte le risorse.

Per rendere le entità idonee ad accedere alle risorse in example.com e non idonee ad accedere alle risorse al di fuori di example.com, crea una policy di confine dell'accesso dell'entità che rende le entità idonee ad accedere alle risorse in example.com:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Poi, crea un'associazione di policy per associare questa policy al set di entità dell'organizzazione:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

Se associato al set di entità dell'organizzazione, questo criterio rende tutte le entità in example.com idonee ad accedere alle risorse in example.com. Poiché questa è l'unica policy di Principal Access Boundary a cui sono soggette queste entità, la policy rende anche le entità in example.com non idonee ad accedere alle risorse al di fuori della tua organizzazione. Ciò significa che non possono utilizzare le autorizzazioni bloccate dal criterio di Principal Access Boundary per accedere alle risorse al di fuori di example.com, anche se dispongono di queste autorizzazioni per queste risorse.

Rendere idonei i service account alle risorse in un singolo progetto

Puoi creare una policy di Principal Access Boundary per rendere idonei gli account di servizio in un progetto specifico ad accedere alle risorse all'interno di quel progetto.

Se questo è l'unico criterio del limite di accesso dell'entità a cui sono soggetti i service account, questi ultimi saranno idonei ad accedere solo alle risorse all'interno di quel progetto.

Ad esempio, supponiamo che tu abbia un progetto, example-dev, con il numero di progetto 901234567890. Vuoi assicurarti che i service account in example-dev siano idonei solo per accedere alle risorse in example-dev.

Hai una policy di Principal Access Boundary che rende tutte le entità della tua organizzazione, inclusi i service account in example-dev, idonee ad accedere alle risorse in example.com. Per vedere l'aspetto di questo tipo di criterio, consulta Rendere le entità idonee all'accesso alle risorse nella tua organizzazione.

Per impedire ai service account in example-dev di accedere alle risorse al di fuori di example-dev, devi prima creare una policy di Principal Access Boundary che renda le entità idonee ad accedere alle risorse in example-dev

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Poi, crea un'associazione di policy per associare questa policy a tutte le entità in example-dev e aggiungi una condizione in modo che l'associazione di policy si applichi solo agli account di servizio:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

Tuttavia, questo criterio da solo non modifica le risorse a cui gli account di servizio possono accedere. Ciò è dovuto al fatto che esiste una policy di Principal Access Boundary che rende tutte le entità in example.com idonee ad accedere a tutte le risorse in example.com. Le policy di Principal Access Boundary sono additive, quindi i service account in example-dev sono ancora idonei ad accedere a tutte le risorse in example.com.

Per assicurarti che gli account di servizio in example-dev siano idonei solo ad accedere alle risorse in example-dev, devi aggiungere una condizione al binding dei criteri per i criteri di Principal Access Boundary esistenti che ne impedisca l'applicazione agli account di servizio, inclusi gli account di servizio predefiniti, in example-dev:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com') || !principal.subject == 'example-dev@appspot.gserviceaccount.com || !principal.subject == '901234567890-compute@developer.gserviceaccount.com'"
  }
}

Ora, i service account in example-dev sono idonei solo per accedere alle risorse in example-dev. Non possono utilizzare le autorizzazioni bloccate dal criterio di Principal Access Boundary per accedere alle risorse al di fuori di example-dev, anche se dispongono di queste autorizzazioni per queste risorse.

In un secondo momento, se vuoi aumentare le risorse a cui questi service account possono accedere, puoi aggiungere risorse aggiuntive al criterio example-dev-only o creare un criterio di limite di accesso principale aggiuntivo e associarlo ai service account.

Passaggi successivi

• Scopri come creare e applicare le policy di Principal Access Boundary.
• Esamina l'autorizzazione bloccata da ogni versione di applicazione delle norme di Principal Access Boundary.