Weryfikowanie kontrolerów przyjęć

Ten artykuł jest częścią serii. Zacznij od omówienia.

Kontrolery przyjęć rzadko powodują problemy, ale ma kluczowe znaczenie dla zapewnienia ich prawidłowej funkcjonalności. W tym artykule omówiono, jak kontrolery dostępu mogą wpływać na inne składniki, gdy nie działają prawidłowo. W tym artykule opisano również polecenia, których można użyć do weryfikowania wydajności kontrolera dostępu.

Kontroler wpływu danych

Kontroler wpływu danych jest fragmentem kodu, który przechwytuje żądania do serwera interfejsu API Kubernetes przed trwałością obiektu, ale po uwierzytelnieniu i autoryzacji żądania.

Kontrolery przyjęć mogą walidować, mutować lub kombinacji obu. Zmutowanie kontrolerów może modyfikować powiązane obiekty przed przyznaniem żądania. Weryfikowanie kontrolerów zapewnia wyłącznie, że żądania spełniają określone wstępnie zdefiniowane kryteria.

Jedną z podstawowych funkcji kontrolerów przyjęć jest uregulowanie żądań dotyczących tworzenia, usuwania i modyfikowania obiektów. Ponadto kontrolery dostępu mogą ograniczać niestandardowe czasowniki, takie jak żądanie połączenia z zasobnikiem za pośrednictwem serwera proxy serwera interfejsu API. Kontrolery wpływu nie mogą jednak blokować żądań odczytu obiektów, w tym operacji, takich jak get, watchlub list.

Niektóre składniki mogą mieć wpływ na kontrolery przyjęć, takie jak wyciszanie i weryfikowanie elementów webhook. W przypadku dołączania do klastra Kubernetes zmutowania i sprawdzania poprawności elementów webhook konieczne jest zapewnienie wysokiej dostępności. Węzły w złej kondycji nie powinny blokować żądań serwera interfejsu API. Ważne jest, aby monitorować potok kontroli dostępu, aby żądania do serwera interfejsu API nie były blokowane. Kontrolery przyjęć w złej kondycji mogą mieć wpływ na mutowanie i weryfikowanie elementów webhook. Kontrolery dostępu oparte na elementach webhook, które należy monitorować, obejmują:

• Dodatek usługi Azure Policy dla klastrów usługi Azure Kubernetes Service (AKS), który rozszerza usługę Gatekeeper. Gatekeeper to element webhook kontrolera dostępu dla programu Open Policy Agent.

• Kyverno, który działa jako dynamiczny kontroler wstępu w klastrze Kubernetes. Kyverno odbiera walidację i wyciszanie wywołań zwrotnych HTTP elementu webhook z serwera interfejsu API Kubernetes i stosuje pasujące zasady w celu zwrócenia wyników, które wymuszają zasady przyjęcia lub odrzucają żądania. Aby uzyskać informacje dotyczące rozwiązywania problemów (takie jak nieudane wywołania elementu webhook serwera APIServer), zobacz dokumentację rozwiązywania problemów z usługą Kyverno.

Alternatywnie kontrolery dostępu, które nie działają prawidłowo, mogą mieć wpływ na różne składniki, takie jak siatki usług. Siatki usług, takie jak Istio i Linkerd, używają kontrolerów dostępu do automatyzowania iniekcji pojemników przyczepki wewnątrz zasobnika, między innymi funkcji. Ważne jest, aby ocenić i sprawdzić, czy kontrolery dostępu działają prawidłowo, aby zapewnić bezproblemową obsługę siatki usług.

Sprawdzanie stanu dodatku usługi Azure Policy dla klastrów usługi AKS

Jeśli zainstalujesz dodatek usługi Azure Policy dla usługi AKS, możesz użyć następujących poleceń kubectl, aby zweryfikować instalację i funkcjonalność kontrolerów przyjęć usługi Azure Policy w klastrze:

# Verify that Azure Policy pods are running.
kubectl get pod -n gatekeeper-system

# Sample output
...
NAME                                     READY   STATUS    RESTARTS   AGE
gatekeeper-audit-65844778cb-rkflg        1/1     Running   0          163m
gatekeeper-controller-78797d4687-4pf6w   1/1     Running   0          163m
gatekeeper-controller-78797d4687-splzh   1/1     Running   0          163m
...

Uruchom poprzednie polecenie, aby sprawdzić dostępność zasobników agenta usługi Azure Policy w przestrzeni nazw gatekeeper-system . Jeśli dane wyjściowe nie są oczekiwane, może to wskazywać na problem z kontrolerem dostępu, usługą interfejsu API lub niestandardową definicją zasobu (CRD).

# Check that all API resources are working correctly. Use the following command to list all API resources.
kubectl api-resources

# Sample output
...
NAME                                     SHORTNAMES    APIGROUP                       NAMESPACED   KIND
bindings                                                                              true         Binding
componentstatuses                        cs                                           false        ComponentStatus
configmaps                               cm                                           true         ConfigMap
...

Poprzednie polecenie pomaga sprawdzić, czy wszystkie zasoby interfejsu API działają poprawnie. Upewnij się, że dane wyjściowe zawierają oczekiwane zasoby bez żadnych błędów lub brakujących składników. kubectl get pod Użyj poleceń ikubectl api-resources, aby sprawdzić stan dodatku usługi Azure Policy dla usługi AKS i sprawdzić funkcjonalność kontrolerów wpływu danych w klastrze Kubernetes. Regularnie monitoruj kontrolery przyjęć, aby upewnić się, że działają prawidłowo, dzięki czemu można zachować ogólną kondycję i stabilność klastra.

Użyj następującego kubectl get polecenia, aby potwierdzić, że przypisania zasad są stosowane do klastra:

kubectl get constrainttemplates

Dane wyjściowe powinny być podobne do następującego przykładu:

NAME                                     AGE
k8sazureallowedcapabilities              23m
k8sazureallowedusersgroups               23m
k8sazureblockhostnamespace               23m
k8sazurecontainerallowedimages           23m
k8sazurecontainerallowedports            23m
k8sazurecontainerlimits                  23m
k8sazurecontainernoprivilege             23m
k8sazurecontainernoprivilegeescalation   23m
k8sazureenforceapparmor                  23m
k8sazurehostfilesystem                   23m
k8sazurehostnetworkingports              23m
k8sazurereadonlyrootfilesystem           23m
k8sazureserviceallowedports              23m

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Zabezpieczanie klastrów usługi AKS za pomocą usługi Azure Policy
• Wbudowane definicje usługi Azure Policy dla usługi AKS

Weryfikowanie elementów webhook

Aby upewnić się, że walidacja i wyciszanie elementów webhook działają zgodnie z oczekiwaniami w klastrze Kubernetes, wykonaj następujące kroki.

1. Uruchom następujące polecenie, aby wyświetlić listę prawidłowych elementów webhook w klastrze:

   kubectl get ValidatingWebhookConfiguration -o wide
   

   Dane wyjściowe powinny być podobne do następującego przykładu:

   NAME                         WEBHOOKS   AGE
   aks-node-validating-webhook   1          249d
   azure-policy-validating-webhook-configuration   1          249d
   gatekeeper-validating-webhook-configuration     1          249d
   

   Przejrzyj dane wyjściowe, aby sprawdzić, czy są obecne prawidłowe elementy webhook, a ich konfiguracje są zgodnie z oczekiwaniami. Dane wyjściowe zawierają nazwę każdego walidowania elementu webhook, liczbę elementów webhook i wiek każdego elementu webhook.

2. Uruchom następujące polecenie, aby wyświetlić listęmutujących elementów webhook w klastrze:

   kubectl get MutatingWebhookConfiguration -o wide
   

   Dane wyjściowe powinny być podobne do następującego przykładu:

   NAME                         WEBHOOKS   AGE
   aks-node-mutating-webhook    1          249d
   azure-policy-mutating-webhook-configuration    1          249d
   gatekeeper-mutating-webhook-configuration      1          249d
   

   Sprawdź dane wyjściowe, aby upewnić się, że zmutowane elementy webhook są poprawnie wyświetlane, a ich konfiguracje są zgodnie z potrzebami. Dane wyjściowe zawierają nazwę każdego zmutujących elementów webhook, liczbę elementów webhook i wiek każdego elementu webhook.

3. Uruchom następujące polecenie, aby pobrać szczegółowe informacje dotyczące określonego kontrolera dostępu:

   kubectl get MutatingWebhookConfiguration <mutating-webhook-name> -o yaml
   

   Zastąp <mutating-webhook-name> ciąg nazwą mutowania elementu webhook, dla którego chcesz pobrać szczegóły. Dane wyjściowe tego polecenia wyświetla reprezentację YAML określonej konfiguracji mutowania elementu webhook.

Uruchom polecenia w tej sekcji i przejrzyj dane wyjściowe, aby potwierdzić, że walidujące imutujące elementy webhook w klastrze Kubernetes są obecne i skonfigurowane zgodnie z oczekiwaniami. Ta weryfikacja jest niezbędna do zapewnienia prawidłowego działania. Ważne jest również zapewnienie, że elementy webhook są zgodne z zasadami sprawdzania poprawności i modyfikowania zasobów w klastrze.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

• Paolo Salvatori | Główny inżynier klienta

Inni współautorzy:

• Franciszek Simy FrancisZki | Starszy specjalista techniczny

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Powiązane zasoby