Il gate si basa sul criterio dell'organizzazione

Cloud Build ti consente di definire un criterio dell'organizzazione (constraints/cloudbuild.allowedIntegrations) per controllare quali servizi esterni possono richiamare trigger di build. Ad esempio: se il trigger rimane in ascolto di modifiche a un repository GitHub e a GitHub è negata nel criterio dell'organizzazione, il trigger non verrà eseguito. Puoi specificare un numero qualsiasi di valori consentiti o vietati per la tua organizzazione o il tuo progetto.

Questa pagina spiega come configurare il criterio dell'organizzazione (constraints/cloudbuild.allowedIntegrations) per le integrazioni utilizzando la console Google Cloud e lo strumento a riga di comando gcloud.

Prima di iniziare

  • Enable the Cloud Build and Organization Policy APIs.

    Enable the APIs

  • Per utilizzare gli esempi a riga di comando in questa guida, installa configurare Google Cloud SDK.

  • Per impostare, modificare o eliminare un criterio dell'organizzazione, devi disporre del Ruolo Amministratore criteri dell'organizzazione (roles/orgpolicy.policyAdmin). Per sapere come aggiungere il ruolo al tuo account, consulta Aggiungere un amministratore delle norme dell'organizzazione.

Configurazione del criterio dell'organizzazione per le integrazioni consentite

Questa sezione spiega come configurare il criterio dell'organizzazione (constraints/cloudbuild.allowedIntegrations) per definire le build per le integrazioni consentite.

Console

  1. Apri la pagina Criteri dell'organizzazione nella console Google Cloud.

    Apri la pagina Criteri dell'organizzazione

  2. Fai clic sulla riga contenente il criterio Integrazioni consentite (Cloud Build).

    Viene visualizzata la pagina Dettagli norme.

  3. Per modificare il criterio, fai clic su Modifica.

    Verrà visualizzata la pagina Modifica criterio.

  4. Nella sezione Applicabile a, seleziona Personalizza per impostare la definizione del criterio.

  5. Nella sezione Applicazione dei criteri, seleziona Sostituisci per definire le tue regole. In caso contrario, seleziona Unisci con il padre per assicurarti che le regole della risorsa principale vengano applicate alle tue impostazioni. Per scoprire di più, consulta Informazioni sulla valutazione della gerarchia.

  6. Nella sezione Regole, fai clic su Aggiungi regola per aggiungere una nuova regola per le tue norme.

  7. In Valori criterio, seleziona Consenti tutto per consentire le build da tutti i servizi, Rifiuta tutto per rifiutare le build da tutti i servizi oppure Personalizzato per consentire o rifiutare le build da servizi specifici.

    Se selezioni Personalizzato come valore, completa i seguenti passaggi:

    1. Nella sezione Tipo di criterio, seleziona Consenti o Rifiuta.

    2. Nella sezione Valori personalizzati, inserisci l'URL dell'host dell'istanza o il repository da cui vuoi consentire o negare le build. Ad esempio, per consentire o negare le build da GitHub, inserisci l'URL come github.com o www.github.com.

      Puoi anche inserire più URL separati da uno spazio. Per ad esempio github.com ghe.staging-test.com.

      A seconda dell'evento, l'URL dell'host specificato è uno dei seguenti:

      • Evento RepoSync: l'host è source.developers.google.com.
      • Evento dell'app GitHub: l'host è ricavato dal campo repository.html_url nel payload JSON, che è sempre github.com.
      • Evento GitHub Enterprise: l'host è dedotto dal campo repository.html_url nel payload JSON. Ad esempio, ghe.staging-test.com.
      • Evento Pub/Sub: l'host viene derivato dall'origine specificato nel trigger. Se non è specificata alcuna origine nell'attivatore, non viene eseguito alcun controllo dei criteri dell'organizzazione.
      • Evento webhook: l'host è dedotto dall'origine specificata nell'attivatore. Se non è specificata alcuna fonte nell'attivatore, viene eseguito il controllo dei criteri dell'organizzazione.

  8. Per salvare la regola, fai clic su Fine.

  9. Per aggiungere un'altra regola, fai clic su Aggiungi regola. In caso contrario, per salvare il criterio, fai clic su Salva.

gcloud

  1. Apri una finestra del terminale.

  2. Se vuoi consentire o negare le build da tutti i servizi, crea un file YAML con i seguenti contenuti:

    name: projects/PROJECT_NUMBER/policies/cloudbuild.allowedIntegrations
spec:
  inheritFromParent: INHERIT
  rules:
    - ALLOW_OR_DENY: true

    Dove:

    • PROJECT_NUMBER è il numero del tuo progetto.
    • INHERIT è true se vuoi che le regole dei criteri ereditati dalla risorsa padre. In caso contrario, false.
    • Se vuoi, ALLOW_OR_DENY è allowAll per consentire le build da tutti gli URL host. Altrimenti, denyAll.
    • HOST_URL è l'URL dell'host. Ad esempio, github.com. Puoi anche specificare altri URL nelle righe seguenti.

    Se vuoi consentire o negare le build dai servizi selezionati, crea un file YAML file con i seguenti contenuti:

    name: projects/PROJECT_NUMBER/policies/cloudbuild.allowedIntegrations
spec:
  inheritFromParent: INHERIT
  rules:
    - values:
        ALLOW_OR_DENY:
          HOST_URL
          ...

    Dove:

    • PROJECT_NUMBER è il numero del tuo progetto.
    • INHERIT è true se vuoi che le regole dei criteri ereditati dalla risorsa padre. Altrimenti, false.
    • ALLOW_OR_DENY è allowedValues se vuoi specificare gli URL host da cui consentire le build. Altrimenti, deniedValues.
    • HOST_URL è l'URL del tuo host. Ad esempio: github.com. Puoi anche specificare altri URL nelle righe seguenti.

  3. Imposta il criterio dell'organizzazione eseguendo il comando seguente, doveFILE_NAME è il nome del file YAML:

     gcloud org-policies set-policy FILE_NAME

  4. Per confermare che il criterio è stato configurato, esegui questo comando: dove PROJECT_ID è il tuo ID progetto:

     gcloud org-policies describe cloudbuild.allowedIntegrations --effective --project PROJECT_ID

Test del criterio dell'organizzazione per verificare le integrazioni consentite

Questa sezione spiega come testare i criteri dell'organizzazione (constraints/cloudbuild.allowedIntegrations) utilizzando gli attivatori di compilazione.

  1. Se non l'hai ancora fatto, crea un trigger di build.

  2. Esegui il push di una modifica al codice sorgente.

  3. Se il criterio è configurato in modo da consentire le build dall'origine, in grado di visualizzare le esecuzioni della build dal trigger nella pagina Cronologia build. In caso contrario, la build non verrà eseguita. Per visualizzare la cronologia delle build limitate dalla definizione delle norme, consulta la pagina Logs Explorer per il motivo del payload JSON e il motivo del rifiuto.

Passaggi successivi