Komunikacja w klastrze między komponentami z użyciem SSL/TLS¶

Cała komunikacja w klastrze odbywa się z wykorzystaniem kluczy SSL, które rozróżniane są jako certyfikaty: - Server Certificates - Client Certificates

W klastrze konieczne posiadanie jest chociaż jednego urzędu certyfikującego CA, którego zadaniem jest weryfikacja certyfikatów.

Server Certificates¶

Są to certyfikaty wygenerowane dla takich komponentów jak: - kube-apiserver - do komunikacji ze wszystkimi komponentami klastra - etcd server - do komunikacji jedynie z kube-apiserver - kubelet server - do komunikacji z kube-apiserver (on się łączy do kubeleta)

Client Certificates¶

Certyfikaty generowane z poziomu klientów do zweryfikowania, czy oni mogą mieć dostęp do klastra. Są to takie certyfikaty jak: - Admin cert - certyfikat dla administratorów do komunikacji z klastrem - potrzebny do komunikacji z kube-apiserverem z użyciem REST API - kube-scheduler - do komunikacji z api-serverem do sprawdzania Podów, które mają być uruchomione i rozdysponowane - kubecontroller-manager - komunikacja z kube-apiserverem - kube-proxy - również do komunikacji z kube-apiserverem - kube-apiserver - do komunikacji z etcd (jako jedyny się komunikuje z nim), może używać te same, co wcześniej wygenerowane, lub utworzyć nowe, specjalnie do komunikacji z etcd - kube-apiserver - do komunikacji z kubelet, z ich użyciem łączy się z kubeletami w klastrze

Certificate Authority (CA)¶

Jest to jednostka służąca do weryfikacji, czy utworzone certyfikaty są poprawne, czy zostały utworzone przez zweryfikowaną instytucję.

W klastrze konieczne jest posiadanie chociaż jednej takiej jednostki. Możemy także utworzyć dwie: dla klastra oraz dla etcd.