Melakukan hardening pada keamanan cluster

Version 1.28 (latest)

• Versi 1.28 (terbaru)
• Versi 1.16
• Versi 1.15
• Versi sebelumnya (tidak didukung)

Dokumen ini menjelaskan cara melakukan hardening pada keamanan GKE pada cluster Bare Metal.

Mengamankan container Anda menggunakan SELinux

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

Menggunakan seccomp untuk membatasi penampung

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Mode komputasi yang aman (seccomp) tersedia dalam GKE versi 1.11 di Bare Metal dan yang lebih baru. Menjalankan container dengan profil seccomp akan meningkatkan keamanan cluster Anda karena membatasi panggilan sistem yang boleh dilakukan container ke kernel. Hal ini mengurangi kemungkinan kerentanan kernel yang dieksploitasi.

Profil seccomp default berisi daftar panggilan sistem yang diizinkan untuk dilakukan oleh penampung. Panggilan sistem apa pun yang tidak ada dalam daftar tidak diizinkan. seccomp diaktifkan secara default pada GKE versi 1.11 di Bare Metal. Ini berarti bahwa semua penampung sistem dan workload pelanggan dijalankan dengan profil seccomp default runtime container. Bahkan container dan workload yang tidak menentukan profil seccomp dalam file konfigurasinya akan dikenai pembatasan seccomp.

Cara menonaktifkan seccomp seluruh cluster atau pada beban kerja tertentu

Anda hanya dapat menonaktifkan seccomp selama pembuatan cluster atau upgrade cluster. bmctl update tidak dapat digunakan untuk menonaktifkan fitur ini. Jika 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 beban kerja Anda perlu mengeksekusi panggilan sistem yang diblokir seccomp secara default, Anda tidak perlu menonaktifkan seccomp di seluruh cluster. Sebagai gantinya, Anda dapat memilih workload tertentu untuk dijalankan di unconfined mode. Menjalankan workload di unconfined mode membebaskan workload tersebut dari pembatasan yang diterapkan oleh 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 menjalankan container sebagai pengguna root

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

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

Metode #1: menambahkan petunjuk USER di Dockerfile

Metode ini menggunakan Dockerfile untuk memastikan bahwa penampung tidak dijalankan sebagai pengguna root. Dalam Dockerfile, Anda dapat menentukan pengguna mana yang harus 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 container. Pengguna ini memiliki ID pengguna (UID) 8877.

Baris berikutnya dalam Dockerfile menjalankan perintah USER nonroot. Perintah ini menetapkan bahwa mulai titik ini dalam gambar, perintah akan dijalankan sebagai pengguna nonroot.

Berikan izin ke UID 8877 agar proses container dapat dijalankan dengan benar untuk nonroot.

Metode #2: menambahkan kolom securityContext di 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 akan diterapkan ke semua container dalam Pod.

Contoh berikut menunjukkan nukilan 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 setiap penampung dalam Pod, semua proses berjalan dengan ID pengguna 8877. Kolom runAsGroup menentukan bahwa proses ini memiliki ID grup utama (GID) dari 8877. Jangan lupa untuk memberikan izin yang diperlukan dan memadai ke UID 8877 agar proses container dapat dijalankan dengan benar.

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

Container sistem di GKE di Bare Metal membantu menginstal dan mengelola cluster. UID dan GID yang digunakan oleh penampung 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. Penampung sistem menggunakan UID dan GID dalam rentang startUIDRangeRootlessContainers hingga startUIDRangeRootlessContainers + 2999.

Contoh berikut menunjukkan nukilan 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 agar ruang UID dan GID yang digunakan oleh penampung sistem tidak tumpang tindih dengan ruang yang ditetapkan ke beban kerja pengguna.

Cara menonaktifkan mode tanpa root

Mulai dari GKE pada rilis Bare Metal 1.10, container bidang kontrol Kubernetes dan container sistem dijalankan sebagai pengguna non-root secara default. GKE pada Bare Metal menetapkan UID dan GID pengguna ini 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 GKE pada rilis Bare Metal 1.11, Anda dapat menonaktifkan mode rootless 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, beban kerja tidak boleh diberi izin untuk memodifikasi dirinya sendiri sejak awal. 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 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 pada GKE pada Bare Metal, Anda harus menetapkan parameter berikut di Constraint:

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

Nonaktifkan port hanya baca kubelet

Dimulai dengan rilis 1.15.0, GKE pada Bare Metal dinonaktifkan secara default pada port 10255, yaitu port hanya baca kubelet. Setiap beban kerja pelanggan yang dikonfigurasi untuk membaca data dari port kubelet 10255 yang tidak aman ini harus dimigrasikan untuk menggunakan port 10250 yang aman.

Port ini dinonaktifkan secara default untuk cluster yang dibuat dengan versi 1.15.0 atau yang lebih tinggi. Port hanya baca kubelet 10255 tetap dapat diakses untuk cluster yang dibuat dengan versi lebih rendah dari 1.15.0, bahkan setelah cluster diupgrade 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 tersebut mencakup informasi konfigurasi lengkap untuk semua Pod yang berjalan di Node, yang dapat berguna bagi penyerang. Laporan ini juga mengekspos informasi metrik dan status, yang dapat memberikan insight yang sensitif bagi bisnis.

Menonaktifkan port hanya baca kubelet direkomendasikan oleh CIS Kubernetes Benchmark.

Pemeliharaan

Memantau buletin keamanan dan mengupgrade cluster Anda adalah tindakan keamanan penting yang harus dilakukan setelah cluster Anda aktif dan berjalan.

Memantau buletin keamanan

Tim keamanan GKE memublikasikan buletin keamanan untuk kerentanan yang sangat serius dan sangat serius.

Buletin ini mengikuti skema penomoran kerentanan Google Cloud umum dan ditautkan dari halaman buletin Google Cloud utama dan GKE pada catatan rilis Bare Metal.

Gunakan feed XML ini untuk berlangganan buletin keamanan untuk GKE di Bare Metal dan produk terkait.

Saat tindakan pelanggan diperlukan untuk mengatasi kerentanan yang tinggi dan kritis ini, Google akan menghubungi pelanggan melalui email. Selain itu, Google mungkin juga menghubungi pelanggan dengan 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 GKE on Bare Metal menggabungkan peningkatan keamanan Kubernetes yang mengatasi kerentanan keamanan yang dapat memengaruhi cluster Anda.

Anda bertanggung jawab untuk terus memperbarui GKE di cluster Bare Metal. 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 otomatis memuat ulang file kubeconfig cluster. File kubeconfig mengautentikasi pengguna ke cluster. File kubeconfig ditambahkan ke direktori cluster saat Anda membuat cluster dengan bmctl. Nama dan jalur default-nya adalah bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig. Saat Anda mengupgrade cluster, file kubeconfig cluster tersebut akan otomatis diperpanjang. Jika tidak, file kubeconfig akan habis masa berlakunya satu tahun setelah dibuat.

Catatan: Hanya file kubeconfig untuk cluster yang sedang diupgrade yang akan diperpanjang. Jika, misalnya, Anda mengupgrade cluster admin yang mengelola tiga cluster pengguna, hanya file kubeconfig cluster admin yang dimuat ulang. Anda harus mengupgrade setiap cluster pengguna secara terpisah untuk me-refresh file kubeconfig masing-masing.

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

Menggunakan Kontrol Layanan VPC dengan Cloud Interconnect atau Cloud VPN

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

Cloud VPN menghubungkan jaringan peer dengan aman ke jaringan Virtual Private Cloud (VPC) Anda melalui koneksi VPN 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 menggunakan 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.

Perhatian: Kontrol Layanan VPC tidak kompatibel dengan konfigurasi proxy cluster. Jika Anda memilih menggunakan Kontrol Layanan VPC, jangan menentukan setelan proxy dalam spesifikasi cluster.

Untuk melindungi GKE sepenuhnya di Bare Metal, Anda perlu menggunakan VIP Terbatas dan menambahkan API berikut ke perimeter layanan:

• Artifact Registry API (artifactregistry.googleapis.com)
• API Resource Manager (cloudresourcemanager.googleapis.com)
• API Compute Engine (compute.googleapis.com)
• Hubungkan 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 untuk Ops API (opsconfigmonitoring.googleapis.com)
• API Kontrol Layanan (servicecontrol.googleapis.com)
• Cloud Storage API (storage.googleapis.com)

Saat Anda menggunakan bmctl untuk membuat atau mengupgrade cluster, gunakan tanda --skip-api-check untuk mengabaikan panggilan Service Usage API (serviceusage.googleapis.com). Service Usage API tidak didukung oleh Kontrol Layanan VPC.

Catatan: Anda tidak dapat membuat atau mengupgrade cluster di Google Cloud Console saat Kontrol Layanan VPC diaktifkan. Operasi gagal karena perintah bmctl register bootstrap tidak memiliki flag --skip-api-check. Jika Anda menggunakan Kontrol Layanan VPC, gunakan bmctl create cluster untuk membuat cluster, atau gunakan bmctl upgrade cluster untuk mengupgrade cluster.