Mempelajari Panduan Dasar Kubernetes

Konsep

Kubernetes v1.14 dokumentasi sudah tidak dirawat lagi. Versi yang kamu lihat ini hanyalah snapshot statis. Untuk dokumentasi terkini, lihat versi terkini.

Edit This Page

Komunikasi Master-Node

Dokumen ini menjelaskan tentang jalur-jalur komunikasi di antara kluster Kubernetes dan master yang sebenarnya hanya berhubungan dengan apiserver saja. Kenapa ada dokumen ini? Supaya kamu, para pengguna Kubernetes, punya gambaran bagaimana mengatur instalasi untuk memperketat konfigurasi jaringan di dalam kluster. Hal ini cukup penting, karena kluster bisa saja berjalan pada jaringan tak terpercaya (untrusted network), ataupun melalui alamat-alamat IP publik pada penyedia cloud.

Kluster menuju Master

Semua jalur komunikasi dari kluster menuju master diterminasi pada apiserver. Tidak ada komponen apapun di dalam master, selain apiserver, yang terekspos ke luar untuk diakses dari servis remote. Untuk instalasi kluster pada umumnya, apiserver diatur untuk listen ke koneksi remote melalui port HTTPS (443) yang aman, dengan satu atau beberapa metode autentikasi client yang telah terpasang. Sebaiknya, satu atau beberapa metode otorisasi juga dipasang, terutama jika kamu memperbolehkan permintaan anonim (anonymous request) ataupun service account token.

Node-node seharusnya disediakan dengan public root certificate untuk kluster, sehingga node-node tersebut bisa terhubung secara aman ke apiserver dengan kredensial client yang valid. Contohnya, untuk instalasi GKE dengan standar konfigurasi, kredensial client harus diberikan kepada kubelet dalam bentuk client certificate. Lihat menghidupkan TLS kubelet untuk menyediakan client certificate untuk kubelet secara otomatis.

Jika diperlukan, pod-pod dapat terhubung pada apiserver secara aman dengan menggunakan service account. Dengan ini, Kubernetes memasukkan public root certificate dan bearer token yang valid ke dalam pod, secara otomatis saat pod mulai dijalankan. Kubernetes service (di dalam semua namespace) diatur dengan sebuah alamat IP virtual. Semua yang mengakses alamat IP ini akan dialihkan (melalui kube-proxy) menuju endpoint HTTPS dari apiserver.

Komponen-komponen master juga berkomunikasi dengan apiserver melalui port yang aman di dalam kluster. Akibatnya, untuk konfigurasi yang umum dan standar, semua koneksi dari kluster (node-node dan pod-pod yang berjalan di atas node tersebut) menuju master sudah terhubung dengan aman. Dan juga, kluster dan master bisa terhubung melalui jaringan publik dan/atau yang tak terpercaya (untrusted).

Master menuju Kluster

Ada dua jalur komunikasi utama dari master (apiserver) menuju kluster. Pertama, dari apiserver ke process kubelet yang berjalan pada setiap node di dalam kluster. Kedua, dari apiserver ke setiap node, pod, ataupun service melalui fungsi proxy pada apiserver.

Apiserver menuju kubelet

Koneksi dari apiserver menuju kubelet bertujuan untuk:

Semua koneksi ini diterminasi pada endpoint HTTPS dari kubelet. Secara default, apiserver tidak melakukan verifikasi serving certificate dari kubelet, yang membuat koneksi terekspos pada serangan man-in-the-middle, dan juga tidak aman untuk terhubung melalui jaringan tak terpercaya (untrusted) dan/atau publik.

Untuk melakukan verifikasi koneksi ini, berikan root certificate pada apiserver melalui tanda --kubelet-certificate-authority, sehingga apiserver dapat memverifikasi serving certificate dari kubelet.

Cara lainnya, gunakan tunnel SSH antara apiserver dan kubelet jika diperlukan, untuk menghindari komunikasi melalui jaringan tak terpercaya (untrusted) atau publik.

Terakhir, yang terpenting, aktifkan autentikasi dan/atau otorisasi Kubelet untuk mengamankan API kubelet.

Apiserver menuju Node, Pod, dan Service

Secara default, koneksi apiserver menuju node, pod atau service hanyalah melalui HTTP polos (plain), sehingga tidak ada autentikasi maupun enkripsi. Koneksi tersebut bisa diamankan melalui HTTPS dengan menambahkan https: pada URL API dengan nama dari node, pod, atau service. Namun, koneksi tidak tervalidasi dengan certificate yang disediakan oleh endpoint HTTPS maupun kredensial client, sehingga walaupun koneksi sudah terenkripsi, tidak ada yang menjamin integritasnya. Koneksi ini tidak aman untuk dilalui pada jaringan publik dan/atau tak terpercaya untrusted.

Tunnel SSH

Kubernetes menyediakan tunnel SSH untuk mengamankan jalur komunikasi Master -> Kluster. Dengan ini, apiserver menginisiasi sebuah tunnel SSH untuk setiap node di dalam kluster (terhubung ke server SSH di port 22) dan membuat semua trafik menuju kubelet, node, pod, atau service dilewatkan melalui tunnel tesebut. Tunnel ini memastikan trafik tidak terekspos keluar jaringan dimana node-node berada.

Tunnel SSH saat ini sudah usang (deprecated), jadi sebaiknya jangan digunakan, kecuali kamu tahu pasti apa yang kamu lakukan. Sebuah desain baru untuk mengganti kanal komunikasi ini sedang disiapkan.

Masukan