Condividi tramite

Distribuzione sicura delle assegnazioni di Criteri di Azure

  • Articolo

Man mano che l'ambiente si espande, aumenta anche la richiesta di una pipeline di distribuzione continua (CD) controllata con controllo progressivo dell'esposizione. Di conseguenza, Microsoft consiglia ai team DevOps di seguire il framework SDP (Safe Deployment Practices). La distribuzione sicura delle definizioni e delle assegnazioni di Criteri di Azure consente di limitare l'impatto dei comportamenti imprevisti delle risorse dei criteri.

L'approccio generale all'implementazione di SDP con Criteri di Azure consiste nell'implementare gradualmente le assegnazioni di criteri tramite anelli per rilevare le modifiche ai criteri che influiscono sull'ambiente nelle fasi iniziali prima che influiscano sull'infrastruttura cloud critica.

Gli anelli di distribuzione possono essere organizzati in modi diversi. In questa esercitazione sulle procedure, gli anelli sono divisi per aree di Azure diverse con Anello 0 che rappresenta le posizioni non critiche e a traffico basso e Anello 5 che indica le posizioni più critiche e a traffico elevato.

Passaggi per la distribuzione sicura delle assegnazioni di Criteri di Azure con effetti di negazione o aggiunta

Usare il diagramma di flusso seguente come riferimento durante l'applicazione del framework SDP alle assegnazioni di Criteri di Azure che usano gli effetti dei criteri di deny o append.

Nota

Per altre informazioni sugli effetti dei criteri di Azure, vedere Informazioni sul funzionamento degli effetti.

Diagramma di flusso con i passaggi da uno a otto che mostrano le procedure di distribuzione sicura per la distribuzione di una nuova definizione di Criteri di Azure.

Numeri dei passaggi del diagramma di flusso:

  1. Dopo aver selezionato la definizione dei criteri, assegnare i criteri all'ambito di livello più alto comprensivo di tutti gli anelli di distribuzione. Applicare i selettori di risorse per restringere l'applicabilità all'anello meno critico usando la proprietà "kind": "resource location". Configurare il tipo di effetto audit usando gli override delle assegnazioni. Selettore di esempio con posizione eastUS ed effetto come audit:

    "resourceSelectors": [{
  "name": "SDPRegions",
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ]
  }]
}],
"overrides":[{
  "kind": "policyEffect",
  "value": "Audit"
}]

  2. Dopo aver distribuito l'assegnazione e aver completato l'analisi iniziale della conformità, verificare che il risultato della conformità sia quello previsto.

    È anche consigliabile configurare test automatizzati che eseguono controlli di conformità. Un controllo di conformità deve includere la logica seguente:

    • Raccogliere i risultati di conformità
    • Se i risultati della conformità sono come previsto, la pipeline deve continuare
    • Se i risultati della conformità non sono come previsto, la pipeline deve avere esito negativo ed è necessario avviare il debug

    Ad esempio, è possibile configurare il controllo di conformità usando altri strumenti all'interno della pipeline di integrazione continua/distribuzione continua (CI/CD).

    In ogni fase di implementazione, i controlli di integrità dell'applicazione devono confermare la stabilità del servizio e l'impatto dei criteri. Se i risultati non sono come previsto a causa della configurazione dell'applicazione, effettuare il refactoring dell'applicazione in modo appropriato.

  3. Ripetere espandendo i valori delle proprietà del selettore di risorse per includere gli anelli successivi, le posizioni e convalidando i risultati di conformità previsti e l'integrità dell'applicazione. Selettore di esempio con un valore di posizione aggiunto:

    "resourceSelectors": [{
  "name": "SDPRegions",
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS", "westUS"]
  }]
}]

  4. Dopo aver assegnato correttamente il criterio a tutti gli anelli usando la modalità audit, la pipeline deve attivare un'attività che modifica l'effetto dei criteri per deny e reimpostare i selettori di risorse nella posizione associata all'Anello 0. Selettore di esempio con un'area e un effetto impostato su Nega:

    "resourceSelectors": [{
  "name": "SDPRegions",
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ]
  }]
}],
"overrides":[{
  "kind": "policyEffect",
  "value": "Deny"
}]

  5. Una volta modificato l'effetto, i test automatizzati devono verificare se l'imposizione avviene come previsto.

  6. Ripetere includendo più anelli nella configurazione del selettore di risorse.

  7. Ripetere questo processo per tutti gli anelli di produzione.

Passaggi per la distribuzione sicura delle assegnazioni di Criteri di Azure con effetti di modifica o deployIfNotExists

I passaggi per i criteri che usano gli effetti modify o deployIfNotExists sono simili ai passaggi illustrati in precedenza con l'azione aggiuntiva di usare la modalità di imposizione e attivare un'attività di correzione. Esaminare il diagramma di flusso seguente con i passaggi modificati da 5 a 9:

Diagramma di flusso che mostra i passaggi da 5 a 9 nel flusso di lavoro delle procedure di distribuzione sicura di Criteri di Azure.

Numeri dei passaggi del diagramma di flusso:

  1. Dopo aver selezionato la definizione dei criteri, assegnare i criteri all'ambito di livello più alto comprensivo di tutti gli anelli di distribuzione. Applicare i selettori di risorse per restringere l'applicabilità all'anello meno critico usando la proprietà "kind": "resource location". Configurare la modalità di imposizione dell'assegnazione su DoNotEnforce. Selettore di esempio con posizione eastUS e enforcementMode come DoNotEnforce:

    "resourceSelectors": [{
  "name": "SDPRegions",
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ]
  }]
}],
"enforcementMode": "DoNotEnforce"

  2. Dopo aver distribuito l'assegnazione e aver completato l'analisi iniziale della conformità, verificare che il risultato della conformità sia quello previsto.

    È anche consigliabile configurare test automatizzati che eseguono controlli di conformità. Un controllo di conformità deve includere la logica seguente:

    • Raccogliere i risultati di conformità
    • Se i risultati della conformità sono come previsto, la pipeline deve continuare
    • Se i risultati della conformità non sono come previsto, la pipeline deve avere esito negativo ed è necessario avviare il debug

    È possibile configurare il controllo di conformità usando altri strumenti all'interno della pipeline di integrazione continua/distribuzione continua (CI/CD).

    In ogni fase di implementazione, i controlli di integrità dell'applicazione devono confermare la stabilità del servizio e l'impatto dei criteri. Se i risultati non sono come previsto a causa della configurazione dell'applicazione, effettuare il refactoring dell'applicazione in modo appropriato.

    È anche possibile attivare attività di correzione per correggere le risorse esistenti non conformi. Assicurarsi che le attività di correzione consentano di garantire la conformità delle risorse come previsto.

  3. Ripetere espandendo i valori delle proprietà del selettore di risorse per includere le posizioni dell'anello successivo e convalidando i risultati di conformità previsti e l'integrità dell'applicazione. Selettore di esempio con un valore di posizione aggiunto:

    "resourceSelectors": [{
  "name": "SDPRegions",
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS", "westUS"]
  }]
}]

  4. Dopo aver assegnato correttamente il criterio a tutti gli anelli usando la modalità DoNotEnforce, la pipeline deve attivare un'attività che modifica il criterio enforcementMode nell'abilitazione Predefinita e reimpostare i selettori di risorse nella posizione associata all'Anello 0. Selettore di esempio con un'area e un effetto impostato su Nega:

    "resourceSelectors": [{
  "name": "SDPRegions",
  "selectors": [{
      "kind": "resourceLocation",
      "in": [ "eastUS" ]
  }]
}],
"enforcementMode": "Default",

  5. Una volta modificato l'effetto, i test automatizzati devono verificare se l'imposizione avviene come previsto.

  6. Ripetere includendo più anelli nella configurazione del selettore di risorse.

  7. Ripetere questo processo per tutti gli anelli di produzione.

Passaggi per aggiornare in modo sicuro la versione di definizione predefinita nell'assegnazione di Criteri di Azure

  1. All'interno dell'assegnazione esistente, applicare gli override per aggiornare la versione della definizione per l'anello meno critico. Viene usata una combinazione di override per modificare definitionVersion e selettori all'interno della condizione overrides per restringere l'applicabilità in base alla proprietà "kind": "resource location". Tutte le risorse esterne alle posizioni specificate continueranno a essere valutate rispetto alla versione della proprietà di primo livello definitionVersion nell'assegnazione. Esempio di override che aggiorna la versione della definizione a 2.0.* e la applica solo alle risorse in EastUs.

    "overrides":[{
  "kind": "definitionVersion",
  "value": "2.0.*",
  "selectors": [{
    "kind": "resourceLocation",
    "in": [ "eastus"]
  }]
}]

  2. Dopo aver aggiornato l'assegnazione e aver completato l'analisi iniziale della conformità, verificare che il risultato della conformità sia quello previsto.

    È anche consigliabile configurare test automatizzati che eseguono controlli di conformità. Un controllo di conformità deve includere la logica seguente:

    • Raccogliere i risultati di conformità
    • Se i risultati della conformità sono come previsto, la pipeline deve continuare
    • Se i risultati della conformità non sono come previsto, la pipeline deve avere esito negativo ed è necessario avviare il debug

    Ad esempio, è possibile configurare il controllo di conformità usando altri strumenti all'interno della pipeline di integrazione continua/distribuzione continua (CI/CD).

    In ogni fase di implementazione, i controlli di integrità dell'applicazione devono confermare la stabilità del servizio e l'impatto dei criteri. Se i risultati non sono come previsto a causa della configurazione dell'applicazione, effettuare il refactoring dell'applicazione in modo appropriato.

  3. Ripetere espandendo i valori delle proprietà del selettore di risorse per includere gli anelli successivi, le posizioni e convalidando i risultati di conformità previsti e l'integrità dell'applicazione. Esempio con un valore di posizione aggiunto:

     "overrides":[{
  "kind": "definitionVersion",
  "value": "2.0",
  "selectors": [{
    "kind": "resourceLocation",
    "in": [ "eastus", "westus"]
  }]
}]

  4. Dopo aver incluso correttamente tutte le posizioni necessarie all'interno di _selectors, è possibile rimuovere l'override e aggiornare la proprietà definitionVersion all'interno dell'assegnazione:

"properties": {
        "displayName": "Enforce resource naming rules",
        "description": "Force resource names to begin with DeptA and end with -LC",
        "definitionVersion": "2.0.*",
}

Passaggi successivi