Supporto delle cartelle nei perimetri di servizio

La funzionalità di appartenenza basata su cartelle nei Controlli di servizio VPC consente di definire perimetri di servizio con le cartelle Google Cloud come membri. Aiutandoti a proteggere un'intera gerarchia di cartelle con una singola configurazione del perimetro, questa funzionalità riduce il sovraccarico amministrativo della gestione del perimetro su larga scala.

Questo documento spiega come funziona il supporto delle cartelle nei perimetri e tratta i seguenti argomenti:

  • Concetti, comportamenti e vantaggi principali dell'utilizzo delle cartelle nei perimetri.

  • Interazioni tra l'appartenenza basata su cartelle, le risorse nidificate e le regole della gerarchia delle risorse, come l'ereditarietà e la precedenza di valutazione.

  • Come cercare i perimetri configurati per progetti e cartelle.

  • Best practice e limitazioni note per l'utilizzo di questa funzionalità.

Informazioni sull'appartenenza alle cartelle nei perimetri

Una Google Cloud cartella può contenere più progetti, altre cartelle o una combinazione di entrambi. Sebbene tu possa aggiungere singoli progetti all'interno di una cartella a un perimetro di servizio, ti consigliamo di aggiungere invece la cartella principale. Quando specifichi una cartella come risorsa protetta durante la creazione di un perimetro, i Controlli di servizio VPC includono tutte le risorse all'interno di quella cartella, come progetti e cartelle nidificate.

Quando aggiungi progetti a una cartella che hai configurato in un perimetro, i Controlli di servizio VPC aggiungono automaticamente questi progetti allo stesso perimetro. Non è necessario aggiornare la configurazione del perimetro per includere questi progetti. Allo stesso modo, quando rimuovi progetti dalla cartella, i Controlli di servizio VPC li rimuovono automaticamente dal perimetro.

Cartelle nidificate ed ereditarietà

I Controlli di servizio VPC limitano tutte le risorse all'interno di una cartella che hai configurato in un perimetro, ad esempio le cartelle nidificate e le relative risorse. Quando aggiungi una cartella a un perimetro, i Controlli di servizio VPC limitano automaticamente tutti i progetti in quella cartella e nelle relative sottocartelle.

Precedenza della valutazione dell'appartenenza alle risorse

Una risorsa Google Cloud può essere protetta da un solo perimetro di servizio regolare in modalità di applicazione forzata e da uno in modalità dry run. Se una risorsa o le relative cartelle principali sono associate a più perimetri, l'associazione di livello più basso nella gerarchia delle risorse determina il perimetro effettivo.

I Controlli di servizio VPC valutano la precedenza in modo indipendente per la modalità di applicazione forzata e la modalità dry run:

  • Precedenza della modalità di applicazione forzata: il perimetro in modalità di applicazione forzata effettivo è determinato dalla risorsa più bassa nella gerarchia (il progetto stesso o la cartella predecessore più vicina) che è assegnata esplicitamente a un perimetro in modalità di applicazione forzata.
  • Precedenza della modalità dry run: il perimetro in modalità di prova effettivo è determinato dalla risorsa più bassa della gerarchia assegnata esplicitamente a un perimetro in modalità di prova o ereditata implicitamente da una risorsa applicata assegnata esplicitamente.

La configurazione di un perimetro in modalità di prova per un progetto o una sottocartella non disabilita né esegue l'override di un perimetro in modalità di applicazione forzata configurato in una cartella predecessore.

Esempi di precedenza

  • Esempio 1 (override diretto del progetto in modalità di applicazione forzata): se configuri una cartella principale (folders/1) in un perimetro in modalità di applicazione forzata (sp1) e configuri esplicitamente un progetto all'interno di questa cartella (projects/1) in un perimetro in modalità di applicazione forzata diverso (sp2), projects/1 è protetto da sp2. L'assegnazione diretta del progetto ha la precedenza sull'ereditarietà delle cartelle. Tutti gli altri progetti in folders/1 (ad esempio projects/2) rimangono protetti da sp1 tramite l'ereditarietà delle cartelle.

  • Esempio 2 (ereditarietà delle cartelle in modalità dry run): quando configuri una cartella (folders/1) in un perimetro di servizio in modalità dry run, tutti i progetti all'interno di quella cartella (projects/1 e projects/2) ereditano la configurazione del perimetro dry run (sp1) a meno che non sia esplicitamente disabilitata. L'ereditarietà dry run si comporta in modo identico all'ereditarietà della modalità di applicazione forzata, a meno che una risorsa nidificata non sia configurata in modo esplicito con un perimetro in modalità di prova diverso.

  • Esempio 3 (valutazione indipendente dei perimetri applicati in modo forzato e dry run): i Controlli di servizio VPC valutano le associazioni applicate in modo forzato e dry run in modo indipendente. Se configuri una cartella principale (folders/1) in un perimetro in modalità di applicazione forzata (sp1) e assegni esplicitamente un progetto all'interno di questa cartella (projects/1) a un perimetro in modalità di prova (sp2), projects/1 rimane protetto da sp1 in modalità di applicazione forzata e viene valutato contemporaneamente in modalità dry run da sp2. L'assegnazione di un progetto a un perimetro in modalità di prova non esegue l'override o la disattivazione del perimetro in modalità di applicazione forzata della cartella principale.

  • Esempio 4 (gerarchia di cartelle multilivello e precedenza delle sottocartelle): in una gerarchia di cartelle multilivello, i Controlli di servizio VPC valutano la precedenza a ogni livello della gerarchia. Se una cartella principale (folders/2) è configurata in un perimetro in modalità di applicazione forzata (sp1), tutti i progetti contenuti (projects/1 e projects/2) ereditano l'applicazione di sp1. Quando i perimetri in modalità dry run vengono assegnati a livelli diversi, ad esempio assegnando il predecessore folders/2 al perimetro in modalità di prova sp2 e il progetto projects/2 (nella sottocartella folders/1) al perimetro in modalità di prova sp1, ogni progetto eredita la configurazione dry run dal suo predecessore più vicino. Di conseguenza, projects/1 viene valutato nel test dry run sp2, mentre projects/2 viene valutato nel test dry run sp1.

Cercare i perimetri configurati effettivi

Poiché le risorse possono ereditare la protezione del perimetro dalle cartelle predecessore, puoi utilizzare il metodo LookupConfiguredServicePerimeter per identificare quali perimetri di servizio proteggono un progetto o una cartella.

L'API restituisce quanto segue:

  • servicePerimeter: il nome completo del perimetro effettivo applicato.
  • servicePerimeterDryRun: il nome completo del perimetro di simulazione effettivo.
  • restrictedResource: La risorsa specifica (progetto o cartella) a cui è collegato direttamente il perimetro in modalità di applicazione forzata.
  • restrictedResourceDryRun: La risorsa specifica a cui è direttamente collegato il perimetro di prova.

Per saperne di più, consulta Cercare i perimetri configurati.

Esclusione di progetti dai perimetri

Per escludere un progetto da un perimetro a livello di cartella, assegna esplicitamente il progetto a un perimetro separato che non limita alcun servizio e consente tutto il traffico in entrata e in uscita. Poiché le configurazioni esplicite del progetto hanno la precedenza sui perimetri a livello di cartella, il progetto viene escluso dal perimetro della cartella.

Per informazioni sull'aggiornamento dei perimetri, consulta Aggiorna un perimetro di servizio.

Policy con ambito

I perimetri di servizio all'interno di una policy con ambito limitano solo le risorse che esistono nell'ambito di quella policy. Affinché una cartella venga inclusa come membro in un perimetro con ambito, la policy di accesso deve essere definita per la cartella o per un predecessore della cartella (ad esempio una cartella principale o l'organizzazione).

Best practice

Esamina le seguenti best practice per la gestione dei perimetri basati su cartelle.

Migrazione sicura dei progetti ai perimetri delle cartelle

Quando esegui la transizione dalle appartenenze esplicite ai progetti alle appartenenze basate su cartelle, segui questi passaggi per evitare interruzioni involontarie dell'applicazione del perimetro:

  1. Aggiungi la cartella padre di destinazione al perimetro di servizio.
  2. Sposta i progetti nella cartella principale nella gerarchia delle risorse.
  3. Attendi almeno 48 ore: conserva le voci di progetto esplicite nella configurazione del perimetro per almeno 48 ore. Questo periodo di attesa consente il completamento della propagazione della gerarchia delle risorse in tutti i sistemi.
  4. Rimuovi le configurazioni di progetto esplicite dal perimetro. I progetti rimangono protetti tramite l'ereditarietà delle cartelle.

Spostamenti nella gerarchia

Lo spostamento di cartelle o progetti modifica la protezione perimetrale effettiva. Per evitare negazioni di accesso impreviste, coordina tutti gli spostamenti della gerarchia con l'amministratore di Resource Manager.

Se sposti i progetti che hai configurato in un perimetro in un'altra cartella e aggiungi questa cartella allo stesso perimetro, devi conservare le configurazioni di appartenenza esplicita al progetto esistenti nel perimetro per almeno 48 ore. Questo periodo di attesa consente la propagazione della gerarchia delle risorse ed evita problemi imprevisti di applicazione del perimetro quando rimuovi le configurazioni esplicite del progetto dal perimetro.

Limitazioni

  • L'appartenenza basata su cartelle non è supportata nei bridge del perimetro. I bridge del perimetro accettano solo le risorse del progetto.

  • Controlli di servizio VPC non supporta le risorse API a livello di cartella.

  • A causa di un problema noto, la configurazione di un progetto di rete VPC come risorsa protetta in un perimetro in modalità di prova di prova esecuzione forzata basata su cartelle. Se un progetto di rete viene aggiunto esplicitamente a un perimetro di dry run, perde la protezione perimetro in modalità di applicazione forzata ereditata dalle cartelle padre.

  • L'appartenenza alle cartelle non è supportata per le API nonGoogle Cloud e per i perimetri configurati con allowed_service_patterns. Per consentire l'accesso a questi pattern di servizio, i progetti o le reti VPC di origine devono essere aggiunti esplicitamente al perimetro, anziché ereditati tramite una cartella.

Passaggi successivi