Zum Hauptinhalt springen

Admission Webhook for K8s

1. Übersicht & Dokumente für Casbin K8s-Gatekeeper​

Casbin K8s-GateKeeper ist ein Kubernetes-Zulassungs-Webhook, der Casbin als Zugriffskontrollwerkzeug integriert. Mit Casbin K8s-GateKeeper können Sie flexible Regeln erstellen, um jede Operation auf K8s-Ressourcen zu autorisieren oder abzufangen, OHNE einen einzigen Code zu schreiben, sondern nur einige Zeilen von deklarativen Konfigurationen von Casbin-Modellen und -Richtlinien, die Teil der Casbin ACL (Access Control List) Sprache sind.

Casbin K8s-GateKeeper wird von der Casbin-Community entwickelt und gewartet. Das Repository dieses Projekts ist hier verfügbar: https://github.com/casbin/k8s-gatekeeper

0.1 Ein einfaches Beispiel​

Zum Beispiel müssen Sie keinen Code schreiben, sondern die folgenden Konfigurationszeilen verwenden, um diese Funktion zu erreichen: "Verbieten Sie, dass Bilder mit einigen spezifizierten Tags in beliebigen Bereitstellungen verwendet werden":

Model:

[request_definition]
r =  obj

[policy_definition]
p =  obj,eft

[policy_effect]
e = !some(where (p.eft == deny))

[matchers]
m = r.obj.Request.Namespace == "default" && r.obj.Request.Resource.Resource =="deployments" && \
contain(split(accessWithWildcard(${OBJECT}.Spec.Template.Spec.Containers , "*", "Image"),":",1) , p.obj)

And Policy:

p, "1.14.1",deny

Diese sind in gewöhnlicher Casbin ACL Sprache. Angenommen, Sie haben bereits Kapitel darüber gelesen, dann wird es sehr einfach zu verstehen sein.

Casbin K8s-Gatekeeper hat die folgenden Vorteile:

  • Einfach zu bedienen. Einige Zeilen ACL zu schreiben ist viel besser als viel Code zu schreiben.
  • Es ermöglicht heiße Updates von Konfigurationen. Sie müssen das gesamte Plugin nicht herunterfahren, um Konfigurationen zu ändern.
  • Es ist flexibel. Beliebige Regeln können auf jede K8s-Ressource angewendet werden, die mit kubectl gatekeeper erkundet werden kann.
  • Es vereinfacht die Implementierung des K8s-Zulassungs-Webhooks, der sehr kompliziert ist. Sie müssen nicht wissen, was ein K8s-Zulassungs-Webhook ist oder wie man Code dafür schreibt. Alles, was Sie tun müssen, ist zu wissen, auf welche Ressource Sie Einschränkungen setzen möchten und dann Casbin ACL zu schreiben. Jeder weiß, dass K8s komplex ist, aber mit Casbin K8s-Gatekeeper können Sie Zeit sparen.
  • Es wird von der Casbin-Community gewartet. Zögern Sie nicht, uns zu kontaktieren, wenn Sie etwas über dieses Plugin verwirrt oder wenn Sie auf Probleme stoßen, wenn Sie es ausprobieren.

1.1 Wie funktioniert Casbin K8s-Gatekeeper?​

K8s-Gatekeeper ist ein Zulassungs-Webhook für K8s, der Casbin verwendet, um willkürliche benutzerdefinierte Zugriffskontrollregeln anzuwenden, um jede Operation auf K8s zu verhindern, die der Administrator nicht möchte.

Casbin ist eine leistungsstarke und effiziente Open-Source-Zugriffskontrollbibliothek. Es bietet Unterstützung für die Durchsetzung von Autorisierungen basierend auf verschiedenen Zugriffskontrollmodellen. Weitere Details zu Casbin finden Sie unter Übersicht.

Zulassungs-Webhooks in K8s sind HTTP-Callbacks, die 'Zulassungsanfragen' erhalten und etwas mit ihnen machen. Insbesondere ist K8s-Gatekeeper eine spezielle Art von Zulassungs-Webhook: 'ValidatingAdmissionWebhook', der entscheiden kann, ob diese Zulassungsanfrage akzeptiert oder abgelehnt wird oder nicht. Bei Zulassungsanfragen handelt es sich um HTTP-Anfragen, die eine Operation an bestimmten Ressourcen von K8s beschreiben (zum Beispiel das Erstellen/Löschen einer Bereitstellung). Weitere Informationen zu Zulassungs-Webhooks finden Sie in der offiziellen K8s-Dokumentation.

1.2 Ein Beispiel zur Veranschaulichung der Funktionsweise​

Wenn beispielsweise jemand eine Bereitstellung erstellen möchte, die einen Pod enthält, der nginx ausführt (mit kubectl oder K8s-Clients), generiert K8s eine Zulassungsanfrage, die (wenn sie in YAML-Format übersetzt wird) so aussehen könnte:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.1
        ports:
        - containerPort: 80

Diese Anfrage durchläuft den Prozess aller in der Abbildung gezeigten Middleware, einschließlich unseres K8s-Gatekeepers. K8s-Gatekeeper kann alle Casbin-Durchsetzer erkennen, die in K8s's etcd gespeichert sind, die vom Benutzer erstellt und gewartet werden (über kubectl oder den von uns bereitgestellten Go-Client). Jeder Durchsetzer enthält ein Casbin-Modell und eine Casbin-Richtlinie. Die Zulassungsanfrage wird von jedem Durchsetzer einzeln bearbeitet, und nur durch das Bestehen aller Durchsetzer kann eine Anfrage von diesem K8s-Gatekeeper akzeptiert werden.

(Wenn Sie nicht verstehen, was ein Casbin-Durchsetzer, Modell oder Richtlinie ist, sehen Sie dieses Dokument: Erste Schritte).

Zum Beispiel möchte der Administrator aus irgendeinem Grund das Auftreten des Bildes 'nginx:1.14.1' verbieten, während 'nginx:1.3.1' erlaubt ist. Es kann ein Durchsetzer erstellt werden, der die folgende Regel und Richtlinie enthält (Wir werden erklären, wie man einen Durchsetzer erstellt, was diese Modelle und Richtlinien sind und wie man sie in den folgenden Kapiteln schreibt).

Model:

[request_definition]
r =  obj

[policy_definition]
p =  obj,eft

[policy_effect]
e = !some(where (p.eft == deny))

[matchers]
m = r.obj.Request.Namespace == "default" && r.obj.Request.Resource.Resource =="deployments" && \
access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Image") == p.obj

Policy:

p, "nginx:1.13.1",allow
p, "nginx:1.14.1",deny

Durch das Erstellen eines Durchsetzers, der das oben genannte Modell und die Richtlinie enthält, wird die vorherige Zulassungsanfrage von diesem Durchsetzer abgelehnt, was bedeutet, dass K8s diese Bereitstellung nicht erstellen wird.

2 Installieren Sie K8s-Gatekeeper​

Es stehen drei Methoden zur Verfügung, um K8s-Gatekeeper zu installieren: Externer Webhook, Interner Webhook und Helm.

notiz

Hinweis: Diese Methoden sind nur dazu gedacht, dass Benutzer K8s-Gatekeeper ausprobieren können und sind nicht sicher. Wenn Sie es in einer produktiven Umgebung verwenden möchten, stellen Sie bitte sicher, dass Sie Kapitel 5. Erweiterte Einstellungen lesen und vor der Installation alle notwendigen Änderungen vornehmen.

2.1 Interner Webhook​

2.1.1 Schritt 1: Erstellen Sie das Image​

Bei der internen Webhook-Methode wird der Webhook selbst als Dienst innerhalb von Kubernetes implementiert. Um den notwendigen Dienst und die Bereitstellung zu erstellen, müssen Sie ein Image von K8s-Gatekeeper erstellen. Sie können Ihr eigenes Image erstellen, indem Sie den folgenden Befehl ausführen:

docker build --target webhook -t k8s-gatekeeper .

Dieser Befehl erstellt ein lokales Image namens 'k8s-gatekeeper:latest'.

notiz

Hinweis: Wenn Sie minikube verwenden, führen Sie bitte eval $(minikube -p minikube docker-env) aus, bevor Sie 'docker build' ausführen.

2.1.2 Schritt 2: Richten Sie Dienste und Bereitstellungen für K8s-Gatekeeper ein​

Führen Sie die folgenden Befehle aus:

kubectl apply -f config/rbac.yaml
kubectl apply -f config/webhook_deployment.yaml 
kubectl apply -f config/webhook_internal.yaml

Dies startet K8s-Gatekeeper, und Sie können dies bestätigen, indem Sie kubectl get pods ausführen.

2.1.3 Schritt 3: Installieren Sie CRD-Ressourcen für K8s-Gatekeeper​

Führen Sie die folgenden Befehle aus:

kubectl apply -f config/auth.casbin.org_casbinmodels.yaml 
kubectl apply -f config/auth.casbin.org_casbinpolicies.yaml

2.2 Externer Webhook​

Für die Methode des externen Webhooks wird K8s-Gatekeeper außerhalb von Kubernetes laufen, und Kubernetes wird auf K8s-Gatekeeper zugreifen, wie es auf eine reguläre Website zugreifen würde. Kubernetes hat eine obligatorische Anforderung, dass der Zulassungs-Webhook HTTPS sein muss. Zum Ausprobieren von K8s-Gatekeeper haben wir ein Set von Zertifikaten und einen privaten Schlüssel bereitgestellt (obwohl dies nicht sicher ist). Wenn Sie lieber Ihr eigenes Zertifikat verwenden möchten, verweisen Sie bitte auf Kapitel 5. Erweiterte Einstellungen für Anweisungen zur Anpassung des Zertifikats und des privaten Schlüssels.

Das von uns bereitgestellte Zertifikat ist für 'webhook.domain.local' ausgestellt. Ändern Sie also den Host (z.B. /etc/hosts) und leiten Sie 'webhook.domain.local' an die IP-Adresse weiter, auf der K8s-Gatekeeper läuft.

Führen Sie dann den folgenden Befehl aus:

go mod tidy
go mod vendor
go run cmd/webhook/main.go
kubectl apply -f config/auth.casbin.org_casbinmodels.yaml 
kubectl apply -f config/auth.casbin.org_casbinpolicies.yaml
kubectl apply -f config/webhook_external.yaml

2.3 Installieren Sie K8s-Gatekeeper über Helm​

2.3.1 Schritt 1: Erstellen Sie das Image​

Bitte verweisen Sie auf Kapitel 2.1.1.

2.3.2 Helm-Installation​

Führen Sie den Befehl helm install k8sgatekeeper ./k8sgatekeeper aus.

3. Probieren Sie K8s-Gatekeeper aus​

3.1 Erstellen Sie Casbin-Modell und -Richtlinie​

Sie haben zwei Methoden, um ein Modell und eine Richtlinie zu erstellen: über kubectl oder über den von uns bereitgestellten go-client.

3.1.1 Erstellen/Aktualisieren Sie Casbin-Modell und -Richtlinie über kubectl​

In K8s-Gatekeeper wird das Casbin-Modell in einer CRD-Ressource namens 'CasbinModel' gespeichert. Seine Definition befindet sich in config/auth.casbin.org_casbinmodels.yaml.

Es gibt Beispiele in example/allowed_repo/model.yaml. Achten Sie auf die folgenden Felder:

  • metadata.name: der Name des Modells. Dieser Name MUSS der gleiche sein wie der Name des CasbinPolicy-Objekts, das mit diesem Modell in Verbindung steht, damit K8s-Gatekeeper sie zuordnen und einen Durchsetzer erstellen kann.
  • spec.enable: Wenn dieses Feld auf "false" gesetzt ist, wird dieses Modell (sowie das CasbinPolicy-Objekt, das mit diesem Modell in Verbindung steht) ignoriert.
  • spec.modelText: eine Zeichenkette, die den Modelltext eines Casbin-Modells enthält.

Die Casbin-Richtlinie wird in einer anderen CRD-Ressource namens 'CasbinPolicy' gespeichert, deren Definition in config/auth.casbin.org_casbinpolicies.yaml gefunden werden kann.

Es gibt Beispiele in example/allowed_repo/policy.yaml. Achten Sie auf die folgenden Felder:

  • metadata.name: the name of the policy. This name MUST be the same as the name of the CasbinModel object related to this policy, so that K8s-gatekeeper can pair them and create an enforcer.
  • spec.policyItem: a string that contains the policy text of a Casbin model.

After creating your own CasbinModel and CasbinPolicy files, use the following command to apply them:

kubectl apply -f <filename>

Once a pair of CasbinModel and CasbinPolicy is created, K8s-gatekeeper will be able to detect it within 5 seconds.

3.1.2 Create/Update Casbin Model and Policy via the go-client we provide​

We understand that there may be situations where it is not convenient to use the shell to execute commands directly on a node of the K8s cluster, such as when you are building an automatic cloud platform for your corporation. Therefore, we have developed a go-client to create and maintain CasbinModel and CasbinPolicy.

The go-client library is located in pkg/client.

In client.go, we provide a function to create a client.

func NewK8sGateKeeperClient(externalClient bool) (*K8sGateKeeperClient, error)

The externalClient parameter determines whether K8s-gatekeeper is running inside the K8s cluster or not.

In model.go, we provide various functions to create, delete, and modify CasbinModel. You can find out how to use these interfaces in model_test.go.

In policy.go, we provide various functions to create, delete, and modify CasbiPolicy. You can find out how to use these interfaces in policy_test.go.

3.1.2 Try Whether K8s-gatekeeper Works​

Suppose you have already created the exact model and policy in example/allowed_repo. Now, try the following command:

kubectl apply -f example/allowed_repo/testcase/reject_1.yaml

You should find that K8s will reject this request and mention that the webhook was the reason why this request is rejected. However, when you try to apply example/allowed_repo/testcase/approve_2.yaml, it will be accepted.

4. How to Write Model and Policy with K8s-gatekeeper​

First of all, make sure you are familiar with the basic grammar of Casbin Models and Policies. If you are not, please read the Get Started section first. In this chapter, we assume that you already understand what Casbin Models and Policies are.

4.1 Request Definition of Model​

When K8s-gatekeeper is authorizing a request, the input is always an object: the Go object of the Admission Request. This means that the enforcer will always be used like this:

ok, err := enforcer.Enforce(admission)

where admission is an AdmissionReview object defined by K8s's official go api "k8s.io/api/admission/v1". You can find the definition of this struct in this repository: https://github.com/kubernetes/api/blob/master/admission/v1/types.go. Für weitere Informationen können Sie auch auf https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#webhook-request-and-response verweisen.

Daher sollte für jedes Modell, das von K8s-Gatekeeper verwendet wird, die Definition der request_definition immer so aussehen:

    [request_definition]
    r =  obj

Der Name 'obj' ist nicht obligatorisch, solange der Name mit dem Namen in dem Teil [matchers] übereinstimmt.

4.2 Matcher des Modells​

Sie sollten die ABAC-Funktion von Casbin verwenden, um Ihre Regeln zu schreiben. Der in Casbin integrierte Ausdrucksauswerter unterstützt jedoch keine Indizierung in Karten oder Arrays (Slices) oder die Erweiterung von Arrays. Daher bietet K8s-Gatekeeper verschiedene 'Casbin-Funktionen' als Erweiterungen an, um diese Funktionen zu implementieren. Wenn Sie immer noch feststellen, dass Ihre Anforderungen nicht durch diese Erweiterungen erfüllt werden können, zögern Sie nicht, ein Problem zu starten oder einen Pull-Request zu erstellen.

Wenn Sie mit Casbin-Funktionen nicht vertraut sind, können Sie sich für weitere Informationen auf Function beziehen.

Hier sind die Erweiterungsfunktionen:

4.2.1 Erweiterungsfunktionen​

4.2.1.1 Zugriff​

Access wird verwendet, um das Problem zu lösen, dass Casbin keine Indizierung in Karten oder Arrays unterstützt. Das Beispiel example/allowed_repo/model.yaml demonstriert die Verwendung dieser Funktion:

[matchers]
m = r.obj.Request.Namespace == "default" && r.obj.Request.Resource.Resource =="deployments" && \
access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Image") == p.obj

In diesem Matcher ist access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Image") gleichbedeutend mit r.obj.Request.Object.Object.Spec.Template.Spec.Containers[0].Image, wobei r.obj.Request.Object.Object.Spec.Template.Spec.Containers ein Slice ist.

Access kann auch einfache Funktionen aufrufen, die keine Parameter haben und einen einzelnen Wert zurückgeben. Das Beispiel example/container_resource_limit/model.yaml demonstriert dies:

[matchers]
  m = r.obj.Request.Namespace == "default" && r.obj.Request.Resource.Resource =="deployments" && \
  parseFloat(access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Resources","Limits","cpu","Value")) >= parseFloat(p.cpu) && \
  parseFloat(access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Resources","Limits","memory","Value")) >= parseFloat(p.memory)

In diesem Matcher ist access(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , 0, "Resources","Limits","cpu","Value") gleichbedeutend mit r.obj.Request.Object.Object.Spec.Template.Spec.Containers[0].Resources.Limits["cpu"].Value(), wobei r.obj.Request.Object.Object.Spec.Template.Spec.Containers[0].Resources.Limits eine Karte ist und Value() eine einfache Funktion ist, die keine Parameter hat und einen einzelnen Wert zurückgibt.

4.2.1.2 accessWithWildcard​

Manchmal haben Sie vielleicht eine Anforderung wie diese: Alle Elemente in einem Array müssen ein Präfix "aaa" haben. Casbin unterstützt jedoch keine for-Schleifen. Mit accessWithWildcard und der Funktion "Karten-/Slice-Erweiterung" können Sie eine solche Anforderung leicht umsetzen.

Zum Beispiel, angenommen a.b.c ist ein Array [aaa,bbb,ccc,ddd,eee], dann wird das Ergebnis von accessWithWildcard(a,"b","c","*") ein Slice [aaa,bbb,ccc,ddd,eee] sein. Durch die Verwendung des Wildcards * wird das Slice erweitert.

Ebenso kann das Wildcard mehr als einmal verwendet werden. Zum Beispiel wird das Ergebnis von accessWithWildcard(a,"b","c","*","*") [a.b.c[0][0], a.b.c[0][1], ..., a.b.c[1][0], a.b.c[1][1], ...] sein.

4.2.1.3 Funktionen, die variable Argumentlängen unterstützen​

Im Ausdrucksauswerter von Casbin wird ein Parameter, der ein Array ist, automatisch als Argument mit variabler Länge erweitert. Unter Ausnutzung dieser Funktion zur Unterstützung der Array-/Slice-/Karten-Erweiterung haben wir auch mehrere Funktionen integriert, die ein Array/Slice als Parameter akzeptieren:

  • contain(): akzeptiert mehrere Parameter und gibt zurück, ob ein beliebiger Parameter (außer dem letzten Parameter) dem letzten Parameter entspricht.
  • split(a,b,c...,sep,index): gibt eine Scheibe zurück, die [splits(a,sep)[index], splits(b,sep)[index], splits(a,sep)[index], ...] enthält.
  • len(): gibt die Länge des variablen Arguments zurück.
  • matchRegex(a,b,c...,regex): gibt zurück, ob alle gegebenen Parameter (a, b, c, ...) dem gegebenen Regex entsprechen.

Hier ist ein Beispiel in example/disallowed_tag/model.yaml:

    [matchers]
    m = r.obj.Request.Namespace == "default" && r.obj.Request.Resource.Resource =="deployments" && \
    contain(split(accessWithWildcard(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , "*", "Image"),":",1) , p.obj)

Angenommen, dass accessWithWildcard(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , "*", "Image") ["a:b", "c:d", "e:f", "g:h"] zurückgibt, weil splits variable Argumente unterstützt und die Split-Operation auf jedem Element durchführt, wird das Element am Index 1 ausgewählt und zurückgegeben. Daher gibt split(accessWithWildcard(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , "*", "Image"),":",1) ["b","d","f","h"] zurück. Und contain(split(accessWithWildcard(r.obj.Request.Object.Object.Spec.Template.Spec.Containers , "*", "Image"),":",1) , p.obj) gibt zurück, ob p.obj in ["b","d","f","h"] enthalten ist.

4.2.1.2 Typumwandlungsfunktionen​

  • ParseFloat(): Parst eine Ganzzahl zu einer Gleitkommazahl (dies ist notwendig, weil jede in einem Vergleich verwendete Zahl in eine Gleitkommazahl umgewandelt werden muss).
  • ToString(): Konvertiert ein Objekt zu einem String. Dieses Objekt muss einen Basistyp von String haben (zum Beispiel ein Objekt vom Typ XXX, wenn es eine Aussage type XXX string gibt).
  • IsNil(): Gibt zurück, ob der Parameter nil ist.

5. Erweiterte Einstellungen​

5.1 Über Zertifikate​

In Kubernetes (k8s) ist es obligatorisch, dass ein Webhook HTTPS verwenden sollte. Es gibt zwei Ansätze, um dies zu erreichen:

  • Verwendung von selbstsignierten Zertifikaten (Beispiele in diesem Repository verwenden diese Methode)
  • Verwendung eines normalen Zertifikats

5.1.1 Selbstsignierte Zertifikate​

Die Verwendung eines selbstsignierten Zertifikats bedeutet, dass die ausstellende Zertifizierungsstelle (CA) nicht eine der bekannten CAs ist. Daher müssen Sie k8s über diese CA informieren.

Derzeit verwendet das Beispiel in diesem Repository eine selbstgemachte CA, deren privater Schlüssel und Zertifikat in config/certificate/ca.crt und config/certificate/ca.key gespeichert sind. Das Zertifikat für den Webhook ist config/certificate/server.crt, das von der selbstgemachten CA ausgestellt wird. Die Domains dieses Zertifikats sind "webhook.domain.local" (für externen Webhook) und "casbin-webhook-svc.default.svc" (für internen Webhook).

Informationen über die CA werden über die Webhook-Konfigurationsdateien an k8s weitergegeben. Sowohl config/webhook_external.yaml als auch config/webhook_internal.yaml haben ein Feld namens "CABundle", das eine base64-kodierte Zeichenkette des Zertifikats der CA enthält.

Falls Sie das Zertifikat/die Domain ändern müssen (zum Beispiel, wenn Sie diesen Webhook in einen anderen Namespace von k8s verschieben möchten, während Sie einen internen Webhook verwenden, oder wenn Sie die Domain ändern möchten, während Sie einen externen Webhook verwenden), sollten die folgenden Verfahren befolgt werden:

  1. Erzeugen Sie eine neue CA:

    • Generieren Sie den privaten Schlüssel für die gefälschte CA:

      openssl genrsa -des3 -out ca.key 2048

    • Entfernen Sie den Passwortschutz des privaten Schlüssels:

      openssl rsa -in ca.key -out ca.key

  2. Generieren Sie einen privaten Schlüssel für den Webhook-Server:

    openssl genrsa -des3 -out server.key 2048
    openssl rsa -in server.key -out server.key

  3. Verwenden Sie die selbst generierte CA, um das Zertifikat für den Webhook zu signieren:

    • Kopieren Sie die OpenSSL-Konfigurationsdatei Ihres Systems für den vorübergehenden Gebrauch. Sie können den Speicherort der Konfigurationsdatei herausfinden, indem Sie openssl version -a ausführen, normalerweise openssl.cnf genannt.

    • In der Konfigurationsdatei:

      • Finden Sie den Absatz [req] und fügen Sie die folgende Zeile hinzu: req_extensions = v3_req

      • Finden Sie den Absatz [v3_req] und fügen Sie die folgende Zeile hinzu: subjectAltName = @alt_names

      • Fügen Sie die folgenden Zeilen zur Datei hinzu:

        [alt_names]
        DNS.2=<The domain you want>

        Hinweis: Ersetzen Sie 'casbin-webhook-svc.default.svc' durch den echten Dienstnamen Ihres eigenen Dienstes, wenn Sie den Dienstnamen ändern möchten.

    • Verwenden Sie die modifizierte Konfigurationsdatei, um eine Zertifikatsanforderungsdatei zu generieren:

      openssl req -new -nodes -keyout server.key -out server.csr -config openssl.cnf

    • Verwenden Sie die selbstgemachte CA, um auf die Anfrage zu reagieren und das Zertifikat zu signieren:

      openssl x509 -req -days 3650 -in server.csr -out server.crt -CA ca.crt -CAkey ca.key -CAcreateserial -extensions v3_req -extensions SAN -extfile openssl.cnf

  4. Ersetzen Sie das Feld 'CABundle': Sowohl config/webhook_external.yaml als auch config/webhook_internal.yaml haben ein Feld namens 'CABundle', das eine base64-kodierte Zeichenkette des Zertifikats der CA enthält. Aktualisieren Sie dieses Feld mit dem neuen Zertifikat.

  5. Wenn Sie Helm verwenden, müssen ähnliche Änderungen an den Helm-Charts vorgenommen werden.

5.1.2 Rechtsgültige Zertifikate​

Wenn Sie rechtsgültige Zertifikate verwenden, müssen Sie nicht alle diese Verfahren durchlaufen. Entfernen Sie das Feld 'CABundle' in config/webhook_external.yaml und config/webhook_internal.yaml und ändern Sie die Domain in diesen Dateien in die Domain, die Sie besitzen.