Il gate si basa sul criterio dell'organizzazione

Cloud Build consente di definire un criterio dell'organizzazione (constraints/cloudbuild.allowedIntegrations) per controllare quali servizi esterni possono richiamare i trigger di build. Ad esempio, se il trigger rimane in ascolto delle modifiche a un repository GitHub e GitHub è negato nel criterio dell'organizzazione, il trigger non verrà eseguito. Puoi specificare un numero qualsiasi di valori consentiti o rifiutati 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

  • Abilita le API Cloud Build and Organization Policy.

    Abilita le API

  • Per utilizzare gli esempi di riga di comando riportati in questa guida, installa e configura Google Cloud SDK.

  • Per impostare, modificare o eliminare un criterio dell'organizzazione, devi avere il ruolo Amministratore criteri organizzazione (roles/orgpolicy.policyAdmin). Per scoprire come aggiungere il ruolo al tuo account, vedi Aggiungere un amministratore dei criteri 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).

    Verrà visualizzata la pagina Dettagli norme.

  3. Per modificare la norma, fai clic su Modifica.

    Verrà visualizzata la pagina Modifica criterio.

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

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

  6. Nella sezione Regole, fai clic su Aggiungi regola per aggiungere una nuova regola per il criterio.

  7. In Valori criterio, seleziona Consenti tutto per consentire le build da tutti i servizi, seleziona Rifiuta tutto per negare le build da tutti i servizi oppure seleziona Personalizzato per consentire o negare 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 host dell'istanza o del 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. Ad esempio, github.com ghe.staging-test.com.

      In base all'evento, l'URL host specificato è uno dei seguenti:

      • Evento RepoSync: l'organizzatore è source.developers.google.com.
      • Evento app GitHub: l'host viene derivato dal campo repository.html_url nel payload JSON, che è sempre github.com.
      • Evento GitHub Enterprise: l'host viene derivato dal campo repository.html_url nel payload JSON. Ad esempio, ghe.staging-test.com.
      • Evento Pub/Sub: l'host viene derivato dall'origine specificata nel trigger. Se nel trigger non è specificata alcuna origine, non viene eseguito il controllo dei criteri dell'organizzazione.
      • Evento webhook: l'host viene derivato dall'origine specificata nel trigger. Se nel trigger non è specificata alcuna origine, è previsto 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 la norma, 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 il seguente contenuto:

    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 vengano ereditate dalla risorsa padre. Altrimenti, false.
    • ALLOW_OR_DENY è allowAll se vuoi consentire le build da tutti gli URL host. Altrimenti, denyAll.
    • HOST_URL è l'URL del tuo 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 con il seguente contenuto:

    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 vengano ereditate dalla risorsa padre. Altrimenti, false.
    • ALLOW_OR_DENY è allowedValues se vuoi specificare 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 questo comando, dove FILE_NAME è il nome del tuo file YAML:

     gcloud org-policies set-policy FILE_NAME

  4. Per confermare che il criterio è stato impostato, esegui il comando seguente, dove PROJECT_ID è l'ID progetto:

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

Test del criterio dell'organizzazione per le integrazioni consentite

Questa sezione spiega come testare il criterio dell'organizzazione (constraints/cloudbuild.allowedIntegrations) utilizzando i trigger di build.

  1. Se non lo hai già fatto, crea un trigger di build.

  2. Esegui il push di una modifica alla tua origine.

  3. Se il criterio è impostato in modo da consentire le build dall'origine, potrai visualizzare le esecuzioni delle build dal trigger nella pagina Cronologia build. In caso contrario, la tua build non verrà eseguita. Per visualizzare la cronologia delle build limitate dalla definizione del tuo criterio, consulta la pagina Esplora log per conoscere il motivo del payload JSON e il motivo del rifiuto.

Passaggi successivi