Prevenzione di deviazioni dalla configurazione

Config Sync riduce il rischio di "shadow ops" grazie alla riparazione automatica automatica, alla risincronizzazione periodica e alla prevenzione facoltativa della deviazione. Quando Config Sync rileva una deviazione tra il cluster e la fonte attendibile, può essere consentito e rapidamente ripristinato o rifiutato completamente.

La riparazione automatica controlla le risorse gestite, rileva la deviazione dalla fonte attendibile e ripristina la deviazione. La riparazione automatica è sempre attiva.

La nuova sincronizzazione periodica si sincronizza automaticamente un'ora dopo l'ultima sincronizzazione riuscita, anche se non sono state apportate modifiche alla fonte attendibile. La nuova sincronizzazione periodica è sempre attiva.

Mentre la riparazione automatica e le risincronizzazioni periodiche aiutano a rimediare alla deviazione, la prevenzione della deviazione intercetta le richieste di modifica degli oggetti gestiti e convalida se la modifica deve essere consentita. Se la modifica non corrisponde alla fonte attendibile, viene rifiutata. La prevenzione della deviazione è disattivata per impostazione predefinita. Se abilitata, la prevenzione della deviazione protegge gli oggetti RootSync per impostazione predefinita e può anche essere configurata per proteggere gli oggetti RepoSync.

Per utilizzare la prevenzione delle deviazioni, devi abilitare le API RootSync e RepoSync.

Attiva prevenzione della deviazione

  1. Imposta il campo preventDrift nel file di configurazione su true e applica il file di configurazione:

    gcloud

    Abilita la prevenzione delle deviazioni utilizzando gcloud CLI se hai installato Config Sync utilizzando la console Google Cloud o gcloud CLI. Assicurati di aggiornare gcloud CLI alla versione più recente. Imposta il campo spec.configSync.preventDrift del file gcloud config su true, quindi applica il file di configurazione gcloud.

    kubectl

    Attiva la prevenzione della deviazione utilizzando kubectl se hai installato manualmente Config Sync utilizzando kubectl. Imposta il campo spec.preventDrift dell'oggetto ConfigManagement su true, quindi applica l'oggetto ConfigManagement.

  2. Attendi fino a quando l'oggetto Config Sync ValidateWebhookConfiguration non viene creato dall'operatore ConfigManagement:

    kubectl get validatingwebhookconfiguration admission-webhook.configsync.gke.io

    Dovresti vedere un output simile all'esempio seguente:

    NAME                                  WEBHOOKS   AGE
admission-webhook.configsync.gke.io   0          2m15s

  3. Esegui il commit di una nuova modifica all'origine dati da sincronizzare in modo che il deployment root-reconciler possa aggiungere webhook all'oggetto Config Sync ConvalidaatingWebhookConfiguration. In alternativa, elimina il deployment root-reconcilier per attivare una riconciliazione. Il nuovo deployment root-reconciler aggiornerebbe l'oggetto Config Sync ValidatingWebhookConfiguration.

  4. Attendi che il server webhook sia pronto. Il log del deployment del webhook di ammissione di Config Sync deve includere serving webhook server. Questa operazione può richiedere diversi minuti.

    kubectl logs -n config-management-system -l app=admission-webhook --tail=-1 | grep "serving webhook server"

    Dovresti vedere un output simile all'esempio seguente:

    I1201 18:05:41.805531       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250
I1201 18:07:04.626199       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250

Disattiva prevenzione della deviazione

gcloud

Disabilita la prevenzione delle deviazioni utilizzando gcloud CLI se hai installato Config Sync utilizzando la console Google Cloud o gcloud CLI. Assicurati di aggiornare gcloud CLI alla versione più recente. Imposta il campo spec.configSync.preventDrift del file gcloud config su false o rimuovi il campo, quindi applica il file gcloud config.

kubectl

Disabilita la prevenzione della deviazione utilizzando kubectl se hai installato manualmente Config Sync utilizzando kubectl. Imposta il campo spec.preventDrift dell'oggetto ConfigManagement su false o rimuovi il campo e poi applica l'oggetto ConfigManagement.

Questa azione elimina tutte le risorse del webhook di ammissione di Config Sync. Poiché l'oggetto Config Sync ValidatingWebhookConfiguration non esiste più, i riconciliatori di Config Sync non generano più configurazioni webhook per le risorse gestite.

Attiva il webhook di ammissione nelle origini con ambito dello spazio dei nomi

Le origini attendibili con ambito a livello di spazio dei nomi non sono completamente protette dal webhook. Il riconciliatore di Config Sync per ogni origine dello spazio dei nomi non dispone dell'autorizzazione per leggere o aggiornare gli oggetti ValidatingWebhookConfiguration a livello di cluster.

Questa mancanza di autorizzazione determina un errore per i log dei riconciliatori dello spazio dei nomi simile all'esempio seguente:

Failed to update admission webhook: KNV2013: applying changes to
admission webhook: Insufficient permission. To fix, make sure the reconciler has
sufficient permissions.:
validatingwebhookconfigurations.admissionregistration.k8s.io "admission-
webhook.configsync.gke.io" is forbidden: User "system:serviceaccount:config-
management-system:ns-reconciler-NAMESPACE" cannot update resource
"validatingwebhookconfigurations" in API group "admissionregistration.k8s.io" at
the cluster scope

Puoi ignorare questo errore se non vuoi utilizzare la protezione webhook per la tua fonte di riferimento basata su spazio dei nomi. Tuttavia, se vuoi utilizzare il webhook, concedi l'autorizzazione al riconciliatore per ogni origine attendibile con ambito dello spazio dei nomi dopo aver configurato la sincronizzazione da più di un'origine attendibile. Potrebbe non essere necessario eseguire questi passaggi se esiste già un RoleBinding per ns-reconciler-NAMESPACE con le autorizzazioni ClusterRole cluster-admin.

  1. Nella fonte attendibile principale, dichiara una nuova configurazione ClusterRole che concede l'autorizzazione al webhook di ammissione Config Sync. Questo ClusterRole deve essere definito una sola volta per cluster:

    # ROOT_SOURCE/cluster-roles/webhook-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: admission-webhook-role
rules:
- apiGroups: ["admissionregistration.k8s.io"]
  resources: ["validatingwebhookconfigurations"]
  resourceNames: ["admission-webhook.configsync.gke.io"]
  verbs: ["get", "update"]

  2. Per ogni origine con ambito dei nomi in cui deve essere concessa l'autorizzazione per il webhook di ammissione, dichiara una configurazione ClusterRoleBinding per concedere l'accesso al webhook di ammissione:

    # ROOT_SOURCE/NAMESPACE/sync-webhook-rolebinding.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-webhook
subjects:
- kind: ServiceAccount
  name: ns-reconciler-NAMESPACE
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: admission-webhook-role
  apiGroup: rbac.authorization.k8s.io

    Sostituisci NAMESPACE con lo spazio dei nomi in cui hai creato l'origine con ambito dello spazio dei nomi.

  3. Esegui il commit delle modifiche nella fonte attendibile principale, ad esempio se esegui la sincronizzazione da un repository Git:

    git add .
git commit -m 'Providing namespace repository the permission to update the admission webhook.'
git push

  4. Per verificare, utilizza kubectl get per assicurarti che siano stati creati i ClusterRole e ClusterRoleBinding:

    kubectl get clusterrole admission-webhook-role
kubectl get clusterrolebindings syncs-webhook

Disattiva la prevenzione della deviazione per le risorse abbandonate

Quando elimini un oggetto RootSync o RepoSync, per impostazione predefinita Config Sync non modifica le risorse precedentemente gestite dall'oggetto RootSync o RepoSync. Ciò può lasciare indietro diverse etichette e annotazioni utilizzate da Config Sync per monitorare questi oggetti delle risorse. Se la protezione dalla deviazione è abilitata, qualsiasi modifica alle risorse gestite in precedenza può essere rifiutata.

Se non hai utilizzato la propagazione dell'eliminazione, gli oggetti delle risorse rimasti potrebbero comunque conservare le etichette e le annotazioni aggiunte da Config Sync.

Se vuoi conservare le risorse gestite, annulla la gestione delle risorse prima di eliminare gli oggetti RootSync o RepoSync impostando l'annotazione configmanagement.gke.io/managed su disabled per ogni risorsa gestita dichiarata nella fonte attendibile. Questo indica a Config Sync di rimuovere le etichette e le annotazioni dalle risorse gestite, senza eliminare queste risorse. Al termine della sincronizzazione, puoi rimuovere l'oggetto RootSync o RepoSync.

Per eliminare queste risorse gestite, hai due opzioni:

  • Elimina le risorse gestite dalla fonte attendibile. Quindi, Config Sync eliminerà gli oggetti gestiti dal cluster. Al termine della sincronizzazione, puoi rimuovere l'oggetto RootSync o RepoSync.
  • Abilita la propagazione dell'eliminazione sull'oggetto RootSync o RepoSync prima di eliminarlo. Quindi, Config Sync eliminerà gli oggetti gestiti dal cluster.

Se l'oggetto RootSync o RepoSync viene eliminato prima di annullare la gestione o l'eliminazione delle relative risorse gestite, puoi ricreare l'oggetto RootSync o RepoSync, che adotterà le risorse sul cluster che corrispondono alla fonte attendibile. Successivamente puoi disgestire o eliminare le risorse, attendere la sincronizzazione delle modifiche ed eliminare di nuovo l'oggetto RootSync o RepoSync.

Passaggi successivi