Catatan perev. : Asli artikel ini diterbitkan di blog resmi Kubernetes dan ditulis oleh Andrew Martin, salah satu pendiri perusahaan muda Inggris Control Plane, yang berspesialisasi dalam keamanan untuk aplikasi cloud asli yang berjalan di K8s.
Keamanan di Kubernetes telah datang jauh sejak proyek tiba, tetapi perangkap masih terjadi. Kami menawarkan daftar rekomendasi yang berguna tentang bagaimana melindungi cluster dan meningkatkan stabilitas mereka dalam kasus peretasan: kami akan mulai dengan pesawat kontrol, terus dengan beban kerja dan keamanan jaringan, dan diakhiri dengan penilaian keamanan masa depan.
Bagian 1: Kontrol Pesawat
Pesawat kendali adalah otak Kubernetes. Dia memiliki gagasan umum tentang setiap wadah dan pod yang berjalan di cluster, dapat merencanakan pod baru (yang dapat berisi kontainer dengan akses root ke node induknya), dan dapat membaca semua rahasia yang tersimpan di cluster. Ini adalah komponen yang sangat penting yang membutuhkan perlindungan terus-menerus terhadap kebocoran data yang tidak disengaja dan tindakan jahat: baik ketika diakses, ketika tidak ada yang terjadi, dan ketika data ditransmisikan melalui jaringan.
1. TLS di mana-mana
Untuk setiap komponen yang mendukung TLS, harus diaktifkan - untuk mencegah peredupan lalu lintas, verifikasi identitas server dan (dalam kasus Mutual TLS) verifikasi identitas klien."Harap dicatat bahwa beberapa komponen dan metode pemasangan dapat mengaktifkan port lokal untuk HTTP, sehingga administrator perlu membiasakan diri dengan pengaturan setiap komponen untuk mengidentifikasi jalur yang mungkin untuk lalu lintas tidak aman."
Dari dokumentasi Kubernetes
Diagram jaringan di bawah ini dari
Lucas Käldström menunjukkan di mana TLS sangat dibutuhkan: antara setiap komponen pada wizard, dan antara Kubelet dan server API.
Kelsey Hightower Kubernetes The Hard Way klasik dan
dokumentasi keamanan di etcd menawarkan instruksi terperinci untuk mencapai tujuan ini.
Secara historis, penskalaan otomatis node Kubernetes tidak mudah, karena setiap node memerlukan kunci TLS untuk terhubung ke master, dan menyimpan rahasia dalam gambar dasar adalah praktik yang buruk.
Bootstrap TLS Kubelet memungkinkan Kubelet baru untuk membuat permintaan penandatanganan sertifikat sehingga sertifikat dihasilkan saat boot:
2. Hak minimum dalam RBAC, menonaktifkan ABAC, memantau log
Role Based Access Control (RBAC) menyediakan manajemen kebijakan berbutir halus di mana pengguna mengakses sumber daya seperti ruang nama.
Attribute Based Access Control (ABAC) di Kubernetes telah digantikan oleh RBAC sejak K8 1.6 dan tidak boleh diaktifkan di sisi server API. Gunakan RBAC sebagai gantinya:
--authorization-mode=RBAC (atau flag ini untuk GKE:
--no-enable-legacy-authorization ).
Ada banyak
contoh yang baik dari kebijakan RBAC untuk berbagai layanan dalam sebuah cluster, serta
dokumentasi . Tapi jangan berhenti di situ: pengaturan yang kompeten untuk kebijakan RBAC dapat diperoleh dengan menggunakan
audit2rbac dari log
audit .
Kebijakan RBAC yang salah atau terlalu permisif adalah risiko keamanan jika jantung dikompromikan. Mempertahankan aturan RBAC dengan hak istimewa minimal, terus mengauditnya, dan memperbaikinya harus menjadi bagian dari “kebersihan teknis utang” yang diterapkan tim dalam siklus hidup pengembangan.
Pencatatan audit (beta dalam Kubernetes 1.10) menawarkan API pencatatan kustom untuk beban kerja (seperti permintaan dan respons) dan pada tingkat metadata. Level logging dapat dikonfigurasikan sesuai dengan kebijakan keamanan organisasi -
GKE menerapkan nilai default yang wajar untuk mereka yang baru mulai bekerja dengannya.
Untuk permintaan baca seperti
dapatkan ,
daftar, dan
tonton , hanya objek yang diminta disimpan dalam log audit, tanpa objek respons. Untuk kueri yang melibatkan data sensitif seperti
Rahasia atau
ConfigMap , hanya metadata yang diekspor. Untuk semua permintaan lainnya, kedua objek dicatat dalam log audit: baik permintaan maupun responsnya.
Jangan lupa: menyimpan log ini di dalam cluster adalah risiko keamanan jika terjadi kompromi. Log ini, seperti yang sensitif keamanan lainnya, harus ditempatkan di luar cluster untuk menghindari konsekuensi negatif jika terjadi kerentanan.
3. Gunakan otentikasi pihak ketiga untuk API Server
Sentralisasi otentikasi dan otorisasi untuk seluruh organisasi (yaitu, Single Sign On) membantu dalam proses menerima dan meninggalkan karyawan baru, memastikan hak akses yang konsisten.Integrasi Kubernetes dengan penyedia otentikasi pihak ketiga (seperti Google atau GitHub) memberikan jaminan identitas dari platform jarak jauh (dengan perlindungan seperti otentikasi dua faktor) dan menghilangkan kebutuhan administrator untuk mengkonfigurasi ulang server API di Kubernetes untuk menambah / menghapus pengguna.
Dex adalah penyedia OpenID Connect Identity (OIDC) dan OAuth 2.0 dengan plug-in. Pusher melangkah lebih jauh dengan menyediakan
alat yang dapat disesuaikan , selain itu ada
beberapa pembantu
lain yang berfokus pada aplikasi lain.
4. Pisahkan dan tempatkan cluster Anda, dll, di belakang firewall
etcd menyimpan informasi tentang status dan rahasia Kubernetes, merupakan komponen penting dari K8 - ia harus dilindungi secara terpisah dari anggota cluster lainnya.Akses tulis ke etcd di server API setara dengan mengeluarkan hak root ke seluruh cluster, dan bahkan akses baca dapat dengan mudah digunakan untuk meningkatkan hak istimewa.
Penjadwal Kubernetes di etcd mencari definisi pod yang tidak memiliki node. Lalu ia mengirim semua pod yang ditemukan ke Kubelet yang tersedia untuk perencanaan. Validasi pod ini dilakukan oleh server API sebelum menulisnya ke etcd, sehingga penyerang yang langsung menulis ke etcd dapat mem-bypass banyak mekanisme keamanan - misalnya,
PodSecurityPolicies .
etcd harus dikonfigurasikan dengan
sertifikat TLS (
klien dan
rekan ) dan disebarkan ke node khusus. Untuk mengurangi risiko pencurian dan penggunaan kunci pribadi dari node kerja, Anda juga dapat membatasi firewall cluster Server API.
5. Rotasi kunci enkripsi
Rotasi kunci dan sertifikat keamanan yang teratur adalah praktik keamanan terbaik yang memungkinkan Anda membatasi "radius kehancuran" ketika kunci dikompromikan.Kubernetes akan
secara otomatis merotasi beberapa sertifikat (khususnya, klien Kubelet dan sertifikat server) dengan membuat CSR baru setelah yang saat ini berakhir.
Namun,
kunci simetris yang digunakan oleh server API untuk mengenkripsi nilai-nilai etcd tidak diputar secara otomatis - ini harus
dilakukan secara manual . Operasi ini memerlukan akses master, sehingga layanan yang dikelola (seperti GKE dan AKS) menyembunyikan masalah dari pengguna.
Bagian 2: beban kerja
Dengan keamanan minimal di level control plane, cluster sudah dapat berfungsi dengan aman. Namun, seperti halnya kapal dengan muatan yang berpotensi berbahaya, kontainer dari kapal semacam itu harus melindungi muatan jika terjadi kecelakaan atau kebocoran yang tidak terduga. Hal yang sama berlaku untuk beban kerja di Kubernetes (
Pods ,
Deployment ,
Jobs ,
Sets , dll.) - mereka dapat dipercaya pada saat penyebaran, tetapi jika mereka dapat diakses dari luar, selalu ada risiko bahwa mereka akan digunakan nanti oleh [penyerang]. Risiko ini dapat dikurangi dengan menjalankan beban kerja dengan hak istimewa minimal dan konfigurasi amannya.
6. Gunakan fitur keamanan Linux dan Kebijakan PodSecurity
Kernel Linux memiliki banyak ekstensi keamanan yang tumpang tindih sebagian (kapabilitas, SELinux, AppArmor, seccomp-bpf) yang dapat dikonfigurasi untuk memberikan aplikasi hak istimewa minimal.Utilitas seperti
bane akan membantu Anda menghasilkan profil untuk AppArmor, dan
docker-slim akan membantu Anda menghasilkan profil seccomp, tetapi berhati-hatilah: untuk mengidentifikasi semua efek samping dari penerapan kebijakan ini, Anda memerlukan rangkaian uji komprehensif yang memeriksa seluruh kode aplikasi.
PodSecurityPolicies mengatur penggunaan ekstensi keamanan ini, serta arahan keamanan Kubernetes lainnya. Mereka bertanggung jawab atas persyaratan minimum yang harus dipenuhi untuk bisa masuk ke server API, termasuk profil keamanan, bendera hak istimewa, jaringan host bersama, proses atau ruang nama untuk IPC.
Arahan-arahan ini penting karena mereka membantu mencegah proses kemas dari melarikan diri dari batas-batas mereka yang terisolasi.
Contoh PodSecurityPolicy dari Tim Allclair sangat fleksibel - Anda dapat menjadikannya sebagai dasar dan menyesuaikannya
untuk kasing Anda.
7. Lakukan analisis statis YAML
Jika PodSecurityPolicies membatasi akses ke server API, maka analisis statis juga dapat digunakan dalam proses pengembangan untuk memodelkan persyaratan peraturan organisasi dan selera risiko.Informasi sensitif tidak boleh disimpan dalam sumber daya YAML seperti perapian (
Pods ,
Deployment ,
Sets , dll.), Dan
ConfigMaps dan
Rahasia sensitif harus dienkripsi dengan utilitas seperti
Vault (dengan operator dari CoreOS),
git-crypt ,
rahasia tersegel atau
awan KMS cloud penyedia .
Analisis statis dari konfigurasi YAML dapat digunakan sebagai dasar untuk keamanan selama startup.
kubesec menghasilkan penilaian risiko untuk sumber daya:
{ "score": -30, "scoring": { "critical": [{ "selector": "containers[] .securityContext .privileged == true", "reason": "Privileged containers can allow almost completely unrestricted host access" }], "advise": [{ "selector": "containers[] .securityContext .runAsNonRoot == true", "reason": "Force the running image to run as a non-root user to ensure least privilege" }, { "selector": "containers[] .securityContext .capabilities .drop", "reason": "Reducing kernel capabilities available to a container limits its attack surface", "href": "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" }] } }
Dan
kubetest adalah kerangka kerja untuk pengujian unit konfigurasi Kubernetes:
#
Utilitas ini menerapkan pendekatan
shift kiri (yaitu, mereka memindahkan validasi dan verifikasi ke tahap awal siklus pengembangan). Pengujian keamanan pada tahap pengembangan memberikan umpan balik cepat kepada pengguna tentang kode dan konfigurasi, yang nantinya dapat ditolak dengan verifikasi manual atau otomatis, dan juga dapat memfasilitasi pengenalan praktik keamanan tambahan.
8. Jalankan kontainer bukan root
Kontainer yang berjalan sebagai root sering memiliki hak lebih banyak dari yang dibutuhkan oleh pekerjaan mereka, dan jika dikompromikan, mereka membantu penyerang mencapai kemampuan yang hebat.Kontainer masih mengandalkan model keamanan tradisional UNIX (disebut DAC,
kontrol akses diskresioner ) - semuanya adalah file, dan hak diberikan kepada pengguna dan grup.
Ruang nama pengguna tidak berfungsi di Kubernetes. Ini berarti bahwa tabel ID pengguna dalam wadah dipetakan ke tabel pengguna host, dan memulai proses dengan hak akses root di dalam wadah menyebabkannya berjalan dengan hak akses root pada host. Meskipun mekanisme ditambahkan ke semua ini untuk mencegah keluar dari wadah, berjalan sebagai root di dalam wadah tidak dianjurkan.
Banyak gambar wadah menggunakan pengguna root untuk menjalankan PID 1: jika proses ini dikompromikan, penyerang mendapatkan root di dalam wadah dan, dengan kesalahan konfigurasi apa pun, pengoperasian masalah menjadi lebih mudah.
Bitnami
melakukan pekerjaan yang sangat baik untuk menerjemahkan gambar wadah mereka ke pengguna
biasa (non-root) (yang juga merupakan persyaratan OpenShift default), yang dapat menyederhanakan migrasi Anda ke gambar non-root juga.
Fragmen PodSecurityPolicy ini mencegah proses root dari berjalan di wadah dan meningkat ke root:
# Required to prevent escalations to root. allowPrivilegeEscalation: false runAsUser: # Require the container to run without root privileges. rule: 'MustRunAsNonRoot'
Kontainer yang tidak menggunakan root tidak dapat menempati port yang diistimewakan, yaitu hingga 1024 (kemampuan yang sesuai di kernel Linux -
CAP_NET_BIND_SERVICE bertanggung jawab untuk ini), namun, menggunakan
Layanan membantu menghindari batasan ini. Berikut adalah contoh untuk aplikasi MyApp, yang menempati port 8443 dalam wadah, tetapi
Layanan membuatnya tersedia di port 443,
targetPort proxy permintaan untuk
targetPort :
kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 443 targetPort: 8443
Kebutuhan untuk menjalankan beban kerja tanpa menggunakan root akan tetap sampai ruang nama pengguna atau
waktu operasi untuk meluncurkan kontainer tanpa root termasuk dalam runtime kontainer.
9. Gunakan kebijakan jaringan
Secara default, jaringan Kubernetes memungkinkan semua lalu lintas antar pod. Pengaturan ini dapat dibatasi oleh kebijakan jaringan - NetworkPolicy .
Layanan tradisional terbatas pada firewall yang menggunakan alamat IP statis dan rentang port untuk setiap layanan. Karena alamat IP ini berubah sangat jarang, mereka secara historis telah digunakan sebagai bentuk otentikasi. Kontainer jarang memiliki IP statis - sifatnya menyiratkan kemungkinan penurunan cepat dan penciptaan kembali, bagi mereka penemuan layanan digunakan sebagai ganti alamat IP statis. Fitur-fitur ini sangat menyulitkan konfigurasi dan verifikasi firewall.
Karena Kubernetes menyimpan semua data tentang keadaan sistem di etcd, dimungkinkan untuk mengkonfigurasi firewall dinamis - jika ada dukungan yang diperlukan dalam plugin jaringan CNI. Calico, Cilium, kube-router, Romana dan Weave Net - semua plugin ini mendukung kebijakan jaringan.
Penting untuk dicatat bahwa kebijakan bekerja pada prinsip gagal-ditutup, yaitu, tidak adanya
podSelector sini secara default sama dengan semua nilai yang mungkin (wildcard):
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny spec: podSelector:
Berikut ini adalah contoh
NetworkPolicy , yang melarang segala sesuatu dari jalan keluar kecuali UDP 53 (DNS), yang juga mencegah koneksi masuk ke aplikasi. Kebijakan
Jaringan adalah kebijakan
stateful , sehingga aplikasi akan tetap menerima tanggapan untuk koneksi keluar.
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: myapp-deny-external-egress spec: podSelector: matchLabels: app: myapp policyTypes: - Egress egress: - ports: - port: 53 protocol: UDP - to: - namespaceSelector: {}
Kebijakan jaringan Kubernetes tidak dapat diterapkan ke nama DNS. Alasannya adalah bahwa DNS mendukung round-robin ke beberapa alamat IP dan respons dinamis yang tergantung pada akses IP, sehingga kebijakan jaringan hanya berlaku untuk alamat IP atau
podSelector (untuk alamat IP dinamis Kubernetes).
Praktik terbaik adalah mulai dengan melarang semua lalu lintas untuk namespace dan langkah demi langkah menambahkan rute yang diperlukan oleh aplikasi untuk lulus pengujian penerimaan. Prosesnya bisa sulit, sehingga ControlPlane mengembangkan
netassert , sebuah utilitas untuk menguji keamanan jaringan dalam skrip DevSecOps dengan nmap yang sangat paralel:
k8s: # used for Kubernetes pods deployment: # only deployments currently supported test-frontend: # pod name, defaults to `default` namespace test-microservice: 80 # `test-microservice` is the DNS name of the target service test-database: -80 # `test-frontend` should not be able to access test-database's port 80 169.254.169.254: -80, -443 # AWS metadata API metadata.google.internal: -80, -443 # GCP metadata API new-namespace:test-microservice: # `new-namespace` is the namespace name test-database.new-namespace: 80 # longer DNS names can be used for other namespaces test-frontend.default: 80 169.254.169.254: -80, -443 # AWS metadata API metadata.google.internal: -80, -443 # GCP metadata API
API dengan metadata dari penyedia cloud adalah sumber eskalasi potensial yang konstan (diperlihatkan
oleh karunia bug terbaru
Shopify ), jadi pengujian khusus yang mengonfirmasi bahwa API diblokir pada jaringan kontainer akan membantu melindungi terhadap kesalahan konfigurasi.
10. Pindai gambar dan jalankan IDS
Server web adalah batu loncatan untuk menyerang jaringan yang dilampirkan. Memindai file yang dipasang dalam gambar memungkinkan Anda memverifikasi bahwa tidak ada kerentanan yang diketahui yang dapat digunakan penyerang untuk mendapatkan akses jarak jauh ke wadah. Intrusion Detection Systems (IDS) merekam kejadian ini jika terjadi.Kubernetes memungkinkan pengiriman ke kluster melalui serangkaian pemeriksaan kontrol (dalam
pengontrol penerimaan ), yang berlaku tidak hanya untuk pod, tetapi juga sumber daya lain seperti
Penyebaran . Di dalamnya, masing-masing sub dapat divalidasi untuk masuk atau isinya dapat diubah, selain yang webhook di sisi backend sekarang juga didukung.
Webhooks ini dapat digunakan oleh wadah alat pemindaian gambar untuk memverifikasi gambar sebelum digunakan untuk cluster. Gambar yang gagal validasi tidak akan menerima persetujuan pengontrol.
Memindai gambar kontainer untuk mengetahui kerentanan membantu mengurangi waktu penyerang dapat memanfaatkan CVE terbuka. Untuk mencegah peluncuran gambar dengan kerentanan kritis dalam pipa penyebaran, Anda dapat menggunakan utilitas gratis seperti
Clair dari CoreOS dan
Micro Scanner dari Aqua.
Alat-alat seperti
Grafeas memungkinkan Anda untuk menyimpan metadata gambar untuk pemeriksaan kepatuhan dan kerentanan yang sedang berlangsung menggunakan tanda tangan wadah unik (atau hash
pengalamatan konten khusus). Memindai gambar kontainer menggunakan hash ini sama dengan memindai gambar yang digunakan dalam produksi dan dapat dilakukan terus menerus tanpa perlu memiliki akses ke lingkungan produksi.
Kerentanan 0day yang tidak diketahui akan selalu ada, jadi Kubernetes harus menggunakan sistem deteksi intrusi seperti
Twistlock ,
Aqua, atau
Sysdig Secure . IDS mendeteksi perilaku yang tidak biasa dalam wadah dan menghentikan atau membunuhnya.
Sysdig's Falco adalah mesin aturan Open Source dan titik awal untuk ekosistem ini.
Bagian 3: Masa Depan
Tahap keamanan berikutnya dalam "evolusi awan asli" tampaknya adalah service mesh, meskipun penerapannya tidak akan segera terjadi: migrasi ini membutuhkan pengalihan kompleksitas aplikasi ke infrastruktur mesh, dan organisasi harus menyadari praktik terbaik ini.
11. Luncurkan mesh layanan
Service mesh adalah jaringan koneksi terenkripsi persisten yang dibuat antara "sisi-terhubung" (mirip dengan "sespan") , proksi berkinerja tinggi seperti Utusan dan Linkerd. Ini membawa manajemen lalu lintas, pemantauan, dan kebijakan - semua tanpa perubahan dalam layanan microser.Transfer keamanan dan kode terkait jaringan dari layanan microser ke perangkat perpustakaan yang dibagikan dan diuji pertempuran sudah dimungkinkan dengan
Linkerd , dan
Istio dari Google, IBM dan Lyft membawa alternatif ke ruang ini. Dengan penambahan
SPIFFE untuk identitas kriptografis dari setiap pod dan banyak fitur lainnya, Istio dapat menyederhanakan penyebaran keamanan jaringan generasi mendatang.
Dalam jaringan "nol kepercayaan" mungkin tidak ada kebutuhan untuk firewall tradisional atau kebijakan jaringan Kubernet, karena setiap interaksi terjadi menggunakan mTLS (mutual TLS), yang tidak hanya menjamin keamanan interaksi, tetapi juga mengkonfirmasi identitas kedua layanan .
Pergeseran dari pendekatan jaringan tradisional ini ke prinsip keamanan dunia Cloud Native tidak akan mudah bagi mereka yang memiliki pola pikir keamanan tradisional. Sebagai pengantar dunia baru ini, kami sangat merekomendasikan
buku Zero Trust Networking karya
Evan Gilman dari SPIFFE.
Istio 0,8 LTS saat ini tersedia, dan proyek ini dengan cepat mendekati rilis 1.0-nya. Versi proyek dalam hal stabilitas dilakukan mirip dengan model Kubernetes: kernel yang stabil dengan API terpisah yang status alpha atau beta mereka diindikasikan menggunakan ruang nama. Harapkan untuk melihat Istio berkembang dalam beberapa bulan mendatang.
Kesimpulan
Aplikasi Cloud Native memiliki kumpulan primitif keamanan ringan yang lebih rinci yang membantu melindungi beban kerja dan infrastruktur. Kekuatan dan fleksibilitas alat-alat semacam itu adalah berkah sekaligus kutukan: tanpa otomatisasi yang memadai [untuk penggunaannya], mengekspos aplikasi yang tidak aman untuk melampaui wadah atau model isolasi mereka menjadi lebih mudah.
Utilitas untuk perlindungan lebih mudah diakses daripada sebelumnya, namun, untuk mengurangi potensi serangan dan potensi untuk konfigurasi yang salah, Anda harus menggunakannya dengan hati-hati.
Jika keamanan memperlambat kecepatan organisasi dalam mengirimkan perubahan, itu tidak akan pernah menjadi prioritas. Menggunakan prinsip-prinsip Pengiriman Berkelanjutan dalam kaitannya dengan rantai pasokan perangkat lunak memungkinkan organisasi untuk mencapai kepatuhan terhadap peraturan, audit berkelanjutan dan peningkatan manajemen tanpa memengaruhi kinerja bisnis.
Peningkatan keamanan yang cepat dan bertahap adalah cara termudah dengan rangkaian uji komprehensif. Continuous Security — pipeline', , , .
PS dari penerjemah
Baca juga di blog kami: