Verwenden von Vault als Zertifizierungsstelle für Kubernetes

Das Delivery-Team von DigitalOcean hat die Aufgabe, den Versand interner Services schnell und einfach zu gestalten. Im Dezember 2015 haben wir uns daran gemacht, eine auf Kubernetes aufbauende Plattform zu entwerfen und zu implementieren. Wir wollten von Anfang an die Best Practices für die Sicherung unseres Clusters befolgen, einschließlich der Aktivierung der gegenseitigen TLS-Authentifizierung zwischen allen etcd- und Kubernetes-Komponenten.

Dies ist jedoch leichter gesagt als getan. DigitalOcean verfügt derzeit über 12 Rechenzentren auf 3 Kontinenten. Wir mussten in jedem Rechenzentrum mindestens einen Kubernetes-Cluster bereitstellen, aber das Einrichten der Zertifikate auch nur für einen einzelnen Kubernetes-Cluster ist ein bedeutendes Unterfangen, ganz zu schweigen von der Erneuerung und dem Widerruf von Zertifikaten für jedes Rechenzentrum.

Bevor wir also mit der Erweiterung der Anzahl der Cluster begannen, haben wir uns daran gemacht, das gesamte Zertifikatsmanagement mithilfe von Hashicorps Vault zu automatisieren. In diesem Beitrag besprechen wir die Details, wie wir unsere Zertifizierungsstelle (CA) entworfen und implementiert haben.

Planung
Wir fanden es hilfreich, alle Kommunikationswege zu betrachten, bevor wir die Struktur unserer Zertifizierungsstelle entwerfen.

Alle Kubernetes-Operationen fließen durch den kube-apiserver und bleiben im etcd-Datenspeicher erhalten. etcd-Knoten sollten nur die Kommunikation von ihren Peers und dem API-Server akzeptieren. Die Kubelets oder andere Clients dürfen nicht direkt mit etcd kommunizieren können. Andernfalls könnten die Zugriffskontrollen des kube-apiservers umgangen werden. Wir müssen auch sicherstellen, dass Verbraucher der Kubernetes-API eine Identität (ein Client-Zertifikat) erhalten, um sich bei kube-apiserver zu authentifizieren.

Mit diesen Informationen haben wir uns entschieden, zwei Zertifizierungsstellen pro Cluster zu erstellen. Das erste würde verwendet werden, um etcd-bezogene Zertifikate auszustellen (die jedem etcd-Knoten und dem kube-apiserver gegeben werden). Die zweite Zertifizierungsstelle wäre für Kubernetes, die dem kube-apiserver und den anderen Kubernetes-Komponenten ihre Zertifikate ausstellt. Das obige Diagramm zeigt die Kommunikation, die die etcd CA in gestrichelten Linien und die Kubernetes CA in durchgezogenen Linien verwendet.

Nachdem das Design fertiggestellt war, konnten wir mit der Umsetzung fortfahren. Zuerst haben wir die CAs erstellt und die Rollen konfiguriert, um Zertifikate auszustellen. Anschließend haben wir Tresorrichtlinien konfiguriert, um den Zugriff auf CA-Rollen zu steuern, und Authentifizierungstoken mit den erforderlichen Richtlinien erstellt. Schließlich haben wir die Token verwendet, um die Zertifikate für jeden Dienst abzurufen.

Leave a Reply

Your email address will not be published.