Keamanan

• 1: Ikhtisar Keamanan Cloud Native
• 2: Panduan Pengamanan - Mekanisme Autentikasi
• 3: Daftar Periksa Keamanan
• 4: Daftar Keamanan Aplikasi

1 - Ikhtisar Keamanan Cloud Native

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.

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.

Tabel Keamanan Penyedia Layanan Cloud

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

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.

Container

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.

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

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.

Selanjutnya

• Pelajari tentang Network Policy untuk Pod
• Pelajari tentang mengamankan klaster kamu
• Pelajari tentang kontrol akses API
• Pelajari tentang enkripsi data saat transit for the control plane
• Pelajari tentang enkripsi data saat diam
• Pelajari tentang Secret (data sensitif) pada Kubernetes

2 - Panduan Pengamanan - Mekanisme Autentikasi

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.

Selanjutnya

• Autentikasi Pengguna
• Autentikasi dengan Token Bootstrap
• Autentikasi Kubelet
• [Autentikasi dengan Token Akun Layanan](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-accounfor kens)

3 - Daftar Periksa Keamanan

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.

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.
• Role Based Access Control Good Practices diikuti untuk panduan dalam autentikasi dan autorisasi.

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.

Untuk larangan penggunaan LoadBalancer dan ExternalIPs, lihat CVE-2020-8554: Man in the middle using LoadBalancer or ExternalIPs dan DenyServiceExternalIPs admission controller untuk informasi lebih lanjut.

Keamanan Pod

• 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.

Untuk tutorial langsung tentang Pod Security, lihat posting blog Kubernetes 1.23: Pod Security Graduates to Beta.

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.

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.

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

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.

Logs dan Audit

• 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:

Node Selectors

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.

PodTolerationRestriction

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

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.
• Bound service account token volume digunakan sebagai pengganti token yang tidak memiliki masa kedaluwarsa.

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:

CertificateApproval

Melakukan pemeriksaan otorisasi tambahan untuk memastikan pengguna yang menyetujui memiliki izin untuk menyetujui permintaan sertifikat.

CertificateSigning

Melakukan pemeriksaan otorisasi tambahan untuk memastikan pengguna yang menandatangani memiliki izin untuk menandatangani permintaan sertifikat.

CertificateSubjectRestriction

Menolak permintaan sertifikat apa pun yang menentukan 'group' (atau 'atribut organisasi') dari system:masters.

LimitRanger

Menegakkan batasan API LimitRange.

MutatingAdmissionWebhook

Memungkinkan penggunaan custom controller melalui webhook, controller ini dapat memodifikasi permintaan yang mereka tinjau.

PodSecurity

Pengganti untuk Pod Security Policy, membatasi konteks keamanan dari Pod yang diterapkan.

ResourceQuota

Menegakkan kuota sumber daya untuk mencegah penggunaan sumber daya yang berlebihan.

ValidatingAdmissionWebhook

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:

DenyServiceExternalIPs

Menolak semua penggunaan baru dari field Service.spec.externalIPs. Ini adalah mitigasi untuk CVE-2020-8554: Man in the middle menggunakan LoadBalancer atau ExternalIPs.

NodeRestriction

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:

AlwaysPullImages

Menegakkan penggunaan versi terbaru dari image yang ditandai dan memastikan bahwa pengelola memiliki izin untuk menggunakan image tersebut.

ImagePolicyWebhook

Memungkinkan penegakan kontrol tambahan untuk image melalui webhook.

Langkah Selanjutnya

• Privilege escalation via Pod creation memberikan peringatan tentang risiko kontrol akses tertentu; periksa bagaimana Anda mengelola ancaman tersebut.
  • Jika Anda menggunakan Kubernetes RBAC, baca RBAC Good Practices untuk informasi lebih lanjut tentang otorisasi.
• Mengamankan Klaster untuk informasi tentang melindungi klaster dari akses yang tidak disengaja atau berbahaya.
• Panduan Multi-tenancy Klaster untuk rekomendasi opsi konfigurasi dan praktik terbaik tentang multi-tenancy.
• Posting Blog "Melihat Lebih Dekat Panduan Penguatan Kubernetes NSA/CISA" sebagai sumber pelengkap untuk memperkuat klaster Kubernetes.

4 - Daftar Keamanan 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.

Penguatan keamanan dasar

Daftar berikut memberikan rekomendasi penguatan keamanan dasar yang akan berlaku untuk sebagian besar aplikasi yang di-deploy ke Kubernetes.

Desain aplikasi

• Ikuti prinsip keamanan yang tepat saat merancang aplikasi.
• 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.

Verba create, update, dan delete harus diizinkan dengan hati-hati. Verba patch jika diizinkan pada Namespace dapat mengizinkan pengguna memperbarui label pada namespace atau deployment yang dapat meningkatkan permukaan serangan.

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.

Keamanan container Linux

Konfigurasikan Security Context untuk pod-container.

• Tetapkan Profil Seccomp untuk Container.
• Batasi Akses Container ke Sumber Daya dengan AppArmor.
• Tetapkan Label SELinux ke Container.

Kelas runtime

• Konfigurasikan kelas runtime yang sesuai untuk container.

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.