Container Service for Kubernetes：Keamanan Pod

Cegah proses keluar dari batas kontainer dan mendapatkan izin

Jika Anda seorang developer atau insinyur O&M yang menggunakan Kubernetes, sangat penting untuk mencegah proses di dalam kontainer keluar dari batas isolasinya dan mengakses host. Hal ini penting karena dua alasan utama:

• Pertama, proses di dalam kontainer secara default berjalan dalam konteks pengguna Linux root. Meskipun operasi pengguna root di dalam kontainer sebagian dibatasi oleh Linux capabilities yang diberikan Docker kepada kontainer, izin default ini berpotensi memungkinkan penyerang melakukan peningkatan hak istimewa atau mengakses informasi sensitif pada host. Informasi tersebut mencakup resource sensitif seperti objek Secrets dan ConfigMap. Berikut adalah daftar capabilities default yang diberikan kepada kontainer Docker. Untuk informasi lebih lanjut, lihat capabilities(7) — Linux manual page.

  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.

  Hindari menjalankan pod dengan status istimewa (privileged) sebisa mungkin, karena status tersebut memberikan semua capabilities Linux yang terkait dengan pengguna root pada host.

• Kedua, semua node pekerja Kubernetes menggunakan mode otorisasi yang disebut node authorizer. Node authorizer memberikan izin untuk semua permintaan API yang berasal dari Kubelet dan memungkinkan sebuah node melakukan operasi berikut:

  Operasi Baca:

  • Layanan

  • Titik Akhir

  • Node

  • Pods

  • Secrets, ConfigMaps, PersistentVolumes (PVs), dan PersistentVolumeClaims (PVCs) yang terkait dengan pod yang terikat pada node Kubelet tersebut

  Operasi Tulis:

  • Nodes dan status node (Aktifkan plugin admission NodeRestriction untuk membatasi Kubelet hanya mengubah objek nodenya sendiri)

  • Pods dan status pod (Aktifkan plugin admission NodeRestriction untuk membatasi Kubelet hanya mengubah pod yang terikat padanya)

  • Peristiwa

  Operasi terkait autentikasi:

  • Akses baca/tulis ke API CertificateSigningRequest (CSR) untuk TLS bootstrapping

  • Kemampuan membuat TokenReview dan SubjectAccessReview untuk pemeriksaan otentikasi identitas dan otorisasi yang didelegasikan

Kluster ACK secara default menggunakan admission controller Node Restriction. Controller ini hanya mengizinkan sebuah node untuk mengubah sekumpulan terbatas properti node dan objek pod yang terikat padanya. Namun, penyerang yang berhasil mengakses host tetap dapat mengambil informasi sensitif dari lingkungan melalui API Kubernetes. Untuk informasi lebih lanjut, lihat Node Restriction admission controller.

Rekomendasi konfigurasi keamanan pod

• Restrict containers from running in privileged mode

  Seperti disebutkan sebelumnya, kontainer yang berjalan dengan status istimewa mewarisi semua capabilities Linux yang diberikan kepada pengguna root pada host. Dalam sebagian besar skenario, kontainer tidak memerlukan izin ini untuk berfungsi dengan benar. Anda dapat membuat kebijakan keamanan pod untuk menolak pod yang dikonfigurasi berjalan dalam mode istimewa. Kebijakan keamanan pod adalah serangkaian batasan keamanan yang harus dipenuhi oleh pod sebelum dapat dibuat. ACK menyediakan kemampuan container security policy berbasis Open Policy Agent (OPA) dan Gatekeeper. Kemampuan ini memvalidasi permintaan pembuatan dan pembaruan pod pada kluster berdasarkan aturan keamanan yang dikonfigurasi pengguna. Jika permintaan pembuatan atau pembaruan pod tidak mematuhi aturan yang ditetapkan, sistem akan menolak permintaan tersebut dan mengembalikan error. Demikian pula, Anda dapat menerapkan kebijakan ACKPSPPrivilegedContainer untuk membatasi penerapan kontainer istimewa di namespace tertentu dalam kluster.

• Restrict application processes from running as the root user

  Secara default, kontainer berjalan sebagai pengguna root. Hal ini dapat menjadi masalah keamanan jika penyerang mengeksploitasi kerentanan pada aplikasi dan mendapatkan akses shell ke kontainer yang sedang berjalan. Anda dapat mengurangi risiko ini dengan beberapa cara. Salah satunya adalah menghapus shell dari gambar kontainer. Cara lain adalah menambahkan instruksi USER ke Dockerfile Anda atau menjalankan kontainer dalam pod sebagai pengguna non-root. Spesifikasi pod Kubernetes (podSpec) berisi field spec.securityContext, runAsUser, dan runAsGroup. Field-field ini memungkinkan Anda menentukan pengguna dan grup untuk menjalankan aplikasi. Anda dapat membuat kebijakan ACKPSPAllowedUsers untuk menegakkan pembatasan ini.

• Forbid running containers in Docker-in-Docker mode or mounting Docker.sock in a container

  Menggunakan kontainer bersarang atau memasang Docker.sock memudahkan pembuatan atau menjalankan gambar kontainer di dalam kontainer Docker. Namun, hal ini memberikan kendali penuh atas node kepada proses yang berjalan di dalam kontainer. Untuk informasi lebih lanjut tentang pembuatan gambar kontainer di Kubernetes, lihat Build an image using an Enterprise Edition instance, Kaniko, dan img.

• Restrict the use of HostPath, and if you must use it, only mount directories with a specified prefix and configure the volume as read-only

  Anda dapat menggunakan HostPath untuk langsung memasang direktori host ke dalam kontainer. Fitur ini hanya diperlukan dalam beberapa skenario bisnis. Jika bisnis Anda memerlukan fitur ini, Anda harus memahami risiko yang terkait. Secara default, pod yang berjalan sebagai root memiliki akses tulis ke sistem file yang diekspos oleh HostPath. Akses ini dapat memungkinkan penyerang memodifikasi pengaturan Kubelet, membuat tautan simbolik ke direktori atau file yang tidak secara langsung diekspos melalui HostPath (seperti /etc/shadow), menginstal kunci SSH, membaca rahasia yang dipasang pada host, dan melakukan tindakan berbahaya lainnya. Untuk mengurangi risiko penggunaan HostPath, Anda dapat mengatur field spec.containers.volumeMounts menjadi read-only. Contohnya:

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

  Demikian pula, Anda dapat menerapkan instance kebijakan ACKPSPHostFilesystem untuk membatasi rentang direktori host yang boleh dipasang oleh pod yang diterapkan di namespace tertentu dalam kluster.

• Set requests and resource limits for each container to avoid resource contention or DoS attacks

  Pod tanpa requests atau batas resource secara teoretis dapat mengonsumsi seluruh resource yang tersedia pada host. Jika pod tersebut dijadwalkan ke node ini, node tersebut mungkin mengalami kekurangan CPU atau memori. Hal ini dapat menyebabkan Kubelet crash atau mengeluarkan pod lain dari node tersebut. Meskipun hal ini tidak dapat dihindari sepenuhnya, menetapkan requests dan batas resource membantu meminimalkan konflik sumber daya. Hal ini juga mengurangi risiko konsumsi resource berlebihan akibat aplikasi yang ditulis dengan buruk.

  PodSpec memungkinkan Anda membatasi penggunaan CPU dan memori. Anda dapat menegakkan batasan requests dan resource dengan menetapkan Resource Quota atau membuat Limit Range pada namespace. Kuota sumber daya memungkinkan Anda menentukan jumlah total resource, seperti CPU dan RAM, yang dialokasikan ke namespace. Saat diterapkan pada namespace, kuota ini mewajibkan Anda menentukan requests dan batas untuk semua kontainer yang diterapkan di namespace tersebut. Sebaliknya, limit range memberikan kontrol alokasi sumber daya yang lebih detail halus. Dengan limit range, Anda dapat menetapkan resource CPU dan memori minimum serta maksimum untuk setiap pod atau kontainer dalam namespace. Anda juga dapat menetapkan nilai request dan batas default jika tidak ada nilai yang diberikan. Untuk informasi lebih lanjut, lihat Managing Resources for Containers.

  Demikian pula, Anda dapat menerapkan instance kebijakan ACKContainerLimits untuk mewajibkan pod aplikasi yang diterapkan di namespace tertentu dalam kluster memiliki konfigurasi batas resource.

• Disable privilege escalation configurations

  Peningkatan hak istimewa memungkinkan proses mengubah konteks keamanan tempat proses tersebut berjalan. Contohnya termasuk sudo dan file biner dengan bit SUID atau SGID. Peningkatan hak istimewa memungkinkan pengguna mengeksekusi file dengan izin pengguna atau grup lain. Anda dapat mencegah kontainer melakukan peningkatan hak istimewa menggunakan kebijakan keamanan pod yang mengatur allowPrivilegeEscalation ke false, atau dengan mengatur securityContext.allowPrivilegeEscalation dalam podSpec.

  Demikian pula, Anda dapat menerapkan instance kebijakan ACKPSPAllowPrivilegeEscalationContainer untuk mewajibkan pod yang diterapkan di namespace tertentu dalam kluster memiliki parameter allowPrivilegeEscalation yang dikonfigurasi.

• Disable automatic mounting of Service Account tokens

  Untuk pod yang tidak perlu mengakses API Kubernetes, Anda dapat menonaktifkan pemasangan otomatis token ServiceAccount pada PodSpec. Anda juga dapat menonaktifkannya untuk semua pod yang menggunakan ServiceAccount tertentu.

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

  Menonaktifkan pemasangan otomatis ServiceAccount tidak memblokir akses jaringan pod ke API Kubernetes. Untuk memblokir akses jaringan pod ke API Kubernetes, Anda dapat mengubah metode akses Endpoint kluster ACK dan menggunakan kebijakan jaringan untuk memblokir akses jaringan pod tersebut. Untuk informasi lebih lanjut, lihat Use network policies in an ACK cluster.

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

  Demikian pula, Anda dapat menerapkan instance kebijakan ACKBlockAutomountToken untuk mewajibkan field automountServiceAccountToken: false ditetapkan pada pod aplikasi guna mencegah pemasangan otomatis Service Account.

• Disable service discovery

  Untuk pod yang tidak perlu menemukan atau memanggil layanan kluster, Anda dapat membatasi informasi yang diberikan ke pod tersebut. Anda dapat mengatur kebijakan DNS pod agar tidak menggunakan CoreDNS dan mencegah Services di namespace diekspos sebagai variabel lingkungan di dalam pod. Untuk informasi lebih lanjut, lihat Environment variables.

  Nilai default kebijakan DNS pod adalah ClusterFirst, yang menggunakan DNS dalam kluster. Nilai Default bukanlah pengaturan default sebenarnya dan mengonfigurasi pod untuk menggunakan resolusi DNS dari node dasar. Untuk informasi lebih lanjut, lihat Kubernetes docs on Pod DNS policy.

  Menonaktifkan service links dan mengubah kebijakan DNS pod tidak memblokir akses jaringan pod ke layanan DNS dalam kluster. Penyerang masih dapat mencantumkan layanan dalam kluster dengan mengakses layanan DNS dalam kluster (misalnya: dig SRV *.*.svc.cluster.local @$CLUSTER_DNS_IP). Untuk memblokir penemuan layanan dalam kluster, lihat Use network policies in an ACK cluster.

  apiVersion: v1
  kind: Pod
  metadata:
    name: pod-no-service-info
  spec:
      dnsPolicy: Default # Nilai "Default" bukan nilai default sebenarnya.
      enableServiceLinks: false
  ...

• Configure images to have a read-only file system

  Anda dapat mengonfigurasi citra Anda agar memiliki sistem file read-only untuk mencegah penyerang menimpa file pada sistem file yang digunakan aplikasi Anda. Jika aplikasi Anda harus menulis ke sistem file, Anda dapat menulis ke direktori temporary atau memasang volume tambahan. Anda dapat menegakkan hal ini dengan mengatur SecurityContext pod sebagai berikut:

  ...
  securityContext:
    readOnlyRootFilesystem: true
  ...

  Demikian pula, Anda dapat menerapkan instance kebijakan ACKPSPReadOnlyRootFilesystem untuk membatasi pod yang diterapkan di namespace tertentu dalam kluster agar hanya menggunakan sistem file root read-only.