Approccio ai test per la landing zone di Azure

Alcune organizzazioni potrebbero voler testare la distribuzione, tramite l'acceleratore della landing zone della piattaforma, di definizioni e assegnazioni di Criteri di Azure, di ruoli personalizzati RBAC e delle relative assegnazioni, e così via. I test possono essere completati tramite l'automazione usando modelli di Azure Resource Manager (modelli arm), Terraform, Bicepo manualmente tramite il portale di Azure. Queste linee guida forniscono un approccio che può essere usato per testare le modifiche e il relativo impatto sulla distribuzione dell'acceleratore di zona di destinazione della piattaforma.

Questo articolo può essere usato anche con le linee guida di automazione della piattaforma e area di progettazione critica di DevOps poiché è correlato alle attività e ai team delle funzioni centrali e PlatformOps. Inoltre, può essere combinato con le indicazioni in Adottare barriere di controllo basate su criteri su come implementare le modifiche ai criteri in una distribuzione della landing zone della piattaforma.

Queste linee guida sono più adatte alle organizzazioni con processi di gestione delle modifiche affidabili che regolano le modifiche alla gerarchia dei gruppi di gestione di produzione. La gerarchia dei gruppi di gestione canary può essere usata in modo indipendente per creare e testare le distribuzioni prima di distribuirle nell'ambiente di produzione.

Definizione della piattaforma

Azure linee guida per la zona di destinazione consente di progettare e distribuire i componenti della piattaforma Azure necessari per consentire di costruire e rendere operative le zone di destinazione su larga scala.

Le risorse della piattaforma comprese nell'ambito di questo articolo e di questo approccio di test sono:

Scenari di esempio e risultati

Un esempio di questo scenario è un'organizzazione che vuole testare l'impatto e il risultato di nuovi Criteri di Azure per eseguire la governance delle risorse e delle impostazioni in tutte le zone di destinazione, in base al principio di progettazione della governance basata su criteri. L’organizzazione non vuole apportare questa modifica direttamente all'ambiente di produzione perché è preoccupata per l'impatto che potrebbe avere.

Usare l'ambiente canary per testare questa modifica della piattaforma consentirà all'organizzazione di implementare e valutare l'impatto e i risultati della modifica di Criteri di Azure. Questo processo garantisce che vengano soddisfatti i requisiti dell'organizzazione prima di implementare Criteri di Azure nell'ambiente di produzione.

Uno scenario simile potrebbe essere una modifica delle assegnazioni dei ruoli di Azure RBAC e delle appartenenze ai gruppi di Microsoft Entra. Potrebbe essere necessaria una forma di test prima che le modifiche vengano apportate nell'ambiente di produzione.

Figura 1: Gerarchia dei gruppi di gestione Canary.

Come mostra il diagramma, l'intera gerarchia del gruppo di gestione di produzione della landing zone di Azure è duplicata sotto Tenant Root Group. Il nome canary viene aggiunto ai nomi visualizzati e agli ID dei gruppi di gestione. Gli ID del gruppo di gestione devono essere univoci all'interno di un singolo tenant Microsoft Entra. Nel tenant, gli ID dei gruppi di gestione sono considerati gli identificatori di riferimento, pertanto devono essere univoci all’interno del tenant. È possibile mantenere i nomi visualizzati del gruppo di gestione allineati alla gerarchia del gruppo di gestione di produzione. Aggiungere anche un elemento distintivo nei nomi visualizzati, in modo che gli utenti possano distinguere visivamente la gerarchia canary dall'ambiente di produzione quando esplorano l'albero dei gruppi di gestione.

La gerarchia del gruppo di gestione canary viene quindi usata per semplificare il test dei tipi di risorse seguenti:

• Gruppi di gestione
  • Posizionamento dell'abbonamento
• RBAC
  • Ruoli (predefiniti e personalizzati)
  • Assegnazioni
• Criteri di Azure
  • Definizioni (predefinite e personalizzate)
  • Iniziative, note anche come definizioni di set
  • Assegnazioni

Cosa accade se non si vuole distribuire la gerarchia del gruppo di gestione canary?

Se non si vuole implementare la gerarchia del gruppo di gestione canary, è possibile testare le risorse della piattaforma all'interno della gerarchia dell'ambiente di produzione utilizzando sottoscrizioni sandbox, come illustrato nel diagramma.

Figura 2: gerarchia dei gruppi di gestione delle landing zone di Azure che evidenzia le sandbox.

Per testare Criteri di Azure e RBAC in questo scenario, è necessaria un'unica sottoscrizione di Azure con il ruolo RBAC Owner assegnato all'identità con cui si desidera eseguire il test, ad esempio account utente, entità servizio o identità del servizio gestito. Questa configurazione consente di creare, assegnare e correggere le definizioni e le assegnazioni di Criteri di Azure solo nell'ambito della sottoscrizione di sandbox.

Questo approccio in modalità sandbox può essere usato anche per testare RBAC all'interno della sottoscrizione, ad esempio se si sta sviluppando un nuovo ruolo RBAC personalizzato per assegnare le autorizzazioni per un caso d'uso specifico. Questo test può essere completamente eseguito nella sottoscrizione sandbox e testato prima di creare e assegnare ruoli più in alto nella gerarchia.

Un vantaggio di questo approccio è che le sottoscrizioni sandbox possono essere usate quando sono necessarie e quindi eliminate dall'ambiente.

Tuttavia, questo approccio non consente di eseguire test con l'ereditarietà di RBAC e dei criteri di Azure nella gerarchia dei gruppi di gestione.

Linee guida per l'implementazione

Di seguito sono riportate indicazioni su come implementare e utilizzare la gerarchia dei gruppi di gestione canary per una landing zone di Azure insieme alla gerarchia dei gruppi di gestione di una landing zone di Azure per un ambiente di produzione.

1. Utilizzare entità servizio Microsoft Entra (SPN) separate oppure identità gestite (MI) a cui sono state concesse autorizzazioni sulla gerarchia dei gruppi di gestione della landing zone di Azure dell'ambiente di produzione pertinente o dell'ambiente canary.
   • Queste indicazioni seguono il principio dei privilegi minimi (PoLP)
2. Utilizzare cartelle separate all'interno di un repository Git, branch o repository per ospitare l'IaC per le distribuzioni della landing zone di Azure degli ambienti di produzione e canary.
   • Uso delle entità servizio di Microsoft Entra (SPN) o delle identità gestite (MI) pertinenti nell’ambito delle pipeline CI/CD, in base alla gerarchia da distribuire.
3. Implementa i criteri dei branch Git o le misure di sicurezza nell'ambiente canary come già avviene per l'ambiente di produzione.
   • Prendere in considerazione la possibilità di ridurre il numero di responsabili dell’approvazione e di controlli per la risposta immediata agli errori dell'ambiente canary.
4. Usare le stesse azioni GitHub o Azure Pipelines che usano le variabili di ambiente per modificare la gerarchia da distribuire. Un'altra opzione è clonare le pipeline e modificare le impostazioni hard-coded per definire la gerarchia da distribuire.
   • L'uso di modelli DevOps di Azure Pipelines o modelli di flusso di lavoro di GitHub Actions consente di rispettare il principio Don't Repeat Yourself (DRY).
5. Disporre di un gruppo di sottoscrizioni canary in un account di fatturazione separato, ad esempio un account Enterprise Agreement (EA) o una sezione della fattura di Contratto del cliente Microsoft (MCA), che possano essere spostate all'interno della gerarchia del gruppo di gestione canary secondo necessità.
   • Potrebbe essere utile avere un set di risorse sempre distribuite nelle sottoscrizioni dell'ambiente canary per velocizzare i test e la convalida delle modifiche nell'ambiente canary.
6. Avere una serie di architetture di carichi di lavoro di esempio che è possibile distribuire nelle sottoscrizioni canary dell'ambiente canary per verificare le modifiche ad Criteri di Azure e a RBAC. Ciò consente di convalidare le modifiche prima di distribuire e promuovere le modifiche nell'ambiente di produzione.
   • Questi carichi di lavoro di esempio possono essere distribuiti usando gli stessi modelli IaC usati per distribuire i carichi di lavoro di produzione. Ciò consente di garantire che l'ambiente canary sia sincronizzato con l'ambiente di produzione e che le modifiche di cui si sta testando siano valide e applicabili all'ambiente di produzione.
   • È consigliabile esaminare e aggiornare continuamente i carichi di lavoro di esempio per assicurarsi che siano pertinenti e aggiornati con l'architettura e i modelli di progettazione più recenti dell'organizzazione.
   • Se fornite architetture di riferimento ai team responsabili dei carichi di lavoro, valutate anche la possibilità di distribuirle nell'ambiente canary. In questo modo è possibile convalidare le modifiche rispetto alle architetture di riferimento e assicurarsi che siano applicabili all'ambiente di produzione.
7. Inviare tutti i log delle attività di Azure per tutte le sottoscrizioni di Azure, incluse eventuali sottoscrizioni dell'ambiente canary, all'area di lavoro di Log Analytics di Azure dell'ambiente di produzione, in conformità alle raccomandazioni di progettazione della landing zone di Azure.
   • In questo modo, i team responsabili della sicurezza e delle operazioni possono monitorare l'ambiente canary per individuare eventuali modifiche o problemi che potrebbero derivare dal test delle modifiche di Criteri di Azure e di RBAC nell'ambiente di produzione.

Uso di un singolo tenant di Microsoft Entra

Le considerazioni da tenere in considerazione quando si usa un singolo tenant di Microsoft Entra sono:

• L'utilizzo di un singolo tenant segue le raccomandazioni di progettazione della landing zone di Azure per i tenant Microsoft Entra.
  • In un singolo tenant Microsoft Entra, è possibile usare i diversi gruppi Microsoft Entra sia per gli ambienti Azure landing zone di produzione che per quelli canary, con gli stessi utenti assegnati alla rispettiva gerarchia del management group.
• Aumento o duplicazione dei costi di licenza di Microsoft Entra ID a causa di identità multiple distribuite tra tenant Microsoft Entra diversi. Ciò è particolarmente rilevante per i clienti che usano le funzionalità P1 o P2 di Microsoft Entra ID.
• Le modifiche RBAC sono più complesse sia negli ambienti canary sia in quelli di produzione, poiché è probabile che utenti e gruppi non siano identici tra i due tenant di Microsoft Entra.
  • Si consideri che gli ID di utenti e gruppi non saranno gli stessi tra i tenant di Microsoft Entra, poiché sono univoci a livello globale.
• Riduce la complessità e il sovraccarico di gestione causati dalla gestione di più tenant di Microsoft Entra.
  • Gli utenti con privilegi che devono mantenere l'accesso e accedere a tenant separati per effettuare test potrebbero, ad esempio, apportare modifiche accidentali all'ambiente di produzione anziché all'ambiente canary.
• Riduce il rischio di drift della configurazione e di errori di distribuzione.
• Non richiede la creazione di procedure di sicurezza aggiuntive né di procedure break-glass o di accesso di emergenza.
• Riduce l'attrito e il tempo necessario per implementare le modifiche alla distribuzione della zona di destinazione Azure.

Passaggi successivi

Dopo aver creato un ambiente canary, è possibile iniziare a testare le modifiche di Criteri di Azure e del controllo degli accessi in base al ruolo (RBAC) prima di distribuirle nella gerarchia del gruppo di gestione della landing zone di Azure di produzione.

Dopo aver testato le modifiche ai Criteri di Azure nell'ambiente canary, è quindi possibile promuoverle nell'ambiente di produzione seguendo lo stesso approccio descritto nella guida Adottare guardrail basati su criteri. Questa operazione viene eseguita utilizzando la funzionalità della modalità di imposizione delle assegnazioni dei criteri. L'uso dell'approccio documentato in queste linee guida consente di procedere in una fase di test aggiuntiva prima di applicare Criteri di Azure nell'ambiente di produzione nel suo effetto desiderato, che consente di acquisire fiducia nelle modifiche apportate a Criteri di Azure.

È anche possibile valutare gli ambienti sandbox che i team responsabili dei carichi di lavoro possono utilizzare per lo sviluppo e il test dei propri carichi di lavoro. Si tratta di un concetto distinto dall'ambiente canary e viene utilizzato per fornire ai team responsabili dei carichi di lavoro un ambiente sicuro in cui sviluppare e testare i propri carichi di lavoro prima che vengano distribuiti nell'ambiente di produzione.