Citrix ADC Ingress Controller

Unterstützung für Webhooks für Zugangscontroller

Zugangscontroller sind leistungsstarke Tools zum Abfangen von Anforderungen an den Kubernetes-API-Server vor der Persistenz des Objekts. Mithilfe von Kubernetes-Zugangscontrollern können Sie definieren und anpassen, was auf Ihrem Cluster ausgeführt werden darf. Daher sind sie nützliche Tools für Cluster-Administratoren, um vorbeugende Sicherheitskontrollen auf Ihrem Cluster bereitzustellen. Sie müssen jedoch die Zulassungssteuerungen in die kube-apiserver Binärdatei kompilieren, und sie bieten nur begrenzte Flexibilität.

Um diese Einschränkung zu überwinden, unterstützt Kubernetes dynamische Zugangscontroller, die als Erweiterungen entwickelt werden können und als zur Laufzeit konfigurierte Webhooks ausgeführt werden können.

Mithilfe der Webhooks für den Zugangscontroller können Kubernetes-Cluster-Administratoren zusätzliche Plug-Ins für die Zugriffskette des API-Servers erstellen, ohne sie neu zu kompilieren. Webhooks für Zugangscontroller können ausgeführt werden, wenn eine Ressource erstellt, aktualisiert oder gelöscht wird.

Sie können zwei Arten von Webhooks für Zugangscontroller definieren:

  • Validierung der Zulassung Webhook
  • mutierender Zulassung Webhook

Webhooks mit mutierender Zulassung werden zuerst aufgerufen und können Objekte ändern, die an den API-Server gesendet werden, um benutzerdefinierte Standardwerte durchzusetzen. Sobald alle Objektänderungen abgeschlossen sind und das eingehende Objekt vom API-Server validiert wurde, werden Webhooks für die Validierung der Zulassung aufgerufen. Die Validierung von Zugangs-Hooks verarbeitet Anfragen und akzeptiert oder lehnt Anfragen ab, um benutzerdefinierte Richtlinien durchzusetzen.

Das folgende Diagramm erklärt, wie der Webhook der Zugangssteuerung funktioniert:

admission-control-webhook

Hier sind einige der Szenarien, in denen Zulassungs-Webhooks nützlich sind:

  • Vorschreiben einer angemessenen Sicherheitsgrundlage für einen gesamten Namespace oder Cluster-Mandat. Zum Beispiel verhindern, dass Container als Root ausgeführt werden, oder sicherstellen, dass das Root-Dateisystem des Containers immer schreibgeschützt eingehängt ist.
  • Durchsetzung der Einhaltung bestimmter Standards und Vorgehensweisen für Beschriftungen, Anmerkungen oder Ressourcenbeschränkungen. Erzwingen Sie beispielsweise die Label-Validierung für verschiedene Objekte, um sicherzustellen, dass die richtigen Beschriftungen für verschiedene Objekte verwendet werden.

  • Um die Konfiguration der im Cluster ausgeführten Objekte zu überprüfen und zu verhindern, dass offensichtliche Fehlkonfigurationen Ihren Cluster treffen. Zum Beispiel, um Images zu erkennen und zu reparieren, die ohne semantische Tags bereitgestellt werden.

Wie bewerbe ich Zulassungskontrolleure

Das Schreiben eines Zugangscontrollers für jeden spezifischen Anwendungsfall ist nicht skalierbar und es ist hilfreich, ein System zu haben, das mehrere Konfigurationen unterstützt, die verschiedene Ressourcentypen und Felder abdecken. Sie können Open Policy Agent (OPA) und Gatekeeper verwenden, um einen anpassbaren Zugangs-Webhook für Kubernetes zu implementieren.

OPA ist eine allgemeine Open-Source-Richtlinien-Engine, die die Durchsetzung von Richtlinien im gesamten Stapel vereinheitlicht. Gatekeeper ist ein anpassbarer validierender Webhook, der CRD-basierte Richtlinien durchsetzt, die von OPA ausgeführt werden.

Gatekeeper(image credit)

Gatekeeper führt die folgenden Funktionen ein

  • Eine erweiterbare, parametrisierte Richtlinienbibliothek
  • Native Kubernetes-CRDs zum Instanziieren der Richtlinienbibliothek (Einschränkungen)
  • Native Kubernetes-CRDs zum Erweitern der Richtlinienbibliothek (Beschränkungsvorlagen)
  • Funktionen für die Prüfung

Schreiben und Bereitstellen eines Webhook für die Zugangssteuerung

Voraussetzungen

  • Kubernetes 1.14.0 oder höher mit aktivierter admissionregistration.k8s.io/v1beta1 API.
    Sie können überprüfen, ob die API aktiviert ist, indem Sie den folgenden Befehl verwenden:

     kubectl api-versions | grep admissionregistration.k8s.io/v1beta1
    

    Die folgende Ausgabe zeigt an, dass die API aktiviert ist:

     admissionregistration.k8s.io/v1beta1
    
  • Der Webhook für die mutierende Zulassung und die Webhook-Zugangssteuerung für die Validierung der Zulassung sollten hinzugefügt und in der richtigen Reihenfolge im Zulassungskontrollflag von aufgeführt werden kube-apiserver.

Mit Minikube können Sie diese Aufgabe ausführen, indem Sie Minikube mit dem folgenden Befehl starten:

    minikube start --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook`
  • Stellen Sie sicher, dass Sie über Cluster-Administrator

     kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user <YOUR USER NAME>
    

Webhook-Konfiguration für die Zulassung mutieren

Weitere Informationen zur mutierenden Webhook-Konfiguration für die Zulassung finden Sie unter ingress-admission-webhook.

Die folgenden Anwendungsfälle werden im Webhook-Beispiel für mutierende Zulassung behandelt:

  • Aktualisieren Sie den Port in einem Ingress basierend auf dem Ingress-Namen
  • Ermöglichen Sie sicheres Back-End mit Nachdruck basierend auf einem Namespace

Validierung der Webhook-Konfiguration für die Zulassung mit Gatekeeper

Gatekeeper verwendet eine CRD, mit der Sie Beschränkungen als Kubernetes-Ressourcen erstellen können. Diese CRD wird ConstraintTemplate in Gatekeeper genannt. Das Schema der Beschränkung ermöglicht es einem Administrator, das Verhalten einer Beschränkung, ähnlich wie bei Argumenten einer Funktion, zu verfeinern. Einschränkungen werden verwendet, um Gatekeeper darüber zu informieren, dass der Administrator möchte, dass eine Beschränkungsvorlage durchgesetzt werden soll und wie.

Sie können verschiedene Richtlinien mithilfe von Beschränkungsvorlagen anwenden. In der Gatekeeper-Bibliotheksind verschiedene Beispiele aufgeführt.

Bereitstellen einer Beispielrichtlinie

Führen Sie die folgenden Schritte aus, um sie mit Gatekeeper HttpsOnly als Beispielrichtlinie bereitzustellen. Die HttpsOnly Richtlinie erlaubt nur eine Ingress-Konfiguration mit HTTPS.

  1. Installieren Sie Gatekeeper mit dem folgenden Befehl.

    Hinweis:

    In diesem Schritt wird Gatekeeper mit einem vorgefertigten Image installiert. Sie können Gatekeeper mit verschiedenen Methoden installieren, die in der Gatekeeper-Installation erwähnt werden.

    # kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml
    

    Sie können die Installation mit dem folgenden Befehl überprüfen.

    kubectl get crd | grep -i constraintsonstrainttemplates.templates.gatekeeper.sh  
    

    Sie können alle Beschränkungsvorlagen mit dem folgenden Befehl überprüfen:

     kubectl get constrainttemplates.templates.gatekeeper.sh
    
  2. Wenden Sie die httpsonly Bedingungsvorlage an.

     kubectl apply -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/template.yaml
    
  3. Wenden Sie eine Einschränkung an, um die httpsonly Richtlinie durchzusetzen.

     kubectl apply -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/constraint.yaml
    
  4. Stellen Sie ein Beispiel für Ingress bereit, das gegen die Richtlinie verstößt, um die Richtlinie zu überprüfen. Beim Erstellen des Ingress sollte ein Fehler angezeigt werden.

    kubectl apply -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/bad-example-ingress.yaml
    
    Error from server ([denied by ingress-https-only] Ingress must be https. tls configuration is required for test-ingress): error when creating "ingress.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by ingress-https-only] Ingress must be https. tls configuration is required for test-ingress
    
  5. Stellen Sie nun einen Ingress bereit, der den erforderlichen TLS-Abschnitt in Ingress hat.

     # kubectl apply -f  https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/good-example-ingress.yaml
           
     ingress.networking.k8s.io/test-ingress created
    
  6. Bereinigen Sie die Installation mit den folgenden Befehlen, nachdem Sie die Überprüfung der Gatekeeper-Richtlinien abgeschlossen haben.

    Uninstall all packages and template installed.
    kubectl delete -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/good-example-ingress.yaml
    kubectl delete -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/constraint.yaml
    kubectl delete -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/template.yaml
    kubectl delete -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml
    

Weitere Anwendungsbeispiele

Im Webhook-Verzeichnis sind mehrere Anwendungsfälle aufgeführt. Die Schritte ähneln den Angaben im Beispiel und können wie folgt zusammengefasst werden:

  1. Wenden Sie die in jedem Anwendungsfallverzeichnis angegebene YAML-Vorlagendatei an.
  2. Wenden Sie die YAML-Integritätsdatei an.
  3. Überprüfen Sie dies, indem Sie schlechte oder gute YAML-Beispieldateien anwenden, um den Anwendungsfall zu überprüfen.

Weitere Anwendungsfälle finden Sie in der Gatekeeper-Bibliothek.

Unterstützung für Webhooks für Zugangscontroller