Aumentare i limiti della policy di conservazione

In Google Distributed Cloud (GDC) air-gapped esiste un vincolo che impedisce agli utenti di superare un criterio di conservazione massimo impostato GDCHRestrictAttributeRange. Questo vincolo viene applicato alle risorse personalizzate (CR) del bucket nei cluster di amministrazione dell'organizzazione da Policy Controller di Anthos Config Management. Ciò significa che solo gli account di servizio di sistema, gli utenti di sistema e gli utenti all'interno del gruppo system:masters possono rimuovere i finalizer per impostazione predefinita. La procedura descritta illustra come aumentare i limiti della policy di conservazione per le CR dei bucket.

Prerequisiti

Genera il file KUBECONFIG per il cluster

Per funzionare, i comandi kubectl richiedono un file KUBECONFIG valido. Questa procedura fornisce istruzioni passo passo per generare il file KUBECONFIG per i cluster di amministrazione root, amministrazione dell'organizzazione, sistema dell'organizzazione e utente.

Prerequisiti

Prima di continuare, assicurati di avere quanto segue:

  • gdcloud è installato.

  • L'interfaccia a riga di comando kubectl è installata.

  • Un certificato firmato da un'autorità di certificazione (CA) installata sulla workstation.

  • Il nome dell'organizzazione.

  • L'URL di base (GDC). L'amministratore IT dell'organizzazione cliente deve fornirti l'URL principale.

Imposta le variabili di ambiente richieste

Segui le istruzioni in questa sezione per generare il file KUBECONFIG per org-admin, system o qualsiasi cluster utente.

  1. Esegui questo comando per definire la variabile di ambiente ORG per un utilizzo successivo nel terminale corrente. ORG è il nome della tua organizzazione.

    export ORG=

  2. Esegui questo comando per definire la variabile di ambiente CONSOLE_URL per un utilizzo successivo nel terminale corrente:

    export CONSOLE_URL=https://console.${ORG:?}.$GDC_URL/
gdcloud config set core/organization_console_url ${CONSOLE_URL:?}

    Sostituisci GDC_URL con l'URL di base del tuo progetto GDC.

Accedi al cluster

  1. Esegui questo comando per accedere:

    gdcloud auth login --no-browser

  2. Copia il comando gcloud stampato ed eseguilo su una macchina con accesso al browser.

  3. Copia l'URL stampato e incollalo nella barra degli indirizzi di un browser web.

  4. Segui le istruzioni riportate nella pagina web per completare la procedura di accesso.

  5. Una volta completato l'accesso, il browser visualizza il messaggio Autenticazione riuscita. Chiudi questa finestra.

  6. Segui le istruzioni sul terminale. Se l'accesso viene eseguito correttamente, nel terminale viene visualizzato il messaggio You are now logged in.

Generare il file KUBECONFIG

  1. Esegui questo comando per definire la variabile di ambiente CLUSTER per un utilizzo successivo nel terminale corrente. CLUSTER è il nome del cluster che vuoi.

    export CLUSTER=

    Fai riferimento alla tabella seguente per derivare il nome del cluster sostituendo ORGANIZATION-NAME e CLUSTER-NAME con i valori appropriati:

    Cluster Nome del cluster
    amministratore root root-admin
    amministratore dell'organizzazione ORGANIZATION-NAME-admin
    sistema dell'organizzazione ORGANIZATION-NAME-system
    utente CLUSTER-NAME

    Vedrai che ciascuno dei nomi rappresenta quanto segue:

    • Il nome del cluster di amministrazione principale è root-admin.
    • I nomi del cluster di sistema dell'amministratore dell'organizzazione e dell'organizzazione per un'organizzazione denominata amira sono rispettivamente amira-admin e amira-system.
    • I nomi dei cluster utente sono i nomi dei cluster.

  2. Esegui questo comando per generare il file KUBECONFIG e convalidare le credenziali: sh export KUBECONFIG=${HOME}/${CLUSTER:?}-kubeconfig.yaml rm ${KUBECONFIG:?} gdcloud clusters get-credentials ${CLUSTER:?} [[ $(kubectl config current-context) == *${CLUSTER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure" Il comando dovrebbe restituire questo output:

    Success. Your kubeconfig is at /usr/local/google/home/iris/kubeconfig-amira-admin.yaml

Ottenere il ruolo di amministratore dei criteri nel cluster

Questa procedura ti consente di ottenere l'accesso temporaneo con privilegi elevati a un cluster.

Prerequisiti

Prima di continuare, assicurati di avere quanto segue:

  • Un altro IO che funga da approvatore delle richieste GitLab. L'IO deve disporre delle autorizzazioni per approvare una richiesta GitLab.
  • Il nome del cluster a cui devi accedere. Ad esempio: root-admin, org-1-admin.
  • Il tipo di ruolo che vuoi assumere. Ad esempio: Role ClusterRole, ProjectRole o OrganizationRole.
  • Il ruolo che vuoi assumere.
  • Lo spazio dei nomi dell'accesso richiesto. Non necessario per ClusterRole e OrganizationRole.
  • Accesso a una workstation IT dell'OC.
  • Credenziali per GitLab.

Esegui elevated-access-script

  1. Dalla directory private-cloud/operations/tools/ sulla workstation, esegui lo script elevated-access-script.sh.

  2. Rispondi alla domanda "Inserisci l'URL GDCH del cluster..." con $GDCH_URL.

  3. Rispondi alla domanda "Inserisci il nome utente Gitlab:" con il nome utente che utilizzi per accedere a Gitlab.

  4. Per la domanda "Inserisci il token di accesso personale di Gitlab:", inserisci il token di accesso personale del tuo account. Per creare un token di accesso personale:

    1. Vai a https://gitlab.$GDCH_URL/gdch/iac. Accedi al tuo account IO Gitlab.

    2. Seleziona il tuo avatar.

    3. Seleziona Modifica profilo.

    4. Nel menu di navigazione, seleziona Token di accesso.

    5. Inserisci un nome e una data di scadenza per il token.

    6. Seleziona gli ambiti che ti interessano.

    7. Seleziona Crea token di accesso personale.

  5. Lo script clonerà ora il repository iac nella tua directory locale.

  6. Rispondi alla domanda "Inserisci il prefisso del tuo IdP". IdP Prefix è un prefisso specifico per ogni Identity Provider che viene anteposto a ogni nome utente all'interno di un cluster GDC. Questo prefisso può essere trovato:

    • consultare il tuo Watch Commander
    • recuperando le istruzioni dalla configurazione di GDC, in particolare dalla sezione "Identity and access management" della Guida per l'utente di Operators.

    La forma abituale di questo prefisso è un insieme di parole seguito da un delimitatore, ad esempio gdch-infra-operator-.

  7. Rispondi alla domanda "Inserisci il tuo nome utente" con il nome utente che utilizzi per accedere al tuo Identity Provider.

  8. Rispondi alla domanda "Enter the cluster you need the role for" (Inserisci il cluster per cui ti serve il ruolo) con il nome del cluster per cui ti serve il ruolo.

  9. Lo script ti chiederà di scegliere un tipo di ruolo Kubernetes. Digita il tipo di ruolo che stai richiedendo.

  10. Rispondi alla domanda "Inserisci il ruolo che devi assumere" con il nome del ruolo.

  11. Inserisci la durata dell'accesso al ruolo. La durata dell'accesso consigliata è di 3 ore.

  12. Lo script genererà tre file YAML.

    1. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/kustomization.yaml
    2. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/kustomization.yaml
    3. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/${ROLE}-binding.yaml

    Verifica che ogni file sia corretto premendo Y o premi N per modificare il file in vim.

  13. Dopo aver confermato tutti i file, lo script li invierà a un ramo elevated_access in GitLab e creerà una richiesta di unione.

Esaminare e approvare la richiesta di accesso con privilegi

Il seguente elenco specifica le azioni intraprese per una richiesta di accesso con privilegi elevati di revisione e approvazione:

  1. Un altro IO esamina la richiesta GitLab, inclusi i file di configurazione delle norme, per approvarla in modo appropriato.
  2. Una volta che l'IO approva la richiesta, il sistema concede l'accesso per il periodo di tempo richiesto.
  3. Il sistema revoca l'accesso dopo il periodo di scadenza impostato.

Vincolo patch

Dopo aver ottenuto l'accesso richiesto, esegui il seguente comando per impostare il nuovo valore massimo della norma di conservazione del bucket. Questo esempio mostra un nuovo massimo di 120 giorni, ma assicurati di aggiornare il comando al valore richiesto dall'amministratore della piattaforma:

kubectl patch GDCHRestrictAttributeRange restrict-bucket-retention-policy -p '{"spec":{"parameters":{"attributeMaxValue":120}}}' --type=merge

L'output dovrebbe essere simile al seguente:

gdchrestrictattributerange.constraints.gatekeeper.sh/restrict-bucket-retention-policy patched