Perkuat keamanan Pod dan cegah kontainer escape - Container Service for Kubernetes

Container Service for Kubernetes (ACK) memungkinkan Anda memperkuat keamanan pod dengan menerapkan serangkaian kontrol yang mengurangi risiko container escape dan privilege escalation. Topik ini mencakup sembilan rekomendasi keamanan, termasuk cara melarang mode istimewa, menegakkan eksekusi non-root, membatasi volume hostPath, dan menonaktifkan pemasangan token ServiceAccount secara otomatis.

Mengapa container escape penting

Container escape memungkinkan penyerang menaikkan hak akses dari dalam kontainer hingga menguasai host yang mendasarinya. Dua perilaku default Kubernetes menciptakan risiko ini.

Konteks root default. Secara default, proses kontainer dijalankan sebagai pengguna root di Linux. Docker membatasi apa yang dapat dilakukan pengguna root tersebut menggunakan Linux capabilities, tetapi kumpulan default-nya sangat luas:

cap_chown, cap_dac_override, cap_fowner, cap_fsetid, cap_kill, cap_setgid, cap_setuid, cap_setpcap, cap_net_bind_service, cap_net_raw, cap_sys_chroot, cap_mknod, cap_audit_write, cap_setfcap

Penyerang yang mengeksploitasi kerentanan pada aplikasi berkontainer dapat menggunakan capability ini untuk membaca Secrets, ConfigMaps, dan data sensitif lainnya di host. Hindari menjalankan kontainer dalam mode istimewa—kontainer istimewa mewarisi semua Linux capabilities pengguna root.

Akses API seluruh node melalui kubelet. Semua node pekerja Kubernetes menggunakan node authorizer, yaitu mode otorisasi khusus yang mengatur permintaan API yang dibuat oleh kubelet. Node authorizer memberikan setiap kubelet akses baca ke Services, Endpoints, Nodes, Pods, Secrets, ConfigMaps, persistent volumes (PVs), dan persistent volume claims (PVCs) untuk pod di node tersebut, serta akses tulis ke status node, status pod, dan Events. Selain itu, node authorizer memberikan izin terkait otentikasi: akses baca dan tulis ke API CertificateSigningRequest (CSR) untuk TLS bootstrapping, serta kemampuan membuat TokenReview dan SubjectAccessReview untuk meninjau otentikasi dan otorisasi identitas yang didelegasikan.

Secara default, kluster ACK mengaktifkan admission controller NodeRestriction, yang membatasi setiap kubelet hanya dapat memodifikasi node-nya sendiri dan pod yang terikat padanya. Namun, NodeRestriction saja tidak dapat mencegah penyerang melakukan kueri terhadap API Kubernetes untuk mengumpulkan informasi tentang lingkungan kluster.

Mekanisme penegakan

ACK mendukung pod security policies berbasis Open Policy Agent (OPA) dan Gatekeeper. Kebijakan ini memvalidasi setiap permintaan pembuatan atau pembaruan pod terhadap aturan keamanan yang Anda konfigurasi. Permintaan yang tidak sesuai akan ditolak dengan error. Untuk setiap rekomendasi di bawah ini, tersedia kebijakan ACK pra-definisi yang sesuai untuk menegakkan kontrol tersebut di tingkat namespace.

Rekomendasi keamanan pod

Sembilan kontrol berikut mengatasi vektor serangan paling umum. Terapkan secara bersamaan untuk pertahanan berlapis (defense in depth).

1. Larang kontainer istimewa

Kontainer istimewa mewarisi semua Linux capabilities pengguna root di host. Sebagian besar beban kerja tidak memerlukan capability ini. Larang mode istimewa untuk mencegah penyerang yang telah menguasai kontainer agar tidak langsung mengakses sumber daya host.

Bidang yang dibatasi:

Field	Nilai yang diizinkan
`spec.containers[*].securityContext.privileged`	Undefined, `false`
`spec.initContainers[*].securityContext.privileged`	Undefined, `false`

Terapkan kebijakan ACKPSPPrivilegedContainer untuk menegakkan pembatasan ini di namespace yang ditentukan.

2. Jalankan pod sebagai pengguna non-root

Semua kontainer dijalankan sebagai root secara default. Penyerang yang mendapatkan akses shell ke kontainer root memiliki jalur yang jauh lebih mudah menuju host. Jalankan kontainer sebagai pengguna non-root untuk membatasi dampak kompromi.

Gunakan salah satu pendekatan berikut:

Hapus shell dari gambar kontainer.
Tambahkan instruksi USER ke Dockerfile.
Atur spec.securityContext.runAsUser dan runAsGroup di podSpec.

Terapkan kebijakan ACKPSPAllowedUsers untuk membatasi pengguna dan kelompok mana yang dapat menjalankan kontainer di namespace yang ditentukan.

3. Larang Docker-in-Docker dan pemasangan Docker.sock

Membuat gambar di dalam kontainer dengan menggunakan Docker-in-Docker atau dengan memasang Docker.sock memberikan kontrol proses kontainer atas node tersebut.

Gunakan pendekatan alternatif untuk membangun gambar sebagai gantinya:

Gunakan instans Container Registry Enterprise Edition untuk membangun gambar
kaniko — membangun gambar di dalam Kubernetes tanpa akses daemon Docker
img — pembuatan gambar tanpa root tanpa Docker.sock

4. Batasi volume hostPath

Volume hostPath memasang direktori host secara langsung ke dalam pod. Kontainer yang dijalankan sebagai root memiliki akses tulis ke direktori tersebut. Penyerang dapat memanfaatkannya untuk memodifikasi pengaturan kubelet, membuat tautan simbolik ke file di luar path yang dipasang (seperti /etc/shadow), atau membaca Secrets yang dipasang di host. Atur pemasangan hostPath sebagai read-only untuk membatasi kerusakan.

volumeMounts:
- name: hostPath-volume
  readOnly: true
  mountPath: /host-path

Terapkan kebijakan ACKPSPHostFilesystem untuk membatasi direktori host mana yang dapat dipasang di namespace yang ditentukan.

5. Tetapkan permintaan dan batas resource

Pod tanpa permintaan atau batas resource dapat menghabiskan seluruh CPU dan memori di node, menyebabkan kubelet crash atau pod lain dievakuasi. Menetapkan permintaan dan batas mengurangi konflik sumber daya dan membatasi dampak aplikasi yang berperilaku buruk.

Tentukan permintaan dan batas CPU serta memori di podSpec. Terapkan kuota sumber daya ke namespace untuk mewajibkan semua kontainer mendeklarasikan permintaan dan batas. Gunakan LimitRange untuk menetapkan nilai default dan batas per kontainer. Untuk informasi lebih lanjut, lihat Managing Resources for Containers, Resource Quotas, dan Limit Ranges.

Terapkan kebijakan ACKContainerLimits untuk menegakkan batas resource di namespace yang ditentukan.

6. Larang privilege escalation

Privilege escalation memungkinkan proses mengubah konteks keamanannya saat waktu proses—misalnya, dengan mengeksekusi binari yang memiliki bit SUID atau SGID diatur (seperti sudo). Hal ini memungkinkan proses berjalan dengan izin pengguna atau kelompok lain. Menonaktifkan fitur ini secara eksplisit mencegah proses non-root mendapatkan kembali akses tingkat root.

Bidang yang dibatasi:

Field	Nilai yang diizinkan
`securityContext.allowPrivilegeEscalation`	`false`

securityContext:
  allowPrivilegeEscalation: false

Terapkan kebijakan ACKPSPAllowPrivilegeEscalationContainer untuk menegakkan pengaturan ini di namespace yang ditentukan.

7. Nonaktifkan pemasangan token ServiceAccount secara otomatis

Untuk pod yang tidak perlu memanggil API Kubernetes, nonaktifkan pemasangan token ServiceAccount secara otomatis. Ini menghapus token dari sistem file pod sehingga tidak dapat digunakan jika pod dikompromikan.

Nonaktifkan pemasangan token untuk pod tertentu:

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-automount
spec:
  automountServiceAccountToken: false

Nonaktifkan pemasangan token untuk semua pod yang menggunakan ServiceAccount tertentu:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-no-automount
automountServiceAccountToken: false

Penting

Menonaktifkan pemasangan token tidak mencegah pod mengakses API Kubernetes—pod tetap dapat membuat koneksi jaringan ke server API. Untuk memblokir akses API sepenuhnya, konfigurasikan network policies. Untuk informasi lebih lanjut, lihat Use network policies in ACK clusters.

Terapkan kebijakan ACKBlockAutomountToken untuk menegakkan automountServiceAccountToken: false di seluruh pod aplikasi di namespace yang ditentukan.

8. Nonaktifkan service discovery

Untuk pod yang tidak perlu mencari atau memanggil layanan kluster lain, kurangi informasi yang tersedia bagi mereka dengan menonaktifkan service links dan mengubah kebijakan DNS. Ini membatasi apa yang dapat dienumerasi penyerang jika pod dikompromikan.

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-service-info
spec:
  dnsPolicy: Default # Nilai Default tidak menunjukkan pengaturan default kebijakan DNS.
  enableServiceLinks: false

Secara default, kebijakan DNS pod adalah ClusterFirst, yang mengarahkan kueri DNS melalui layanan CoreDNS dalam kluster. Mengatur dnsPolicy: Default mengarahkan DNS melalui resolver node. Mengatur enableServiceLinks: false mencegah Services di namespace dimasukkan sebagai variabel lingkungan. Untuk informasi lebih lanjut, lihat Environment variables dan Pod's DNS policy.

Penting

Mengubah kebijakan DNS dan menonaktifkan service links tidak mencegah pod mengakses CoreDNS secara langsung. Penyerang tetap dapat mengenumerasi layanan kluster dengan menjalankan dig SRV *.*.svc.cluster.local @$CLUSTER_DNS_IP. Gunakan network policies untuk sepenuhnya membatasi service discovery. Untuk informasi lebih lanjut, lihat Use network policies in ACK clusters.

9. Gunakan sistem file root read-only

Sistem file root read-only mencegah penyerang menimpa binari atau file konfigurasi aplikasi di dalam kontainer. Jika aplikasi harus menulis ke disk, konfigurasikan agar menulis ke volume tmpfs atau volume persisten yang dipasang sebagai gantinya.

Bidang yang dibatasi:

Field	Nilai yang diizinkan
`securityContext.readOnlyRootFilesystem`	`true`

securityContext:
  readOnlyRootFilesystem: true

Terapkan kebijakan ACKPSPReadOnlyRootFilesystem untuk menegakkan sistem file root read-only pada pod di namespace yang ditentukan.

Langkah selanjutnya

Tinjau semua kebijakan pra-definisi yang tersedia untuk kluster ACK: Predefined security policies of ACK
Batasi trafik antar pod dan antara pod ke server API dengan network policies: Use network policies in ACK clusters