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 esfiltrazione di dati.

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

Come funzionano le policy di Principal Access Boundary

Per impostazione predefinita, le entità possono 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 una policy 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 Principal Access Boundary possono bloccare alcune autorizzazioni IAM (Identity and Access Management), ma non tutte. Per scoprire di più su quali autorizzazioni sono 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 il seguente scenario:

• Il preside Tal ([e-mail]) fa parte dell'organizzazione Google Workspace example.com.
• A Tal viene concesso il ruolo Amministratore spazio di archiviazione (roles/storage.admin) su 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 policy 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 i criteri 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 stabilisce che le entità example.com sono idonee ad accedere solo alle risorse in example.com. Poi, possono creare un'associazione di policy per collegare questa policy 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 di 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 IAM (Identity and Access Management) per accedere alla risorsa.

Se una policy di Principal Access Boundary blocca un'autorizzazione, IAM applica le policy di Principal Access Boundary per questa autorizzazione. In altre parole, impedisce a qualsiasi entità non idonea ad accedere a una risorsa di utilizzare questa autorizzazione per accedere alla risorsa.

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

Ad esempio, supponiamo che a un'entità, Lee ([e-mail]), 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 di applicazione di 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 le tue policy del confine 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 quando crei il criterio. Tuttavia, sconsigliamo di utilizzare questo valore perché potrebbe causare la perdita imprevista dell'accesso alle risorse da parte dei principal.

Nota: possono essere necessarie fino a 4 settimane prima che una nuova versione diventi la versione di applicazione predefinita. La versione di applicazione predefinita viene utilizzata per le nuove policy che non specificano un numero di versione e per le policy che utilizzano il valore latest.

Per un elenco completo delle autorizzazioni bloccate da ogni versione di applicazione, consulta la sezione 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 insieme di entità, crea un'associazione policy che specifica sia la policy di Principal Access Boundary che vuoi applicare sia l'insieme di entità a cui vuoi applicarla. Dopo aver associato il criterio a un insieme di entità, le entità in quell'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 questa 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:

• 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 i binding dei criteri per quel tipo di set di entità

Set di entità	Dettagli	Risorsa padre dei binding delle policy
Pool di identità della forza lavoro	Contiene tutte le identità nel pool di identità della forza lavoro specificato. Formato: //iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID	L'organizzazione che contiene il pool di identità della forza lavoro
Pool di identità del workload	Contiene tutte le identità nel pool di identità del workload specificato. Formato: //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID	Il progetto che contiene il pool di identità del workload
Dominio Google Workspace	Contiene tutte le identità nel dominio Google Workspace specificato. Formato: //iam.googleapis.com/locations/global/workspace/CUSTOMER_ID Puoi trovare il tuo ID cliente utilizzando i seguenti metodi: Utilizza il comando gcloud organizations describe. L'ID workspace si trova nel campo directoryCustomerId della risposta. Utilizza il metodo organizations.get nell'API Cloud Resource Manager. L'ID workspace si trova nel campo directoryCustomerId della risposta. Visualizza il tuo ID cliente nella Console di amministrazione. Questo metodo richiede il ruolo di super amministratore Google Workspace.	L'organizzazione associata al dominio Google Workspace
Set di entità del progetto	Contiene tutti i service account e i pool di identità del workload nel progetto specificato. Formato: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID	Il progetto
Set di entità della cartella	Contiene tutti i service account e tutti i pool di identità del workload in qualsiasi progetto nella cartella specificata. Formato: //cloudresourcemanager.googleapis.com/folders/FOLDER_ID	La cartella
Set di entità dell'organizzazione	Contiene le seguenti identità: Tutte le identità in tutti i domini associati al tuo ID cliente Google Workspace Tutti i pool di identità della forza lavoro nella tua organizzazione Tutti i service account e i pool di identità del workload in qualsiasi progetto dell'organizzazione Formato: //cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID	L'organizzazione

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 binding 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 agli account di servizio:

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

• L'attributo principal.subject indica l'identità del principal nella richiesta, ad esempio [e-mail]. 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 [e-mail]:

  principal.subject != '[e-mail]'
  

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 di avere un account di servizio, dev-project-service-account, con l'indirizzo email [e-mail]. Questo account di servizio è soggetto a una policy 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 non vuoi che dev-project-service-account possa 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 all'associazione di policy anziché eliminarla:

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 all'insieme di entità per dev-project. Utilizzi 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 == '[e-mail]'"
   }
   

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 != '[e-mail]' || 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. Al contrario, è idoneo ad accedere solo alle risorse in dev-project.

Associazioni di policy tra organizzazioni

Non puoi creare un'associazione di policy cross-organization per una policy di confine dell'accesso dell'entità. Un'associazione di policy tra organizzazioni è un'associazione di policy che associa una policy 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 all'insieme 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 insieme 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 Principal Access Boundary, di autorizzazione e di negazione 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 dalle policy di autorizzazione e negazione associate 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 scoprire 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 ([e-mail]), sia soggetta a un'unica policy di Principal Access Boundary, prod-projects-policy. Questa policy rende le entità idonee ad accedere alle risorse in prod-project. Dana è soggetta a questo criterio perché è associato al set di entità della sua organizzazione.

Crea una nuova policy di Principal Access Boundary, dev-staging-projects-policy, che consente alle entità di accedere alle risorse in dev-project e staging-project, quindi la 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 le policy di Principal Access Boundary a cui è soggetta.

Ad esempio, puoi modificare dev-staging-projects-policy in modo che non renda le entità idonee ad accedere alle risorse in dev-project. In questo caso, Dana potrebbe 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 caso, Dana potrà accedere solo alle risorse in dev-project e staging-project.

Importante: se rimuovi una policy di Principal Access Boundary per ridurre l'accesso di un'entità, assicurati che l'entità sia sempre soggetta ad almeno una policy di Principal Access Boundary. Se un'entità non è soggetta ad alcuna policy di Principal Access Boundary, è idonea ad accedere a tutte le risorse Google Cloud . Per scoprire come ridurre in modo sicuro l'accesso di un'entità, vedi Ridurre le risorse a cui le entità possono accedere.

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

Ereditarietà delle policy

Le policy di Principal Access Boundary sono associate a insiemi di entità, non a risorse Resource Manager. Di conseguenza, non vengono ereditate tramite la gerarchia delle risorse nello stesso modo in cui vengono ereditate le policy 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 ha le 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, figli di folder-a

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

Set di entità	Identità Google Workspace nel dominio example.com	Pool di federazione delle identità per la forza lavoro in example.com	Service account e pool di identità del workload in project-1	Service account e pool di identità del workload in project-2	Service account e pool di identità del workload in project-3
Capitale impostato per example.com
Capitale impostato per folder-a
Capitale impostato per project-1
Capitale impostato per project-2
Capitale impostato per project-3

Di conseguenza, le seguenti entità sono interessate dalle seguenti policy 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 visualizzarla

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 policy 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 dell'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 una policy 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 va a buon fine.
• 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 policy, ad esempio chi ha creato la policy o se è stata implementata da una pipeline automatica. Per saperne di più sulle annotazioni, consulta Annotazioni.
• createTime: l'ora in cui è stata creata la policy di Principal Access Boundary.
• updateTime: l'ora in cui è stata aggiornata l'ultima volta la policy di Principal Access Boundary.

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 della regola leggibile da una persona.

  • 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 i principal hanno con le risorse elencate nel campo resources. L'unico effetto che puoi specificare nelle regole del Principal Access Boundary è "ALLOW". Questa relazione rende le entità idonee ad accedere alle risorse elencate nella regola.

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

  Per ulteriori informazioni sulle versioni delle policy di Principal Access Boundary, consulta 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 applicano le norme.

Ad esempio, la seguente associazione di 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à [e-mail].

{
  "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 [e-mail]",
    "expression": "principal.subject != '[e-mail]'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

Ogni binding delle policy contiene i seguenti campi:

• name: Il nome del binding della 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 va a buon fine.
• displayName: un nome leggibile per l'associazione della policy.
• annotations: (Facoltativo) Un elenco di coppie chiave-valore definite dall'utente. Puoi utilizzare queste annotazioni per aggiungere metadati aggiuntivi all'associazione di policy, ad esempio chi ha creato l'associazione di policy o se è stata implementata da una pipeline automatizzata. Per saperne di più sulle annotazioni, consulta 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 il binding della 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 all'insieme 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 all'entità. Per ulteriori informazioni, consulta Principal Access Boundary e condizioni in questa pagina.

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

• updateTime: l'ora in cui l'associazione della policy è stata aggiornata l'ultima volta.

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 della tua organizzazione. Se questo è l'unico criterio di Principal Access Boundary a cui sono soggette le entità della tua organizzazione, allora 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 di 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 Principal Access Boundary che renda 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"
  }
}

Quindi, 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 service account di 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 potranno accedere solo alle risorse all'interno di quel progetto.

Ad esempio, supponiamo di avere un progetto, example-dev, con il numero di progetto 901234567890. Vuoi assicurarti che i service account in example-dev siano idonei ad accedere solo 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 policy, consulta Rendere le entità idonee all'accesso alle risorse della 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 crei 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 gli service account in example-dev sono ancora idonei ad accedere a tutte le risorse in example.com.

Per assicurarti che i service account 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 ai service account, inclusi i service account 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 == '[e-mail] || !principal.subject == '[e-mail]'"
  }
}

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 Principal Access Boundary aggiuntivo e associarlo ai service account.

Passaggi successivi

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