☰

So deaktivieren Sie die unsichere Kubectl-Genehmigung gegenüber dem Kube-API-Server

tag-icon • tag-icon kubernetes kubeadm
So deaktivieren Sie die unsichere Kubectl-Genehmigung gegenüber dem Kube-API-Server

Ich versuche, meine Master-Server-API sicherer zu machen, um zu verhindern, dass Nicht-HTTPS-Anfragen durchkommen.

Beispiel einer Konfiguration:

$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    server: https://ip:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: REDACTED

Das funktioniert, solange ich die richtigen CAs verwende.

Mein Problem ist, dass es auch funktioniert, wenn ich die CAs entferne oder die falschen CAs habe und einfach das Flag anwende --insecure-skip-tls-verify.

Wie kann ich den Server zwingen, über die Server-API https-Verbindungen statt http zuzulassen?

Ich habe auch anonyme Anfragen deaktiviertAnonyme Anfragenaber ich sehe immer noch, dass die Anfragen durchgehen können.

Antwort1

Mein Problem ist, dass es auch funktioniert, wenn ich die CAs entferne oder die falschen CAs habe und einfach das Flag --insecure-skip-tls-verify anwende.

Die Verwendung --insecure-skip-tls-verifyist sehrNICHT EMPFOHLENin der Produktionsumgebung. Es kann verwendet werden, wenn Sie einige lokale Tests durchführen möchten oder zu Lernzwecken.

InKubectlDokumentation Sie haben Informationen:

--insecure-skip-tls-verify

If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure

Wenn dieses Flag also auf true gesetzt wird, werden Zertifikate immer übersprungen und die Identität des Servers wird überhaupt nicht überprüft. Es ist ähnlich wiecurl -k

-k, --insecure
              (TLS) By default, every SSL connection curl makes is verified to
              The  server  connection  is verified by making sure the server's
              interface name, IP address or host name.

Sie können Ihren Cluster auf viele Arten sichern, aber es hängt vom Szenario ab. Es gibt jedoch einige HauptAPI-Server-Ports und IPsKonzepte:

Verwenden Sie SecurePort

Standardmäßig bedient der Kubernetes-API-Server HTTPzwei Ports:

  1. localhost port:
  • ist für Tests und Bootstrap vorgesehen, sowie für die Kommunikation anderer Komponenten des Masterknotens (Scheduler, Controller-Manager) mit der API
  • kein TLS
  • Deaktivieren Sie unsichere HTTP-Verbindungen: Standard ist Port 8080, ändern Sie ihn mit --insecure-portFlag. (Kann deaktiviert werden durch --insecure-port=0)
  • Standard-IP ist localhost, mit Flag ändern --insecure-bind-address. (Entfernen --insecure-bind-address)
  • Anfrage umgeht Authentifizierungs- und Autorisierungsmodule.
  • Anforderung, die von Zulassungskontrollmodul(en) bearbeitet wird.
  • geschützt durch die Notwendigkeit des Host-Zugriffs
  1. Secure port:
  • wenn möglich verwenden Sicheren Port aktivieren:
  • verwendet TLS. Setzen Sie das Zertifikat mit --tls-cert-fileund den Schlüssel mit --tls-private-key-fileder Flagge.
  • Standard ist Port 6443, ändern Sie es mit -secure-port-Flag.
  • Die Standard-IP ist die erste non-localhostNetzwerkschnittstelle. Ändern Sie sie mit --bind-addressFlag.
  • Anfragen werden von Authentifizierungs- und Autorisierungsmodulen bearbeitet.
  • Anforderung, die von Zulassungskontrollmodul(en) bearbeitet wird.
  • Es werden Authentifizierungs- und Autorisierungsmodule ausgeführt.

API-Zugriff einschränken, was bedeutet, dass Sie den Zugriff auf Ihre API nur von einer bestimmten IP-Adresse oder einem bestimmten IP-Bereich (autorisierte Netzwerke) aus zulassen sollten. Sie sollte nicht von außerhalb der Welt zugänglich sein. Dazu können Sie Firewall-Regeln verwenden oderNetzwerkrichtlinie.

AbschaltenAnonyme Anfragen, was Sie bereits getan haben.

Sie können sich das ansehen --insecure-port=0, es sollte jedoch in neueren Versionen veraltet sein.

Als zusätzliche Information empfehle ich Ihnen,Kubernetes auf die harte Tour, insbesondere 3 Kapitel: Provisioning Compute Resources, Provisioning the CA and Generating TLS Certificates, Generating Kubernetes Configuration Files for Authentication. Dort finden Sie einige Best Practices.

Sehr gute Erklärung der Kube API-serverFlaggen finden Sie inDieser Artikel

Nützliche Links zur Clustersicherheit:

Grundlagen zur Absicherung von Kubernetes-Clustern - So sichern Sie den Kube-API-Server

Steuern des Zugriffs auf die Kubernetes-API

Bewährte Methoden für die Kubernetes-Sicherheit

Kubernetes-Sicherheit 101: Risiken und 29 Best Practices

Steuern des Zugriffs auf die Kubernetes-API

Auf Cluster zugreifen

verwandte Informationen