Ověření kontrolerů přístupu

Tento článek je součástí série článků. Začněte přehledem.

Kontrolery přístupu zřídka způsobují problémy, ale je důležité zajistit jejich správnou funkčnost. Tento článek popisuje, jak mohou kontrolery přístupu ovlivnit jiné komponenty, pokud nefungují správně. Popisuje také příkazy, které můžete použít k ověření výkonu kontroleru přístupu.

Kontroler přístupu

Kontroler přístupu je část kódu, která zachycuje požadavky na server rozhraní Kubernetes API před trvalostí objektu, ale po ověření a autorizaci požadavku.

Kontrolery přístupu můžou být validace, mutování nebo kombinace obou. Ztlumení kontrolerů může před přijetím požadavku upravit související objekty. Ověřování kontrolerů pouze zajišťuje, aby požadavky splňovaly konkrétní předdefinovaná kritéria.

Jednou z hlavních funkcí kontrolerů přístupu je regulace požadavků na vytváření, odstraňování a úpravy objektů. Kontrolery přístupu navíc můžou omezit vlastní příkazy, jako je například vyžádání připojení k podu prostřednictvím proxy serveru rozhraní API. Kontrolery přístupu ale nemůžou blokovat požadavky na čtení objektů, včetně operací, jako getje , watchnebo list.

Některé komponenty můžou ovlivnit kontrolery přístupu, jako je mutování a ověřování webhooků. Když do clusteru Kubernetes zahrnete ztlumení a ověřování webhooků, je nezbytné zajistit vysokou dostupnost. Uzly, které nejsou v pořádku, by neměly blokovat požadavky serveru rozhraní API. Je důležité monitorovat kanál řízení přístupu, takže požadavky na server rozhraní API nejsou blokované. Kontrolery přístupu, které nejsou v pořádku, můžou ovlivnit ztlumení a ověřování webhooků. Kontrolery přístupu založené na webhooku, které byste měli monitorovat, zahrnují:

  • Doplněk Azure Policy pro clustery Azure Kubernetes Service (AKS), který rozšiřuje Gatekeeper. Gatekeeper je webhook kontroleru přístupu pro agenta Open Policy.

  • Kyverno, který běží jako kontroler dynamického přístupu v clusteru Kubernetes. Kyverno přijímá ověřování a ztlumování zpětných volání HTTP webhooku přístupu ze serveru rozhraní API Kubernetes a používá odpovídající zásady pro vrácení výsledků, které vynucují zásady přístupu nebo odmítají požadavky. Referenční informace k řešení potíží (např. Selhání volání webhooku serveru APIServer) najdete v dokumentaci k řešení potíží s Kyverno.

Případně můžou kontrolery přístupu, které nefungují správně, ovlivnit různé komponenty, jako jsou například sítě služeb. Sítě služeb, jako je Istio a Linkerd, používají kontrolery přístupu k automatizaci injektáže kontejnerů sajdkárů uvnitř podu mimo jiné. Je důležité vyhodnotit a ověřit, že kontrolery přístupu fungují správně, aby se zajistilo bezproblémové fungování sítě služeb.

Kontrola stavu doplňku Azure Policy pro clustery AKS

Pokud nainstalujete doplněk Azure Policy pro AKS, můžete pomocí následujících příkazů kubectl ověřit instalaci a funkčnost kontrolerů přístupu azure Policy ve vašem clusteru:

# 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
...

Spuštěním předchozího příkazu ověřte dostupnost podů agenta Azure Policy v oboru názvů gatekeeper-system . Pokud výstup není to, co očekáváte, může to znamenat problém s kontrolerem přístupu, službou API nebo vlastní definicí prostředků (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
...

Předchozí příkaz vám pomůže ověřit, že všechny prostředky rozhraní API fungují správně. Ujistěte se, že výstup obsahuje očekávané prostředky bez chyb nebo chybějících komponent. kubectl get pod Pomocí příkazů kubectl api-resources můžete zkontrolovat stav doplňku Azure Policy pro AKS a ověřit funkčnost kontrolerů přístupu v clusteru Kubernetes. Pravidelně monitorujte kontrolery přístupu, abyste měli jistotu, že správně fungují, abyste mohli udržovat celkový stav a stabilitu clusteru.

Pomocí následujícího kubectl get příkazu potvrďte, že se pro váš cluster použijí přiřazení zásad:

kubectl get constrainttemplates

Poznámka:

Synchronizace přiřazení zásad s každým clusterem může trvat až 20 minut .

Výstup by se měl podobat následujícímu příkladu:

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

Další informace naleznete v následujících zdrojích:

Ověření webhooků

Pokud chcete zajistit, aby ověřování a ztlumování webhooků fungovalo podle očekávání v clusteru Kubernetes, postupujte podle těchto kroků.

  1. Spuštěním následujícího příkazu zobrazte seznam ověřovacích webhooků v clusteru:

    kubectl get ValidatingWebhookConfiguration -o wide
    

    Výstup by se měl podobat následujícímu příkladu:

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

    Zkontrolujte výstup a ověřte, že jsou k dispozici ověřování webhooků a jejich konfigurace jsou podle očekávání. Výstup obsahuje název každého validujícího webhooku, počet webhooků a věk každého webhooku.

  2. Spuštěním následujícího příkazu zobrazte seznam ztlumených webhooků v clusteru:

    kubectl get MutatingWebhookConfiguration -o wide
    

    Výstup by se měl podobat následujícímu příkladu:

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

    Zkontrolujte výstup a ujistěte se, že jsou správně uvedené ztlumené webhooky a jejich konfigurace jsou podle potřeby. Výstup obsahuje název každého ztlumujícího webhooku, počet webhooků a věk každého webhooku.

  3. Spuštěním následujícího příkazu načtěte konkrétní podrobnosti pro konkrétní kontroler přístupu:

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

    Nahraďte <mutating-webhook-name> názvem ztlumeného webhooku, pro který chcete načíst podrobnosti. Výstup tohoto příkazu zobrazí reprezentaci YAML zadané konfigurace mutujícího webhooku.

Spusťte příkazy v této části a zkontrolujte výstup, abyste si mohli ověřit, že ověřování a ztlumování webhooků v clusteru Kubernetes jsou přítomné a nakonfigurované podle očekávání. Toto ověření je nezbytné k zajištění správného fungování. Je také důležité zajistit, aby webhooky dodržovaly zásady pro ověřování a úpravy prostředků v clusteru.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

Další přispěvatelé:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.