Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Cloud de Confiance di S3NS. Per maggiori dettagli, consulta Differenze rispetto a Google Cloud.

Questa pagina è stata tradotta dall'API Cloud Translation.

Prevenzione di deviazioni dalla configurazione

Config Sync riduce il rischio di "operazioni ombra" tramite l'autoriparazione automatica, la risincronizzazione periodica e la prevenzione della deriva facoltativa. Quando Config Sync rileva una discrepanza tra il cluster e la fonte attendibile, può essere consentita e ripristinata rapidamente o rifiutata completamente.

Self-healing monitora le risorse gestite, rileva la deviazione dalla fonte attendibile e la ripristina. L'autoriparazione è sempre attiva.

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

Sebbene l'autoriparazione e le risincronizzazioni periodiche contribuiscano a correggere la deriva, la prevenzione della deriva intercetta le richieste di modifica degli oggetti gestiti e verifica se la modifica deve essere consentita. Se la modifica non corrisponde alla fonte attendibile, viene rifiutata. La prevenzione della deriva è disattivata per impostazione predefinita. Se abilitata, la prevenzione della deriva protegge per impostazione predefinita gli oggetti RootSync e può essere configurata anche per proteggere gli oggetti RepoSync.

Per utilizzare la prevenzione della deriva, devi abilitare le API RootSync e RepoSync.

Prima di iniziare

Se hai già installato Google Cloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update.

Attiva la prevenzione della deriva

Puoi abilitare la prevenzione della deriva utilizzando gcloud CLI. Non puoi attivare la prevenzione della deriva nella console Cloud de Confiance .

Per attivare la prevenzione della deriva, completa i seguenti passaggi:

Aggiorna il manifest di applicazione delle specifiche per impostare il campo spec.configSync.preventDrift su true:

applySpecVersion: 1
spec:
  configSync:
    enabled: true
    ... existing content ...
    preventDrift: true

Applica il manifest aggiornato:
```
gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=MANIFEST_NAME  \
    --project=PROJECT_ID
```
Sostituisci quanto segue:
- MEMBERSHIP_NAME: il nome dell'appartenenza al parco risorse che hai scelto quando hai registrato il cluster. Recupera il nome con il comando gcloud container fleet memberships list.
- MANIFEST_NAME: il nome del file manifest delle specifiche di applicazione, di solito apply-spec.yaml.
- PROJECT_ID: il tuo ID progetto.

Attendi la creazione dell'oggetto ValidateWebhookConfiguration di Config Sync da parte dell'operatore ConfigManagement:

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

Dovresti vedere un output simile al seguente esempio:

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

Esegui il commit di una nuova modifica all'origine attendibile da sincronizzare in modo che il root-reconciler Deployment possa aggiungere webhook all'oggetto ValidatingWebhookConfiguration di Config Sync. Un'alternativa è eliminare l'root-reconcilier Deployment per attivare una riconciliazione. Il nuovo deployment root-reconciler aggiornerebbe l'oggetto ValidatingWebhookConfiguration di Config Sync.

Attendi che il server webhook sia pronto. Il log di deployment del webhook di ammissione di Config Sync deve includere serving webhook server. L'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 al seguente esempio:

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

Disattivare la prevenzione della deriva

Quando disattivi la prevenzione della deriva, Config Sync elimina tutte le risorse webhook di ammissione di Config Sync. Poiché l'oggetto Config Sync ValidatingWebhookConfiguration non esiste più, i riconciliatori Config Sync non generano più le configurazioni webhook per le risorse gestite.

Per disattivare la prevenzione della deriva, completa i seguenti passaggi:

Aggiorna il manifest di applicazione delle specifiche per impostare il campo spec.configSync.preventDrift su false:

applySpecVersion: 1
spec:
  configSync:
    enabled: false
    ... existing content ...
    preventDrift: false

Applica il manifest aggiornato:
```
gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=MANIFEST_NAME  \
    --project=PROJECT_ID
```
Sostituisci quanto segue:
- MEMBERSHIP_NAME: il nome dell'appartenenza al parco risorse che hai scelto quando hai registrato il cluster. Recupera il nome con il comando gcloud container fleet memberships list.
- MANIFEST_NAME: il nome del file manifest delle specifiche di applicazione, di solito apply-spec.yaml.
- PROJECT_ID: il tuo ID progetto.

Abilita il webhook di controllo degli accessi nelle origini con ambito spazio dei nomi

Le origini attendibili con ambito a livello di spazio dei nomi non sono completamente protette dal webhook. Il riconciliatore 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 genera un errore nei log dei riconciliatori dello spazio dei nomi simile al seguente esempio:

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 origine attendibile con ambito spazio dei nomi. Tuttavia, se vuoi utilizzare il webhook, concedi l'autorizzazione al riconciliatore per ogni origine attendibile con ambito spazio dei nomi dopo aver configurato la sincronizzazione da più di un'origine attendibile. Potresti non dover eseguire questi passaggi se esiste già un RoleBinding per ns-reconciler-NAMESPACE con le autorizzazioni di ClusterRole cluster-admin.

Nella fonte attendibile principale, dichiara una nuova configurazione ClusterRole che conceda l'autorizzazione al webhook di ammissione di 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"]

Per ogni origine con ambito spazio dei nomi in cui è necessario concedere l'autorizzazione del webhook di controllo ammissione, dichiara una configurazione ClusterRoleBinding per concedere l'accesso al webhook di controllo 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.

Esegui il commit delle modifiche nella fonte di riferimento principale, ad esempio se la sincronizzazione viene eseguita da un repository Git:
```
git add .
git commit -m 'Providing namespace repository the permission to update the admission webhook.'
git push
```
Per verificare, utilizza kubectl get per assicurarti che siano stati creati ClusterRole e ClusterRoleBinding:
```
kubectl get clusterrole admission-webhook-role
kubectl get clusterrolebindings syncs-webhook
```

Disattiva la prevenzione della deriva per le risorse abbandonate

Quando elimini un oggetto RootSync o RepoSync, per impostazione predefinita Config Sync non modifica le risorse gestite in precedenza da quell'oggetto RootSync o RepoSync. In questo modo rimangono diverse etichette e annotazioni che Config Sync utilizza per monitorare questi oggetti risorsa. Se la protezione dalla deriva è attivata, le modifiche alle risorse gestite in precedenza potrebbero essere rifiutate.

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

Se vuoi conservare queste risorse gestite, annulla la gestione prima di eliminare gli oggetti RootSync o RepoSync impostando l'annotazione configmanagement.gke.io/managed su disabled per ogni risorsa gestita dichiarata nell'origine attendibile. Indica a Config Sync di rimuovere le etichette e le annotazioni dalle risorse gestite, senza eliminarle. Una volta completata la sincronizzazione, puoi rimuovere l'oggetto RootSync o RepoSync.

Se vuoi eliminare queste risorse gestite, hai due opzioni:

Elimina le risorse gestite dalla fonte attendibile. Poi Config Sync eliminerà gli oggetti gestiti dal cluster. Una volta completata la sincronizzazione, puoi rimuovere l'oggetto RootSync o RepoSync.
Attiva la propagazione dell'eliminazione sull'oggetto RootSync o RepoSync prima di eliminarlo. Dopodiché, Config Sync eliminerà gli oggetti gestiti dal cluster.

Se l'oggetto RootSync o RepoSync viene eliminato prima di annullare la gestione o eliminare le relative risorse gestite, puoi ricreare l'oggetto RootSync o RepoSync, che adotta le risorse del cluster che corrispondono all'origine attendibile. A questo punto puoi annullare la gestione o eliminare le risorse, attendere la sincronizzazione delle modifiche ed eliminare di nuovo l'oggetto RootSync o RepoSync.

Passaggi successivi

Scopri come risolvere i problemi relativi al webhook.