Bagian dokumentasi Kubernetes ini memiliki tujuan untuk membantu anda
menjalankan workloads lebih aman, dan aspek-aspek mendasar dalam menjaga
klaster Kubernetes tetap aman.
Kubernetes berbasiskan arsitektur cloud-native dan mengambil saran dari
CNCF mengenai praktik yang baik dari cloud native information security.
Baca Cloud Native Security and Kubernetes
untuk konteks yang lebih luas mengenai bagaimana cara mengamankan klaster anda
dan aplikasi yang berjalan di atasnya.
Kubernetes menyarankan anda untuk mengkonfigurasi dan menggunakan TLS dalam menyediakan
enkripsi data saat transit
di dalam control plane, dan di antara control plane dengan client.
Anda juga bisa mengaktifkan encryption at rest
untuk data yang tersimpan di dalam Kubernetes control plane; hal ini terpisah dari
menggunanakan encryption at rest untuk data anda di workload.
Secrets
Secret API menyediakan perlindungan dasar untuk variabel konfigurasi yang konfidensial.
Perlindungan Workload
Terapkan Pod security standards untuk memastikan Pods dan containers terisolasi dengan baik.
Anda juga dapat menggunakan RuntimeClasses untuk mendefinisikan isolasi custom jika dibutuhkan.
Network policies memungkinkan anda mengendalikan
trafik jaringan di antara Pods, atau antara Pods dengan jaringan di luar klaster.
Anda dapat men-deploy security controls dari ekosistem yang lebih besar untuk mengimplementasikan kontrol pencegahan
atau pendeteksian di sekitar Pods, kontainer dan images yang berjalan.
Audit
Kubernetes audit logging menyediakan
sebuah set catatan yang berurutan terkait dengan keamanan, mendokumentasikan
urutan aktivitas dalam suatu cluster. Aktivitas cluster audit dihasilkan
oleh pengguna, aplikasi yang menggunakan Kubernetes API dan control plane.
Keamanan penyedia cloud
Catatan: Items on this page refer to vendors external to Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. To add a vendor, product or project to this list, read the content guide before submitting a change. More information.
Jika anda menjalankan klaster Kubernetes pada perangkat keras anda sendiri atau
pada penyedia layanan komputasi awan, silakan kunjungi halaman dokumentasi untuk melihat saran/tips dalam keamanan.
Berikut ini beberapa tautan ke halaman dokumentasi keamanan dari beberapa
penyedia jasa komputasi awan:
Anda dapat mendefinisikan security policies menggunakan mekanisme Kubernetes-native seperti NetworkPolicy (kontrol deklaratif atas network packet filtering) atau ValidatingAdmissionPolicy
(larangan deklaratif atas perubahan apa yang bisa dibuat seseorang menggunakan Kubernetes API).
Bagaimanapun juga, anda dapat mengandalkan dari implementasi policy dari
ekosistem yang lebih besar di sekitar Kubernetes. Kubernetes menyediakan
mekanisme ekstensi untuk membiarkan ekosistem proyek tersebut mengimplementasikan
policy controls mereka pada peninjauan kode sumber, persetujuan image container,
akses kontrol API, jaringan dan lain-lain.
Untuk informasi lebih lanjut mengenai mekanisme policy dan Kubernetes, silakan
baca Policies.
Selanjutnya
Pelajari lebih lanjut topik terkait keamanan Kubernetes:
Keamanan Kubernetes (dan keamanan secara umum) adalah sebuah topik sangat luas yang memiliki banyak bagian yang sangat berkaitan satu sama lain. Pada masa sekarang ini di mana perangkat lunak open source telah diintegrasi ke dalam banyak sistem yang membantu berjalannya aplikasi web, ada beberapa konsep menyeluruh yang dapat membantu intuisimu untuk berpikir tentang konsep keamanan secara menyeluruh. Panduan ini akan mendefinisikan sebuah cara/model berpikir untuk beberapa konsep umum mengenai Keamanan Cloud Native. Cara berpikir ini sepenuhnya subjektif dan kamu sebaiknya hanya menggunakannya apabila ini membantumu berpikir tentang di mana harus mengamankan stack perangkat lunakmu.
4C pada Keamanan Cloud Native
Mari memulainya dengan sebuah diagram yang dapat membantumu mengerti bagaimana berpikir tentang keamanan dalam bentuk beberapa lapisan.
Catatan:
Pendekatan berlapis ini memperkuat pendekatan defense in depth terhadap keamanan, yang secara luas dianggap sebagai praktik terbaik untuk mengamankan sistem-sistem perangkat lunak. 4C tersebut adalah Cloud, Cluster, Container, dan Code.
The 4C's of Cloud Native Security
Seperti yang dapat kamu lihat dari gambar di atas, setiap dari 4C tersebut bergantung pada keamanan dari kotak yang lebih besar di mana mereka berada. Hampir tidak mungkin untuk mengamankan sistem terhadap standar-standar keamanan yang buruk pada Cloud, Container, dan Code hanya dengan menangani keamanan pada lapisan kode. Akan tetapi, apabila semua area tersebut ditangani dengan baik, maka menambahkan keamanan ke dalam kode kamu akan memperkuat landasan yang sudah kuat. Area-area yang menjadi perhatian ini akan dideskripsikan lebih mendalam di bawah.
Cloud
Dalam banyak hal, Cloud (atau server-server co-located, atau pusat data/data center korporat) adalah trusted computing base (basis komputasi yang dipercaya) dari sebuah klaster Kubernetes. Jika komponen-komponen tersebut rentan secara keamanan (atau dikonfigurasi dengan cara yang rentan), maka sesungguhnya tidak ada cara untuk menjamin keamanan dari komponen-komponen apa pun yang dibangun di atas basis komputasi ini. Memberikan rekomendasi untuk keamanan cloud berada di luar lingkup panduan ini, karena setiap penyedia layanan cloud dan beban kerja pada dasarnya berbeda-beda. Berikut beberapa tautan menuju beberapa dokumentasi penyedia layanan cloud yang populer untuk keamanan maupun untuk memberikan panduan umum untuk mengamankan infrastruktur yang menjadi basis sebuah klaster Kubernetes.
Jika kamu mengoperasikan perangkat keras kamu sendiri, atau penyedia layanan cloud yang berbeda, kamu perlu merujuk pada dokumentasi penyedia layanan cloud yang kamu pakai untuk praktik keamanan terbaik.
Tabel Panduan Umum Infrastruktur
Area yang Menjadi Perhatian untuk Infrastruktur Kubernetes
Rekomendasi
Akses Jaringan terhadap API Server (Master-master)
Secara Ideal, semua akses terhadap Master-master Kubernetes tidak diizinkan secara publik pada internet, dan dikontrol oleh daftar kendali akses (network ACL) yang dibatasi untuk kumpulan alamat IP yang dibutuhkan untuk mengelola klaster.
Akses Jaringan terhadap Node-node (Server-server Worker)
Node-node harus dikonfigurasikan untuk hanya menerima koneksi-koneksi (melalui daftar kendali akses) dari Master-master pada porta-porta (port) yang telah ditentukan, dan menerima koneksi-koneksi dari Service-service Kubernetes dengan tipe NodePort dan LoadBalancer. Apabila memungkinkan, Node-node tersebut sebaiknya tidak diekspos pada internet publik sama sekali.
Akses Kubernetes terhadap API Penyedia Layanan Cloud
Akses terhadap etcd (tempat penyimpanan data Kubernetes) harus dibatasi hanya untuk Master-master saja. Bergantung pada konfigurasimu, kamu sebaiknya juga mengusahakan koneksi etcd menggunakan TLS. Informasi lebih lanjut dapat ditemukan di sini: https://github.com/etcd-io/etcd/tree/master/Documentation#security
Enkripsi etcd
Di mana pun kita dapat melakukannya, mengenkripsi semua data saat diam (at rest) pada semua drive, dan sejak etcd menyimpan keadaan seluruh klaster (termasuk Secret-secret), disk-nya sebaiknya kita enkripsi saat diam.
Cluster
Bagian ini akan memberikan tautan-tautan untuk mengamankan beban-beban kerja di dalam Kubernetes. Ada dua area yang menjadi perhatian untuk mengamankan Kubernetes:
Mengamankan komponen-komponen yang dapat dikonfigurasi yang membentuk klaster
Mengamankan komponen-komponen yang dijalankan di dalam klaster
Komponen-komponen dari Cluster
Jika kamu ingin menjaga klastermu dari akses yang tidak disengaja atau yang bersifat serangan, dan mengadopsi praktik yang baik, baca dan ikutilah nasihat untuk mengamankan klastermu.
Komponen-komponen di dalam Cluster (aplikasimu)
Bergantung pada permukaan yang dapat diserang dari aplikasimu, kamu mungkin ingin berfokus pada aspek keamanan yang spesifik. Sebagai contoh, jika kamu menjalankan sebuah layanan (kita sebut Layanan A) yang kritikal di dalam rantai sumber daya lainnya dan sebuah beban kerja terpisah (kita sebut Layanan B) yang rentan terhadap serangan resource exhaustion, dengan tidak menyetel limit untuk sumber daya maka kamu juga menaruh risiko terhadap Layanan A. Berikut tabel tautan-tautan menuju hal-hal yang perlu diperhatikan untuk mengamankan beban-beban kerja yang berjalan di dalam Kubernetes.
Area yang Menjadi Perhatian untuk Keamanan Beban Kerja
Untuk menjalankan perangkat lunak di dalam Kubernetes, perangkat lunak tersebut haruslah berada di dalam sebuah Container. Karenanya, ada beberapa pertimbangan keamanan yang harus diperhitungkan untuk mengambil manfaat dari fitur-fitur keamanan beban kerja Kubernetes. Keamanan Container berada di luar lingkup panduan ini, tetapi berikut disediakan sebuah tabel rekomendasi-rekomendasi umum dan tautan menuju eksplorasi lebih dalam pada topik ini.
Area yang Menjadi Perhatian untuk Container
Rekomendasi
Pemindaian Kerentanan Container dan Dependensi Keamanan OS
Sebagai bagian dari tahap membangun sebuah image atau dilakukan secara teratur, kamu sebaiknya memindai Container-container terhadap kerentanan yang telah diketahui dengan peralatan seperti CoreOS's Clair
Penandatanganan Image dan Penegakan Aturan
Dua dari Proyek-proyek CNCF (TUF dan Notary) adalah alat-alat yang berguna untuk menandatangani image Container dan memelihara sistem kepercayaan untuk konten dari Container-container kamu. Jika kamu menggunakan Docker, ia dibangun di dalam Docker Engine sebagai Docker Content Trust. Pada bagian penegakan aturan, proyek Portieris dari IBM adalah sebuah alat yang berjalan sebagai sebuah Dynamic Admission Controller Kubernetes untuk memastikan bahwa image-image ditandatangani dengan tepat oleh Notary sebelum dimasukkan ke dalam Cluster.
Larang pengguna-pengguna dengan hak istimewa
Saat membangun Container-container, rujuklah dokumentasimu untuk cara membuat pengguna-pengguna di dalam Container-container yang memiliki hak istimewa sistem operasi yang paling sedikit yang dibutuhkan untuk mencapai tujuan Container tersebut.
Code
Akhirnya pada lapisan kode aplikasi, hal ini adalah satu dari permukaan-permukaan serangan utama yang paling dapat kamu kontrol. Hal ini juga berada di luar lingkup Kubernetes, tetapi berikut beberapa rekomendasi:
Tabel Panduan Umum Keamanan Kode
Area yang Menjadi Perhatian untuk Kode
Rekomendasi
Akses hanya melalui TLS
Jika kode kamu perlu berkomunikasi via TCP, idealnya ia melakukan TLS handshake dengan klien sebelumnya. Dengan pengecualian pada sedikit kasus, kelakuan secara bawaan sebaiknya adalah mengenkripsi semuanya (data) pada saat transit (encryption at transit). Lebih jauh lagi, bahkan "di belakang dinding api" di dalam VPC kita sebaiknya kita melakukan enkripsi lalu lintas jaringan di antara layanan-layanan. Hal ini dapat dilakukan melalui sebuah proses yang dikenal dengan mutual TLS atau mTLS yang melakukan verifikasi dua sisi terhadap komunikasi antara layanan-layanan yang memiliki sertifikat digital. Ada banyak alat-alat yang dapat digunakan untuk mencapai hal ini, seperti Linkerd dan Istio.
Membatasi cakupan porta komunikasi
Rekomendasi ini sepertinya cukup jelas, tetapi di mana pun dapat dilakukan sebaiknya kamu hanya membuka porta-porta pada layananmu yang benar-benar diperlukan untuk komunikasi sistem atau pengambilan metrik.
Keamanan Dependensi Pihak ke-3
Karena aplikasi-aplikasi kita cenderung memiliki dependensi-dependensi di luar kode kita sendiri, merupakan praktik yang baik untuk memastikan hasil pemindaian rutin dependensi-dependensi kode kita masih aman tanpa CVE yang masih ada terhadap mereka. Setiap bahasa pemrograman memiliki alat untuk melakukan pemindaian ini secara otomatis.
Analisis Statis Kode
Kebanyakan bahasa pemrograman menyediakan cara agar potongan kode dapat dianalisis terhadap praktik-praktik penulisan kode yang berpotensi tidak aman. Kapan pun dapat dilakukan, kamu sebaiknya melakukan pemeriksaan menggunakan peralatan otomatis yang dapat memindai kode terhadap kesalahan keamanan yang umum terjadi. Beberapa dari peralatan tersebut dapat ditemukan di sini: https://www.owasp.org/index.php/Source_Code_Analysis_Tools
Serangan Pengamatan (probing) Dinamis
Ada sedikit peralatan otomatis yang dapat dijalankan terhadap layanan/aplikasi kamu untuk mencoba beberapa serangan yang terkenal dan umumnya memengaruhi layanan-layanan. Serangan-serangan tersebut termasuk SQL injection, CSRF, dan XSS. Satu dari alat analisis dinamis yang terkenal adalah OWASP Zed Attack Proxy https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Otomasi yang Kokoh
Kebanyakan dari saran yang disebut di atas dapat diotomasi di dalam delivery pipeline kode kamu sebagai bagian dari rangkaian pemeriksaan keamanan. Untuk mempelajari lebih lanjut tentang pendekatan "Continuous Hacking" terhadap delivery perangkat lunak, artikel ini menyediakan lebih banyak detail.
Informasi tentang opsi autentikasi di Kubernetes dan securityproperties -nya.
Memilih mekanisme autentikasi yang tepat adalah aspek penting dalam mengamankan klaster Anda.
Kubernetes menyediakan beberapa mekanisme bawaan, masing-masing dengan kelebihan dan kekurangannya
yang harus dipertimbangkan dengan hati-hati saat memilih mekanisme autentikasi terbaik untuk klaster Anda.
Secara umum, disarankan untuk mengaktifkan sesedikit mungkin mekanisme autentikasi untuk menyederhanakan
manajemen pengguna dan mencegah kasus di mana pengguna tetap memiliki akses ke klaster yang tidak lagi diperlukan.
Penting untuk dicatat bahwa Kubernetes tidak memiliki basis data pengguna bawaan di dalam klaster.
Sebaliknya, Kubernetes mengambil informasi pengguna dari sistem autentikasi yang dikonfigurasi dan menggunakan
informasi tersebut untuk membuat keputusan otorisasi. Oleh karena itu, untuk mengaudit akses pengguna, Anda perlu
meninjau kredensial dari setiap sumber autentikasi yang dikonfigurasi.
Untuk klaster produksi dengan banyak pengguna yang mengakses API Kubernetes secara langsung, disarankan untuk
menggunakan sumber autentikasi eksternal seperti OIDC. Mekanisme autentikasi internal, seperti sertifikat klien
dan token akun layanan yang dijelaskan di bawah ini, tidak cocok untuk kasus penggunaan ini.
Autentikasi sertifikat klien X.509
Kubernetes memanfaatkan sertifikat klien X.509
untuk komponen sistem, seperti saat kubelet mengautentikasi ke API Server. Meskipun mekanisme ini juga dapat digunakan
untuk autentikasi pengguna, mekanisme ini mungkin tidak cocok untuk penggunaan produksi karena beberapa batasan:
Sertifikat klien tidak dapat dicabut secara individual. Setelah disusupi, sertifikat dapat digunakan oleh penyerang
hingga kedaluwarsa. Untuk mengurangi risiko ini, disarankan untuk mengonfigurasi masa berlaku yang pendek untuk
kredensial autentikasi pengguna yang dibuat menggunakan sertifikat klien.
Jika sertifikat perlu dibatalkan, otoritas sertifikat harus diubah kuncinya, yang dapat memperkenalkan risiko
ketersediaan ke klaster.
Tidak ada catatan permanen tentang sertifikat klien yang dibuat di klaster. Oleh karena itu, semua sertifikat yang
diterbitkan harus dicatat jika Anda perlu melacaknya.
Kunci privat yang digunakan untuk autentikasi sertifikat klien tidak dapat dilindungi dengan kata sandi. Siapa pun
yang dapat membaca file yang berisi kunci tersebut akan dapat menggunakannya.
Menggunakan autentikasi sertifikat klien memerlukan koneksi langsung dari klien ke API server tanpa titik
terminasi TLS yang mengintervensi, yang dapat mempersulit arsitektur jaringan.
Data grup tertanam dalam nilai O dari sertifikat klien, yang berarti keanggotaan grup pengguna tidak dapat diubah
selama masa berlaku sertifikat.
File token statis
Meskipun Kubernetes memungkinkan Anda memuat kredensial dari
berkas token statis yang terletak
di disk node control plane, pendekatan ini tidak disarankan untuk server produksi karena beberapa alasan:
Kredensial disimpan dalam teks biasa di disk node control plane, yang dapat menjadi risiko keamanan.
Mengubah kredensial apa pun memerlukan restart proses API server agar berlaku, yang dapat memengaruhi ketersediaan.
Tidak ada mekanisme yang tersedia untuk memungkinkan pengguna memutar kredensial mereka. Untuk memutar kredensial,
administrator klaster harus memodifikasi token di disk dan mendistribusikannya ke pengguna.
Tidak ada mekanisme penguncian yang tersedia untuk mencegah serangan brute-force.
Token bootstrap
Token bootstrap digunakan untuk menghubungkan
node ke klaster dan tidak disarankan untuk autentikasi pengguna karena beberapa alasan:
Mereka memiliki keanggotaan grup yang dikodekan keras yang tidak cocok untuk penggunaan umum, sehingga tidak cocok
untuk tujuan autentikasi.
Pembuatan token bootstrap secara manual dapat menghasilkan token yang lemah yang dapat ditebak oleh penyerang,
yang dapat menjadi risiko keamanan.
Tidak ada mekanisme penguncian yang tersedia untuk mencegah serangan brute-force, sehingga memudahkan penyerang
untuk menebak atau memecahkan token.
Token rahasia ServiceAccount
Rahasia akun layanan
tersedia sebagai opsi untuk memungkinkan beban kerja yang berjalan di klaster mengautentikasi ke API server.
Di Kubernetes < 1.23, ini adalah opsi default, namun, mereka sedang digantikan dengan token API TokenRequest.
Meskipun rahasia ini dapat digunakan untuk autentikasi pengguna, mereka umumnya tidak cocok karena beberapa alasan:
Mereka tidak dapat diatur dengan masa berlaku dan akan tetap berlaku hingga akun layanan terkait dihapus.
Token autentikasi terlihat oleh pengguna klaster mana pun yang dapat membaca rahasia di namespace tempat mereka
didefinisikan.
Akun layanan tidak dapat ditambahkan ke grup arbitrer, yang mempersulit manajemen RBAC di mana mereka digunakan.
Token API TokenRequest
API TokenRequest adalah alat yang berguna untuk menghasilkan kredensial jangka pendek untuk autentikasi layanan
ke API server atau sistem pihak ketiga. Namun, ini umumnya tidak disarankan untuk autentikasi pengguna karena tidak
ada metode pencabutan yang tersedia, dan mendistribusikan kredensial ke pengguna dengan cara yang aman dapat menjadi
tantangan.
Saat menggunakan token TokenRequest untuk autentikasi layanan, disarankan untuk menerapkan masa berlaku yang pendek
untuk mengurangi dampak token yang disusupi.
Autentikasi token OpenID Connect
Kubernetes mendukung integrasi layanan autentikasi eksternal dengan API Kubernetes menggunakan
OpenID Connect (OIDC).
Ada berbagai macam perangkat lunak yang dapat digunakan untuk mengintegrasikan Kubernetes dengan penyedia identitas.
Namun, saat menggunakan autentikasi OIDC di Kubernetes, penting untuk mempertimbangkan langkah-langkah penguatan berikut:
Perangkat lunak yang diinstal di klaster untuk mendukung autentikasi OIDC harus diisolasi dari beban kerja umum
karena akan berjalan dengan hak istimewa tinggi.
Beberapa layanan Kubernetes yang dikelola memiliki batasan pada penyedia OIDC yang dapat digunakan.
Seperti halnya token TokenRequest, token OIDC harus memiliki masa berlaku yang pendek untuk mengurangi dampak
token yang disusupi.
Autentikasi token Webhook
Autentikasi token Webhook
adalah opsi lain untuk mengintegrasikan penyedia autentikasi eksternal ke Kubernetes. Mekanisme ini memungkinkan
layanan autentikasi, baik yang berjalan di dalam klaster atau di luar, untuk dihubungi untuk keputusan autentikasi
melalui webhook. Penting untuk dicatat bahwa kesesuaian mekanisme ini kemungkinan besar bergantung pada perangkat
lunak yang digunakan untuk layanan autentikasi, dan ada beberapa pertimbangan khusus Kubernetes yang harus diperhatikan.
Untuk mengonfigurasi autentikasi Webhook, akses ke sistem file server control plane diperlukan. Ini berarti bahwa
hal ini tidak akan memungkinkan dengan Kubernetes yang dikelola kecuali penyedia secara khusus membuatnya tersedia.
Selain itu, perangkat lunak apa pun yang diinstal di klaster untuk mendukung akses ini harus diisolasi dari beban
kerja umum, karena akan berjalan dengan hak istimewa tinggi.
Proxy autentikasi
Opsi lain untuk mengintegrasikan sistem autentikasi eksternal ke Kubernetes adalah dengan menggunakan
proxy autentikasi.
Dengan mekanisme ini, Kubernetes mengharapkan menerima permintaan dari proxy dengan nilai header tertentu yang
ditetapkan, menunjukkan nama pengguna dan keanggotaan grup untuk tujuan otorisasi. Penting untuk dicatat bahwa ada
pertimbangan khusus yang harus diperhatikan saat menggunakan mekanisme ini.
Pertama, TLS yang dikonfigurasi dengan aman harus digunakan antara proxy dan API server Kubernetes untuk mengurangi
risiko serangan penyadapan atau pengintaian lalu lintas. Ini memastikan bahwa komunikasi antara proxy dan API server
Kubernetes aman.
Kedua, penting untuk menyadari bahwa penyerang yang dapat memodifikasi header permintaan mungkin dapat memperoleh
akses tidak sah ke sumber daya Kubernetes. Oleh karena itu, penting untuk memastikan bahwa header diamankan dengan
baik dan tidak dapat dirusak.
[Autentikasi dengan Token Akun Layanan](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-accounfor kens)
3 - Daftar Periksa Keamanan
Daftar periksa dasar untuk memastikan keamanan di klaster Kubernetes.
Daftar ini bertujuan memberikan daftar dasar panduan dengan tautan ke
dokumentasi yang lebih lengkap pada setiap topiknya. Daftar ini tidak
berarti sudah final dan masih bisa berubah.
Bagaimana cara membaca dan menggunakan dokumen ini:
Urutan dari topik tidak mencerminkan prioritas
Beberapa daftar, dirincikan dalam paragraf di bawahnya pada setiap bagian.
Perhatian:
Daftar periksa sendiri tidak cukup untuk mendapatkan postur keamanan yang baik.
Postur keamanan yang baik membutuhkan usaha yang terus menerus, dan daftar periksa
bisa menjadi langkah pertama dalam perjalanan panjang dalam keamanan.
Beberapa rekomendasi dalam daftar periksa ini bisa jadi terlalu ketat atau
terlalu longgar untuk kebutuhan spesifik keamanan kamu.
Karena keamanan Kubernetes bukan lah "sama untuk semua", setiap kategori dalam daftar,
harus dievaluasi berdasarkan untung/rugi-nya.
Authentication & Authorization
Autentikasi dan Autorisasi
system:masters group tidak digunakan untuk pengguna atau komponen otentikasi setelah bootstrapping.
kube-controller-manager dijalankan dengan --use-service-account-credentials
aktif.
Sertifikat root terlindungi (baik dengan offline CA, atau online CA dengan akses kontrol yang efektif).
Sertifikat intermediate dan leaf memiliki masa berlaku tidak lebih dari
3 tahun ke depan.
Terdapat sebuah proses untuk me-review akses periodik dan review dilakukan
tidak lebih dari 24 bulan.
Setelah bootstrapping, baik pengguna ataupun komponen harusnya tidak melakukan
otentikasi ke Kubernetes API sebagai system:masters. Mirip dengan, menjalankan
semua kube-controller-manager sebagai system:masters harus dihindari.
Faktanya, system:masters harus digunakan sebagai mekanisme terakhir (pecahkan-kaca), berlawanan dengan pengguna admin.
Keamanan Jaringan
Gunakan plugin CNI untuk mendukung kebijakan jaringan.
CNI plugins in use support network policies.
Kebijakan jaringan ingress dan egress diaplikasikan ke semua workload
di dalam klaster.
Terapkan kebijakan default jaringan setiap namespace, periksa semua pod, dan tolak semua.
Jika memungkinkan, sebuah service mesh digunakan untuk mengenkripsi semua komunikasi di dalam klaster.
Kubernetes API, kubelet API dan etcd tidak terekspos ke Internet.
Akses ke workloads ke cloud metadata API di-filter.
Penggunaan LoadBalancer dan ExternalIPs dilarang.
Sejumlah Container Network Interface (CNI) plugins
menyediakan fungsionalitas untuk membatasi sumber daya jaringan yang
memungkinkan pods berkomunikasi. Hal ini umumnya dilakukan melalui
Network Policies
yang menyediakan sumber daya dengan namespace untuk mendefinisikan aturan.
Kebijakan jaringan default yang mem-blok semua egress dan ingress di setiap
namespace, memilih semua pods, dapat bermanfaat untuk mengadopsi pendekatan daftar
diizinkan untuk memastikan tidak ada workloads yang terlewat.
Tidak semua plugin CNI menyediakan enkripsi saat transit. Jika plugin yang dipilih
tidak memiliki fitur ini, solusi alternatif dapat ditawarkan untuk menggunakan
service mesh yang menyediakan fungsionalitas ini.
Datastore etcd dari control plane harus memiliki kontrol untuk membatasi akses
dan tidak terekspos ke Internet. Lebih jauh, mutual TLS (mTLS) harus digunakan
untuk berkomunikasi dengan aman. Certificate authority untuk ini harus unik ke etcd.
Akses Internet eksternal ke server Kubernetes API harus dibatasi untuk tidak
meng-ekspos API ke publik. Harap hati-hati, banyak managed Kubernetes distributions
yang secara default mengekspos API server. Untuk ini, kamu bisa menggunakan bastion host
untuk mengakses server.
Akses API kubelet
harus dibatasi dan tidak terekspos ke publi, setting default autentikasi dan autorisasi,
saat tidak ada berkas konfigurasi di-spesifikasikan dengan flag --config,
sangat permisif.
Jika penyedia cloud digunakan untuk men-host Kubernetes, akses dari pod ke
cloud metadata API 169.254.169.254 harus dibatasi juga atau diblok jika tidak
dibutuhkan karena ada informasi yang bisa bocor.
Hak RBAC untuk create, update, patch, delete workloads hanya diberikan jika diperlukan.
Kebijakan Pod Security Standards yang sesuai diterapkan untuk semua namespace dan ditegakkan.
Batas memori ditetapkan untuk workloads dengan batas yang sama atau lebih rendah dari permintaan.
Batas CPU dapat ditetapkan pada workloads yang sensitif.
Untuk node yang mendukungnya, Seccomp diaktifkan dengan profil syscalls yang sesuai untuk program.
Untuk node yang mendukungnya, AppArmor atau SELinux diaktifkan dengan profil yang sesuai untuk program.
Otorisasi RBAC sangat penting tetapi
tidak cukup granular untuk memiliki otorisasi pada sumber daya Pods
(atau pada sumber daya apa pun yang mengelola Pods). Granularitas hanya ada pada API verbs
pada sumber daya itu sendiri, misalnya, create pada Pods. Tanpa
admission tambahan, otorisasi untuk membuat sumber daya ini memungkinkan akses langsung
tanpa batas ke node yang dapat dijadwalkan dalam klaster.
Pod Security Standards
mendefinisikan tiga kebijakan berbeda, yaitu privileged, baseline, dan restricted yang membatasi
bagaimana field dapat diatur dalam PodSpec terkait keamanan.
Standar ini dapat ditegakkan di tingkat namespace dengan
Pod Security Admission baru,
yang diaktifkan secara default, atau dengan webhook admission pihak ketiga. Harap dicatat bahwa,
berbeda dengan PodSecurityPolicy admission yang dihapus,
Pod Security Admission
dapat dengan mudah digabungkan dengan webhook admission dan layanan eksternal.
Kebijakan restricted pada Pod Security Admission, kebijakan paling ketat dari
Pod Security Standards,
dapat beroperasi dalam beberapa mode,
warn, audit, atau enforce untuk secara bertahap menerapkan
konteks keamanan
yang paling sesuai sesuai dengan praktik terbaik keamanan. Namun demikian,
konteks keamanan
pada pods harus diselidiki secara terpisah untuk membatasi hak istimewa dan akses yang mungkin dimiliki pods
di luar standar keamanan yang telah ditentukan, untuk kasus penggunaan tertentu.
Batas memori dan CPU
harus ditetapkan untuk membatasi sumber daya memori dan CPU yang dapat dikonsumsi pod pada node,
dan dengan demikian mencegah potensi serangan DoS dari workloads yang berbahaya atau
terkompromi. Kebijakan semacam itu dapat ditegakkan oleh admission controller.
Harap dicatat bahwa batas CPU akan membatasi penggunaan dan dengan demikian dapat memiliki efek yang tidak diinginkan
pada fitur auto-scaling atau efisiensi, misalnya menjalankan proses dalam upaya terbaik dengan sumber daya CPU yang tersedia.
Perhatian:
Batas memori yang lebih tinggi dari permintaan dapat mengekspos seluruh node terhadap masalah OOM.
Mengaktifkan Seccomp
Seccomp adalah singkatan dari secure computing mode dan telah menjadi fitur kernel Linux sejak versi 2.6.12.
Fitur ini dapat digunakan untuk membatasi hak istimewa sebuah proses, dengan membatasi panggilan sistem (syscalls)
yang dapat dilakukan dari ruang pengguna (userspace) ke kernel. Kubernetes memungkinkan Anda untuk secara otomatis
menerapkan profil seccomp yang dimuat ke sebuah node ke Pods dan container Anda.
Seccomp dapat meningkatkan keamanan workloads Anda dengan mengurangi permukaan serangan syscall kernel Linux
yang tersedia di dalam container. Mode filter seccomp memanfaatkan BPF untuk membuat daftar izin atau larangan
terhadap syscall tertentu, yang disebut profil.
Sejak Kubernetes 1.27, Anda dapat mengaktifkan penggunaan RuntimeDefault sebagai profil seccomp default
untuk semua workloads. Sebuah tutorial keamanan tersedia untuk topik ini.
Selain itu, Kubernetes Security Profiles Operator
adalah proyek yang memfasilitasi pengelolaan dan penggunaan seccomp di dalam klaster.
Catatan:
Seccomp hanya tersedia pada node Linux.
Mengaktifkan AppArmor atau SELinux
AppArmor
AppArmor adalah modul keamanan kernel Linux yang dapat
menyediakan cara mudah untuk menerapkan Mandatory Access Control (MAC) dan audit yang lebih baik
melalui log sistem. Profil AppArmor default diterapkan pada node yang mendukungnya, atau profil khusus dapat dikonfigurasi.
Seperti seccomp, AppArmor juga dikonfigurasi melalui profil, di mana setiap profil dapat berjalan dalam mode enforcing,
yang memblokir akses ke sumber daya yang tidak diizinkan, atau mode complain, yang hanya melaporkan pelanggaran.
Profil AppArmor diterapkan pada basis per-container, dengan anotasi, memungkinkan proses untuk mendapatkan hak istimewa yang sesuai.
SELinux juga merupakan
modul keamanan kernel Linux yang dapat menyediakan mekanisme untuk mendukung kebijakan kontrol akses,
termasuk Mandatory Access Controls (MAC). Label SELinux dapat diberikan ke container atau pod
melalui bagian securityContext.
Log audit, jika diaktifkan, dilindungi dari akses umum.
Log audit adalah alat penting untuk melacak aktivitas dalam klaster Kubernetes Anda. Jika log audit diaktifkan, pastikan log tersebut hanya dapat diakses oleh pengguna atau sistem yang berwenang. Hal ini membantu mencegah kebocoran informasi sensitif dan memastikan bahwa log dapat digunakan untuk investigasi keamanan tanpa risiko manipulasi atau akses tidak sah.
Penempatan Pod
Penempatan pod dilakukan sesuai dengan tingkat sensitivitas aplikasi.
Aplikasi sensitif dijalankan secara terisolasi pada node atau dengan runtime sandbox tertentu.
Pod yang berada pada tingkat sensitivitas yang berbeda, misalnya pod aplikasi dan server API Kubernetes, sebaiknya diterapkan pada node yang terpisah. Tujuan dari isolasi node adalah untuk mencegah pelarian container aplikasi yang dapat langsung memberikan akses ke aplikasi dengan tingkat sensitivitas yang lebih tinggi, sehingga memudahkan penyerang untuk berpindah dalam klaster. Pemisahan ini harus ditegakkan untuk mencegah pod secara tidak sengaja diterapkan pada node yang sama. Hal ini dapat ditegakkan dengan fitur berikut:
Pasangan key-value, sebagai bagian dari spesifikasi pod, yang menentukan node mana yang akan digunakan untuk penerapan. Ini dapat ditegakkan pada tingkat namespace dan klaster dengan admission controller PodNodeSelector.
Sebuah admission controller yang memungkinkan administrator membatasi toleransi yang diizinkan dalam sebuah namespace. Pod dalam namespace hanya dapat menggunakan toleransi yang ditentukan pada kunci anotasi objek namespace yang menyediakan serangkaian toleransi default dan yang diizinkan.
RuntimeClass adalah fitur untuk memilih konfigurasi runtime container. Konfigurasi runtime container digunakan untuk menjalankan container dalam pod dan dapat memberikan lebih banyak atau lebih sedikit isolasi dari host dengan biaya overhead kinerja.
Secrets
ConfigMap tidak digunakan untuk menyimpan data rahasia.
Enkripsi saat data tidak aktif (encryption at rest) dikonfigurasi untuk API Secret.
Jika sesuai, mekanisme untuk menyuntikkan secrets yang disimpan di penyimpanan pihak ketiga diterapkan dan tersedia.
Token service account tidak dimasukkan ke dalam pod yang tidak membutuhkannya.
Secrets yang diperlukan untuk pod sebaiknya disimpan dalam Kubernetes Secrets, bukan alternatif seperti ConfigMap. Sumber daya Secret yang disimpan dalam etcd harus dienkripsi saat data tidak aktif.
Pod yang membutuhkan secrets sebaiknya memiliki secrets tersebut secara otomatis dimasukkan melalui volume, yang sebaiknya disimpan di memori seperti dengan opsi emptyDir.medium. Mekanisme juga dapat digunakan untuk menyuntikkan secrets dari penyimpanan pihak ketiga sebagai volume, seperti Secrets Store CSI Driver. Hal ini sebaiknya dilakukan sebagai alternatif dibandingkan memberikan pod akses RBAC service account ke secrets. Dengan cara ini, secrets dapat ditambahkan ke pod sebagai variabel lingkungan atau file. Namun, perlu dicatat bahwa metode variabel lingkungan lebih rentan terhadap kebocoran karena core dump dalam log dan sifat variabel lingkungan di Linux yang tidak bersifat rahasia, dibandingkan dengan mekanisme izin pada file.
Token service account tidak boleh dimasukkan ke dalam pod yang tidak membutuhkannya. Hal ini dapat dikonfigurasi dengan mengatur automountServiceAccountToken ke false, baik di dalam service account untuk diterapkan di seluruh namespace atau secara spesifik untuk sebuah pod. Untuk Kubernetes v1.22 dan yang lebih baru, gunakan Bound Service Accounts untuk kredensial service account yang memiliki batas waktu.
Images
Minimalkan konten yang tidak diperlukan dalam container image.
Container image dikonfigurasi untuk dijalankan sebagai pengguna tanpa hak istimewa.
Referensi ke container image dilakukan menggunakan digest sha256 (bukan tag) atau asal-usul image divalidasi dengan memverifikasi tanda tangan digital image saat waktu penerapan melalui admission control.
Container image secara rutin dipindai selama pembuatan dan penerapan, dan perangkat lunak yang rentan diketahui diperbaiki.
Container image sebaiknya hanya berisi konten minimum yang diperlukan untuk menjalankan program yang dikemas. Sebaiknya hanya program dan dependensinya, dengan membangun image dari base image yang seminimal mungkin. Secara khusus, image yang digunakan di lingkungan produksi sebaiknya tidak mengandung shell atau utilitas debugging, karena ephemeral debug container dapat digunakan untuk pemecahan masalah.
Bangun image agar langsung dijalankan dengan pengguna tanpa hak istimewa menggunakan instruksi USER dalam Dockerfile. Security Context memungkinkan container image dijalankan dengan pengguna dan grup tertentu menggunakan runAsUser dan runAsGroup, bahkan jika tidak ditentukan dalam manifest image. Namun, izin file dalam layer image mungkin membuatnya tidak memungkinkan untuk langsung memulai proses dengan pengguna tanpa hak istimewa tanpa modifikasi image.
Hindari menggunakan tag image untuk mereferensikan image, terutama tag latest, karena image di balik tag dapat dengan mudah dimodifikasi di registry. Sebaiknya gunakan digest lengkap sha256 yang unik untuk manifest image. Kebijakan ini dapat ditegakkan melalui ImagePolicyWebhook. Tanda tangan image juga dapat secara otomatis diverifikasi dengan admission controller saat waktu penerapan untuk memvalidasi keaslian dan integritasnya.
Pemindaian container image dapat mencegah kerentanan kritis diterapkan ke klaster bersama dengan container image. Pemindaian image harus diselesaikan sebelum menerapkan container image ke klaster dan biasanya dilakukan sebagai bagian dari proses penerapan dalam pipeline CI/CD. Tujuan dari pemindaian image adalah untuk mendapatkan informasi tentang kemungkinan kerentanan dan pencegahannya dalam container image, seperti skor Common Vulnerability Scoring System (CVSS). Jika hasil pemindaian image digabungkan dengan aturan kepatuhan pipeline, hanya container image yang telah diperbaiki dengan benar yang akan digunakan di lingkungan produksi.
Admission controllers
Pemilihan admission controller yang sesuai diaktifkan.
Kebijakan keamanan pod ditegakkan oleh Pod Security Admission atau/atau webhook admission controller.
Plugin rantai admission dan webhook dikonfigurasi dengan aman.
Admission controller dapat membantu meningkatkan keamanan klaster. Namun, mereka juga dapat menghadirkan risiko karena memperluas API server dan harus diamankan dengan benar.
Daftar berikut menyajikan sejumlah admission controller yang dapat dipertimbangkan untuk meningkatkan postur keamanan klaster dan aplikasi Anda. Ini mencakup controller yang mungkin dirujuk di bagian lain dokumen ini.
Grup pertama admission controller ini mencakup plugin yang diaktifkan secara default, pertimbangkan untuk tetap mengaktifkannya kecuali Anda tahu apa yang Anda lakukan:
Memungkinkan penggunaan custom controller melalui webhook, controller ini tidak memodifikasi permintaan yang mereka tinjau.
Grup kedua mencakup plugin yang tidak diaktifkan secara default tetapi berada dalam status ketersediaan umum dan direkomendasikan untuk meningkatkan postur keamanan Anda:
Membatasi izin kubelet untuk hanya memodifikasi sumber daya API pod yang mereka miliki atau sumber daya API node yang mewakili mereka sendiri. Ini juga mencegah kubelet menggunakan anotasi node-restriction.kubernetes.io/, yang dapat digunakan oleh penyerang dengan akses ke kredensial kubelet untuk memengaruhi penempatan pod ke node yang dikontrol.
Grup ketiga mencakup plugin yang tidak diaktifkan secara default tetapi dapat dipertimbangkan untuk kasus penggunaan tertentu:
Panduan dasar untuk memastikan keamanan aplikasi di Kubernetes, ditujukan untuk pengembang aplikasi
Daftar ini bertujuan untuk memberikan panduan dasar dalam mengamankan aplikasi
yang berjalan di Kubernetes dari perspektif pengembang.
Daftar ini tidak dimaksudkan untuk menjadi lengkap dan akan terus berkembang seiring waktu.
Cara membaca dan menggunakan dokumen ini:
Urutan topik tidak mencerminkan urutan prioritas.
Beberapa item daftar dijelaskan dalam paragraf di bawah daftar setiap bagian.
Daftar ini mengasumsikan bahwa pengembang adalah pengguna kluster Kubernetes yang
berinteraksi dengan objek dalam lingkup namespace.
Perhatian:
Daftar ini tidak cukup untuk mencapai postur keamanan yang baik dengan sendirinya.
Postur keamanan yang baik membutuhkan perhatian dan peningkatan yang terus-menerus, tetapi daftar ini
dapat menjadi langkah pertama dalam perjalanan tanpa akhir menuju kesiapan keamanan.
Beberapa rekomendasi dalam daftar ini bisa jadi terlalu ketat atau terlalu longgar untuk
kebutuhan keamanan spesifik kamu. Karena keamanan Kubernetes tidak bersifat "satu ukuran untuk semua",
setiap kategori item daftar periksa harus dievaluasi berdasarkan kelebihannya.
Penguatan keamanan dasar
Daftar berikut memberikan rekomendasi penguatan keamanan dasar yang
akan berlaku untuk sebagian besar aplikasi yang di-deploy ke Kubernetes.
Aplikasi dikonfigurasi dengan kelas QoS
yang sesuai melalui permintaan dan batas sumber daya.
Batas memori ditetapkan untuk beban kerja dengan batas yang sama atau lebih besar dari permintaan.
Batas CPU dapat ditetapkan pada beban kerja sensitif.
Akun layanan
Hindari menggunakan default ServiceAccount. Sebagai gantinya, buat ServiceAccount untuk
setiap beban kerja (workloads) atau layanan mikro.
automountServiceAccountToken harus disetel ke false kecuali pod
secara khusus memerlukan akses ke API Kubernetes untuk beroperasi.
Rekomendasi securityContext tingkat pod
Terapkan runAsNonRoot: true.
Konfigurasikan container untuk dijalankan sebagai pengguna dengan hak istimewa lebih rendah
(misalnya, menggunakan runAsUser dan runAsGroup), dan konfigurasikan izin yang sesuai
pada file atau direktori di dalam image container.
Opsional, tambahkan grup tambahan dengan fsGroup untuk mengakses volume persisten.
Aplikasi di-deploy ke namespace yang menerapkan
standar keamanan Pod yang sesuai.
Jika kamu tidak dapat mengontrol penerapan ini untuk kluster tempat aplikasi di-deploy,
pertimbangkan ini melalui dokumentasi atau pertahanan tambahan secara mendalam.
Rekomendasi securityContext tingkat container
Nonaktifkan eskalasi hak istimewa menggunakan allowPrivilegeEscalation: false.
Konfigurasikan sistem file root agar hanya dapat dibaca dengan readOnlyRootFilesystem: true.
Hindari menjalankan container dengan hak istimewa (atur privileged: false).
Hapus semua kemampuan dari container dan tambahkan kembali hanya yang spesifik
yang diperlukan untuk operasi container.
Kontrol Akses Berbasis Peran (RBAC)
Izin seperti create, patch, update, dan delete
hanya boleh diberikan jika diperlukan.
Hindari membuat izin RBAC untuk membuat atau memperbarui peran yang dapat menyebabkan
eskalasi hak istimewa.
Tinjau binding untuk grup system:unauthenticated dan hapus jika memungkinkan,
karena ini memberikan akses kepada siapa saja yang dapat menghubungi server API pada tingkat jaringan.
Untuk beban kerja sensitif, pertimbangkan untuk menyediakan ValidatingAdmissionPolicy yang direkomendasikan
yang lebih membatasi tindakan tulis yang diizinkan.
Keamanan image
Gunakan alat pemindaian image untuk memindai image sebelum mendepoy container di kluster Kubernetes.
Gunakan penandatanganan container untuk memvalidasi tanda tangan image container sebelum men-deploy ke kluster Kubernetes.
Kebijakan jaringan
Konfigurasikan NetworkPolicies
untuk hanya mengizinkan lalu lintas masuk dan keluar yang diharapkan dari pod.
Pastikan bahwa kluster kamu menyediakan dan menerapkan NetworkPolicy.
Jika kamu menulis aplikasi yang akan di-deploy pengguna ke kluster yang berbeda,
pertimbangkan apakah kamu dapat mengasumsikan bahwa NetworkPolicy tersedia dan diterapkan.
Penguatan keamanan tingkat lanjut
Bagian ini mencakup beberapa poin penguatan keamanan tingkat lanjut
yang mungkin berharga berdasarkan pengaturan lingkungan Kubernetes yang berbeda.
Konfigurasikan kelas runtime yang sesuai untuk container.
Catatan: Bagian ini tertaut ke proyek-proyek pihak ketiga yang menyediakan fungsionalitas yang dibutuhkan oleh Kubernetes. Pencipta proyek Kubernetes tidak bertanggung jawab atas proyek-proyek tersebut. Laman ini mengikuti pedoman website CNCF dengan membuat daftar proyek menurut abjad. Untuk menambakan proyek ke dalam daftar ini, bacalah panduan sebelum mengirimkan perubahan.
Beberapa container mungkin memerlukan tingkat isolasi yang berbeda dari yang disediakan oleh
runtime default kluster. runtimeClassName dapat digunakan dalam podspec
untuk mendefinisikan kelas runtime yang berbeda.
Untuk beban kerja sensitif, pertimbangkan menggunakan alat emulasi kernel seperti
gVisor, atau isolasi virtual menggunakan mekanisme
seperti kata-containers.
Dalam lingkungan dengan tingkat kepercayaan tinggi, pertimbangkan menggunakan
mesin virtual rahasia
untuk lebih meningkatkan keamanan kluster.
