Melakukan hardening pada keamanan cluster Anda

Dokumen ini menjelaskan cara memperkuat keamanan cluster yang dibuat dengan Google Distributed Cloud (khusus software) di bare metal.

Mengamankan container Anda menggunakan SELinux

Anda dapat mengamankan penampung dengan mengaktifkan SELinux, yang didukung untuk Red Hat Enterprise Linux (RHEL). Jika mesin host Anda menjalankan RHEL dan Anda ingin mengaktifkan SELinux untuk cluster, Anda harus mengaktifkan SELinux di semua mesin host. Lihat mengamankan container Anda menggunakan SELinux untuk mengetahui detailnya.

Menggunakan seccomp untuk membatasi container

Mode komputasi aman (seccomp) tersedia di Google Distributed Cloud versi 1.11 dan yang lebih baru. Menjalankan container dengan profil seccomp meningkatkan keamanan cluster Anda karena membatasi panggilan sistem yang diizinkan untuk dilakukan container ke kernel. Hal ini mengurangi kemungkinan kerentanan kernel dieksploitasi.

Profil seccomp default berisi daftar panggilan sistem yang diizinkan untuk dilakukan oleh container. Semua panggilan sistem yang tidak ada dalam daftar tidak diizinkan. seccomp diaktifkan secara default di cluster versi 1.11 dan yang lebih tinggi. Artinya, semua container sistem dan beban kerja pelanggan dijalankan dengan profil seccomp default runtime container. Bahkan, container dan workload yang tidak menentukan profil seccomp dalam file konfigurasinya tunduk pada batasan seccomp.

Cara menonaktifkan seccomp di seluruh cluster atau pada workload tertentu

Anda hanya dapat menonaktifkan seccomp selama pembuatan cluster atau upgrade cluster. bmctl update tidak dapat digunakan untuk menonaktifkan fitur ini. Jika Anda ingin menonaktifkan seccomp dalam cluster, tambahkan bagian clusterSecurity berikut ke file konfigurasi cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: example
  namespace: cluster-example
spec:
...
  clusterSecurity:
    enableSeccomp: false
...

Jika beberapa workload Anda perlu mengeksekusi panggilan sistem yang diblokir secara default oleh seccomp, Anda tidak perlu menonaktifkan seccomp di seluruh cluster. Sebagai gantinya, Anda dapat memilih workload tertentu untuk dijalankan di unconfined mode. Menjalankan beban kerja di unconfined mode membebaskan beban kerja tersebut dari batasan yang diterapkan profil seccomp pada cluster lainnya.

Untuk menjalankan container di unconfined mode, tambahkan bagian securityContext berikut ke manifes Pod:

apiVersion: v1
kind: Pod
....
spec:
  securityContext:
    seccompProfile:
      type: Unconfined
....

Jangan jalankan container sebagai pengguna root

Secara default, proses dalam container dijalankan sebagai root. Hal ini menimbulkan potensi masalah keamanan, karena jika proses keluar dari container, proses tersebut berjalan sebagai root di mesin host. Oleh karena itu, sebaiknya jalankan semua beban kerja Anda sebagai pengguna non-root.

Bagian berikut menjelaskan dua cara menjalankan container sebagai pengguna non-root.

Metode #1: tambahkan instruksi USER di Dockerfile

Metode ini menggunakan Dockerfile untuk memastikan bahwa container tidak berjalan sebagai pengguna root. Dalam Dockerfile, Anda dapat menentukan pengguna yang akan menjalankan proses di dalam container. Cuplikan berikut dari Dockerfile menunjukkan cara melakukannya:

....

#Add a user with userid 8877 and name nonroot
RUN useradd −u 8877 nonroot

#Run Container as nonroot
USER nonroot
....

Dalam contoh ini, perintah Linux useradd -u membuat pengguna bernama nonroot di dalam penampung. Pengguna ini memiliki ID pengguna (UID) 8877.

Baris berikutnya di Dockerfile menjalankan perintah USER nonroot. Perintah ini menentukan bahwa mulai dari titik ini di image, perintah dijalankan sebagai pengguna nonroot.

Berikan izin ke UID 8877 agar proses penampung dapat dieksekusi dengan benar untuk nonroot.

Metode #2: menambahkan kolom securityContext dalam file manifes Kubernetes

Metode ini menggunakan file manifes Kubernetes untuk memastikan bahwa container tidak berjalan sebagai pengguna root. Setelan keamanan ditentukan untuk Pod, dan setelan keamanan tersebut diterapkan ke semua container dalam Pod.

Contoh berikut menunjukkan kutipan file manifes untuk Pod tertentu:

apiVersion: v1
kind: Pod
metadata:
  name: name-of-pod
spec:
  securityContext:
    runAsUser: 8877
    runAsGroup: 8877
....

Kolom runAsUser menentukan bahwa untuk semua container dalam Pod, semua proses dijalankan dengan ID pengguna 8877. Kolom runAsGroup menentukan bahwa proses ini memiliki ID grup (GID) utama 8877. Jangan lupa untuk memberikan izin yang diperlukan dan memadai ke UID 8877 agar proses penampung dapat dieksekusi dengan benar.

Hal ini memastikan bahwa proses dalam container dijalankan sebagai UID 8877, yang memiliki lebih sedikit hak istimewa daripada root.

Container sistem di Google Distributed Cloud khusus software membantu menginstal dan mengelola cluster. UID dan GID yang digunakan oleh container ini dapat dikontrol oleh kolom startUIDRangeRootlessContainers dalam spesifikasi cluster. startUIDRangeRootlessContainers adalah kolom opsional yang, jika tidak ditentukan, memiliki nilai 2000. Nilai yang diizinkan untuk startUIDRangeRootlessContainers adalah 1000-57000. Nilai startUIDRangeRootlessContainers hanya dapat diubah selama upgrade. Container sistem menggunakan UID dan GID dalam rentang startUIDRangeRootlessContainers hingga startUIDRangeRootlessContainers + 2999.

Contoh berikut menunjukkan kutipan file manifes untuk resource Cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: name-of-cluster
spec:
 clusterSecurity:
    startUIDRangeRootlessContainers: 5000
...

Pilih nilai untuk startUIDRangeRootlessContainers sehingga ruang UID dan GID yang digunakan oleh container sistem tidak tumpang-tindih dengan yang ditetapkan ke beban kerja pengguna.

Cara menonaktifkan mode tanpa root

Mulai dari rilis Google Distributed Cloud 1.10, container bidang kontrol Kubernetes dan container sistem berjalan sebagai pengguna non-root secara default. Google Distributed Cloud menetapkan UID dan GID ini kepada pengguna dalam rentang 2000-4999. Namun, penetapan ini dapat menyebabkan masalah jika UID dan GID tersebut telah dialokasikan ke proses yang berjalan di dalam lingkungan Anda.

Mulai dari rilis 1.11, Anda dapat menonaktifkan mode tanpa root saat mengupgrade cluster. Jika mode tanpa root dinonaktifkan, container bidang kontrol Kubernetes dan container sistem akan berjalan sebagai pengguna root.

Untuk menonaktifkan mode tanpa root, lakukan langkah-langkah berikut:

  1. Tambahkan bagian clusterSecurity berikut ke file konfigurasi cluster:

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: example
      namespace: cluster-example
    spec:
    ...
      clusterSecurity:
        enableRootlessContainers: false
    ...
    
  2. Upgrade cluster Anda. Untuk mengetahui detailnya, lihat Mengupgrade cluster.

Membatasi kemampuan workload dalam modifikasi mandiri

Workload Kubernetes tertentu, terutama workload sistem, memiliki izin untuk menjalankan modifikasi mandiri Sebagai contoh, beberapa workload melakukan penskalaan otomatis secara vertikal. Meskipun berguna, ini akan memungkinkan penyerang yang telah menyusupi node untuk menjelajahi cluster lebih dalam lagi. Misalnya, penyerang dapat membuat workload pada node melakukan modifikasi mandiri untuk dijalankan sebagai akun layanan dengan hak istimewa yang berada di namespace yang sama.

Idealnya, workload seharusnya sejak awal tidak diizinkan untuk melakukan modifikasi mandiri. Jika memerlukan modifikasi mandiri, Anda dapat membatasi izin dengan menerapkan batasan Pemilah Komunikasi atau Pengontrol Kebijakan, seperti NoUpdateServiceAccount dari library open source Pemilah Komunikasi, yang memberikan beberapa solusi keamanan bermanfaat.

Saat Anda men-deploy kebijakan, biasanya Anda perlu mengizinkan pengontrol yang mengelola siklus proses cluster untuk mengabaikan kebijakan tersebut. Hal ini diperlukan agar pengontrol dapat membuat perubahan pada cluster, seperti menerapkan upgrade cluster. Misalnya, jika Anda men-deploy kebijakan NoUpdateServiceAccount di cluster, Anda harus menetapkan parameter berikut di Constraint:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers: []

Menonaktifkan port hanya baca kubelet

Mulai rilis 1.15.0, Google Distributed Cloud menonaktifkan port 10255, port hanya baca kubelet, secara default. Setiap workload pelanggan yang dikonfigurasi untuk membaca data dari port kubelet yang tidak aman ini 10255 harus dimigrasikan untuk menggunakan port kubelet yang aman 10250.

Hanya cluster yang dibuat dengan versi 1.15.0 atau yang lebih tinggi yang menonaktifkan port ini secara default. Port hanya baca kubelet 10255 tetap dapat diakses untuk cluster yang dibuat dengan versi di bawah 1.15.0, bahkan setelah upgrade cluster ke versi 1.15.0 atau yang lebih tinggi.

Perubahan ini dilakukan karena kubelet membocorkan informasi sensitivitas rendah melalui port 10255, yang tidak diautentikasi. Informasi ini mencakup informasi konfigurasi lengkap untuk semua Pod yang berjalan di Node, yang dapat dimanfaatkan oleh penyerang. API ini juga mengekspos metrik dan informasi status, yang dapat memberikan insight sensitif bisnis.

Menonaktifkan port hanya baca kubelet direkomendasikan oleh Tolok Ukur Kubernetes CIS.

Pemeliharaan

Memantau buletin keamanan dan mengupgrade cluster Anda adalah langkah-langkah keamanan penting yang harus dilakukan setelah cluster Anda siap dan berjalan.

Memantau buletin keamanan

Tim keamanan GKE memublikasikan buletin keamanan untuk kerentanan tingkat keparahan tinggi dan penting.

Buletin ini mengikuti skema penomoran kerentanan Google Cloud yang umum dan ditautkan dari halaman Google Cloud buletin utama dan catatan rilis.

Gunakan feed XML ini untuk berlangganan buletin keamanan untuk Google Kubernetes Engine (GKE) dan produk terkait. Berlangganan

Saat tindakan pelanggan diperlukan untuk mengatasi kerentanan tinggi dan penting ini, Google akan menghubungi pelanggan melalui email. Selain itu, Google juga dapat menghubungi pelanggan yang memiliki kontrak dukungan melalui saluran dukungan.

Untuk mengetahui informasi selengkapnya tentang cara Google mengelola kerentanan dan patch keamanan untuk GKE dan GKE Enterprise, lihat Patching keamanan.

Mengupgrade cluster

Kubernetes secara rutin memperkenalkan fitur keamanan baru dan menyediakan patch keamanan. Rilis Google Distributed Cloud menyertakan peningkatan keamanan Kubernetes yang menangani kerentanan keamanan yang dapat memengaruhi cluster Anda.

Anda bertanggung jawab untuk menjaga agar cluster Anda tetap diupdate. Untuk setiap rilis, tinjau catatan rilis. Untuk meminimalkan risiko keamanan pada cluster Anda, rencanakan untuk mengupdate ke rilis patch baru setiap bulan dan versi minor setiap empat bulan.

Salah satu dari banyak keuntungan mengupgrade cluster adalah cluster tersebut secara otomatis memperbarui file kubeconfig cluster. File kubeconfig mengautentikasi pengguna ke cluster. File kubeconfig ditambahkan ke direktori cluster Anda saat Anda membuat cluster dengan bmctl. Nama dan jalur defaultnya adalah bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig. Saat Anda mengupgrade cluster, file kubeconfig cluster tersebut akan diperbarui secara otomatis. Jika tidak, file kubeconfig akan habis masa berlakunya satu tahun setelah dibuat.

Untuk mengetahui informasi tentang cara mengupgrade cluster, lihat mengupgrade cluster.

Menggunakan Kontrol Layanan VPC dengan Cloud Interconnect atau Cloud VPN

Cloud Interconnect menyediakan koneksi berlatensi rendah dan ketersediaan tinggi yang memungkinkan Anda mentransfer data dengan andal antara mesin bare metal lokal dan Google Cloud jaringan Virtual Private Cloud (VPC). Untuk mempelajari lebih lanjut Cloud Interconnect, lihat Ringkasan penyediaan Dedicated Interconnect.

Cloud VPN menghubungkan jaringan peer dengan aman ke jaringan Virtual Private Cloud (VPC) melalui koneksi IPsec IPsec. Untuk mempelajari Cloud VPN lebih lanjut, lihat Ringkasan Cloud VPN.

Kontrol Layanan VPC berfungsi dengan Cloud Interconnect atau Cloud VPN untuk memberikan keamanan tambahan bagi cluster Anda. Kontrol Layanan VPC membantu mengurangi risiko pemindahan data yang tidak sah. Dengan Kontrol Layanan VPC, Anda dapat menambahkan project ke perimeter layanan yang melindungi resource dan layanan dari permintaan yang berasal dari luar perimeter. Untuk mempelajari perimeter layanan lebih lanjut, lihat Detail dan konfigurasi perimeter layanan.

Untuk melindungi sepenuhnya cluster yang dibuat dengan Google Distributed Cloud, Anda harus menggunakan VIP Terbatas dan menambahkan API berikut ke perimeter layanan:

  • Artifact Registry API (artifactregistry.googleapis.com)
  • Resource Manager API (cloudresourcemanager.googleapis.com)
  • Compute Engine API (compute.googleapis.com)
  • Connect Gateway API (connectgateway.googleapis.com)
  • Google Container Registry API (containerregistry.googleapis.com)
  • GKE Connect API (gkeconnect.googleapis.com)
  • GKE Hub API (gkehub.googleapis.com)
  • GKE On-Prem API (gkeonprem.googleapis.com)
  • Identity and Access Management (IAM) API (iam.googleapis.com)
  • Cloud Logging API (logging.googleapis.com)
  • Cloud Monitoring API (monitoring.googleapis.com)
  • Config Monitoring for Ops API (opsconfigmonitoring.googleapis.com)
  • Service Control API (servicecontrol.googleapis.com)
  • Cloud Storage API (storage.googleapis.com)