Introduzione

Completato

Quando si distribuisce l'infrastruttura come codice, è possibile automatizzare le distribuzioni, migliorare la fiducia nelle distribuzioni e aumentare l'efficienza del lavoro del team. Tuttavia, questi vantaggi si applicano solo se l'utente e il team sono diligenti ed evitano di apportare modifiche manuali all'ambiente.

In questo modulo viene illustrato come applicare la configurazione e la governance all'ambiente e alle pipeline di Azure, in modo da evitare modifiche impreviste o non controllate.

Nota

Il termine GitHub Actions per una pipeline è flusso di lavoro. Per semplicità, in questo modulo si userà pipeline per fare riferimento sia alle pipeline in Azure Pipelines che ai flussi di lavoro in GitHub Actions.

Scenario di esempio

Si supponga di lavorare come amministratore di Azure per un'azienda di giocattoli. Negli ultimi mesi, l'utente e il team hanno convertito le distribuzioni di Azure per l'uso di Bicep. I processi di distribuzione sono stati automatizzati tramite pipeline. Tuttavia, alcuni membri del team non hanno ancora acquisito l'abitudine di distribuire tutte le modifiche come codice.

Di recente, si sono verificati diversi casi in cui le distribuzioni in Azure sono state effettuate usando processi diversi:

  1. Qualcuno ha apportato una modifica diretta alla configurazione di un sito Web usando il portale di Azure.
  2. Qualcuno ha distribuito un nuovo file Bicep direttamente dal proprio computer.
  3. Qualcuno ha copiato le credenziali dell'entità servizio di una pipeline e le ha usate per accedere all'ambiente di produzione tramite l'interfaccia della riga di comando di Azure.
  4. Qualcuno ha eseguito il commit di una modifica al file Bicep direttamente al ramo principale del repository, bypassando le revisioni delle richieste pull.
  5. Qualcuno ha aggiornato un file Bicep usando una richiesta pull. Le modifiche sono state convalidate, testate e distribuite nella sequenza di ambienti corretta.

Nel diagramma che segue vengono illustrati tali scenari:

Diagramma che mostra numerosi approcci per apportare modifiche alla configurazione di Azure.

Di tutte queste modifiche, solo la numero 5 è stata distribuita tramite gli strumenti di automazione adottati e seguendo il processo concordato dal team. Anche se nessuna delle altre modifiche ha causato alcun danno, non è il caso di sfidare la fortuna. Il team ha deciso di applicare il processo in modo da ottenere il massimo vantaggio dal proprio investimento nell'automazione. Si è convenuto con il team di consentire la distribuzione nell'ambiente Azure soltanto mediante il processo approvato:

Diagramma che mostra diversi approcci per apportare modifiche alla configurazione di Azure, tutti bloccati ad eccezione del processo approvato.

Cosa si dovrà fare?

In questo modulo viene illustrato come applicare la distribuzione dell'infrastruttura di Azure come codice. Vengono presi in considerazione i controlli che è necessario applicare a ogni ambiente e vengono applicati criteri di governance e sicurezza per proteggere le risorse di Azure. Si apprenderà anche come proteggere le pipeline e i repository assicurandosi che tutti gli aspetti della configurazione di Azure seguano un processo consigliato e con protezione avanzata.

Suggerimento

Questo modulo presenta molte funzionalità di sicurezza. L'unità di riepilogo contiene collegamenti ad altre informazioni su ogni funzionalità.

Qual è l'obiettivo principale?

Alla fine di questo modulo si sarà in grado di identificare i controlli di sicurezza e la governance da applicare all'ambiente, ai repository e alle pipeline di Azure, in modo da poter distribuire tutta l'infrastruttura come codice.

Prerequisiti

È necessario avere familiarità con l'uso di:

  • Infrastruttura come codice e relativi vantaggi e tecnologie come Bicep o Terraform.
  • Azure, tra cui il portale di Azure, le sottoscrizioni, i gruppi di risorse e le risorse.
  • Git per gestire il codice, inclusi rami e richieste pull.
  • Distribuzioni automatizzate tramite GitHub Actions o Azure Pipelines.