Dokumen ini menjelaskan cara memperkuat keamanan Google Distributed Cloud klaster.
Mengamankan container Anda menggunakan SELinux
Anda dapat mengamankan container dengan mengaktifkan SELinux, yang didukung untuk warna Red Hat Enterprise Linux (RHEL). Jika mesin {i>host<i} Anda menjalankan RHEL dan Anda ingin untuk mengaktifkan SELinux untuk cluster Anda, Anda harus mengaktifkan SELinux di semua host Anda mesin Linux dan Windows. Lihat mengamankan penampung Anda menggunakan SELinux untuk mengetahui detailnya.
Menggunakan seccomp
untuk membatasi penampung
Mode komputasi aman (seccomp
) tersedia di versi 1.11
Google Distributed Cloud dan yang lebih tinggi. Menjalankan container dengan profil seccomp
akan meningkatkan keamanan cluster karena membatasi panggilan sistem yang
container apa saja yang diizinkan
untuk membuat {i>kernel<i}. Ini mengurangi kemungkinan terjadinya {i>kernel<i}
kerentanan yang dieksploitasi.
Profil seccomp
default berisi daftar panggilan sistem yang merupakan
yang diperbolehkan untuk dibuat. Panggilan sistem apa pun yang tidak ada dalam daftar tidak diizinkan. seccomp
diaktifkan secara default di Google Distributed Cloud versi 1.11. Ini berarti bahwa semua
container sistem dan workload pelanggan dijalankan dengan runtime container
profil seccomp
default. Bahkan container dan workload yang tidak menentukan
Profil seccomp
di file konfigurasinya tunduk kepada seccomp
pembatasan.
Cara menonaktifkan seccomp
di seluruh cluster atau pada workload tertentu
Anda dapat menonaktifkan seccomp
hanya 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 bagian
file konfigurasi cluster Anda:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: example
namespace: cluster-example
spec:
...
clusterSecurity:
enableSeccomp: false
...
Jika beberapa workload Anda perlu menjalankan sistem,
panggilan yang diblokir seccomp
secara default, Anda tidak perlu menonaktifkan seccomp
di
seluruh gugus. Sebagai gantinya, Anda dapat memilih workload tertentu untuk dijalankan
unconfined mode
. Menjalankan beban kerja di unconfined mode
akan membebaskan beban kerja tersebut
dari batasan yang diberlakukan oleh profil seccomp
pada
.
Untuk menjalankan penampung di unconfined mode
, tambahkan 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
keamanan, karena jika sebuah proses keluar dari kontainer, proses tersebut
berjalan sebagai root
di mesin host. Oleh karena itu, disarankan untuk menjalankan semua
workload sebagai pengguna non-root.
Bagian berikut ini menjelaskan dua cara untuk menjalankan container sebagai non-root .
Metode #1: menambahkan instruksi USER
di Dockerfile
Metode ini menggunakan Dockerfile
untuk memastikan bahwa container tidak berjalan sebagai root
. Pada Dockerfile
, Anda dapat menentukan pengguna mana yang diproses di dalam penampung
harus dijalankan sebagai. Cuplikan Dockerfile
berikut 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 yang disebut nonroot
ke dalam container. Pengguna ini memiliki ID pengguna (UID) 8877
.
Baris berikutnya di Dockerfile
menjalankan perintah USER nonroot
. Perintah ini
menetapkan bahwa mulai saat ini dalam gambar, perintah dijalankan sebagai pengguna
nonroot
.
Berikan izin ke UID 8877
agar proses container dapat dijalankan
dengan benar untuk nonroot
.
Metode #2: menambahkan kolom securityContext dalam file manifes Kubernetes
Metode ini menggunakan file manifes Kubernetes untuk memastikan bahwa container tidak dijalankan
sebagai pengguna root
. Setelan keamanan ditentukan untuk Pod, dan setelan keamanan tersebut
setelan ini kemudian diterapkan ke semua container di 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 setiap container di Pod,
proses yang berjalan dengan ID pengguna 8877
. Kolom runAsGroup
menentukan bahwa
proses memiliki ID grup (GID) utama 8877
. Ingatlah untuk memberikan
izin yang diperlukan dan memadai ke UID 8877
sehingga container
proses dapat berjalan dengan benar.
Ini memastikan bahwa proses dalam container dijalankan sebagai UID 8877
, yang memiliki
lebih sedikit hak istimewa
daripada {i>root<i}.
Container sistem di Google Distributed Cloud membantu menginstal dan mengelola cluster.
UID dan GID yang digunakan oleh penampung ini dapat dikontrol oleh kolom
startUIDRangeRootlessContainers
dalam spesifikasi cluster. Tujuan
startUIDRangeRootlessContainers
adalah kolom opsional yang jika tidak ditentukan,
memiliki nilai 2000
. Nilai yang diizinkan untuk startUIDRangeRootlessContainers
adalah
1000
—57000
. Nilai startUIDRangeRootlessContainers
dapat diubah
hanya selama peningkatan versi. Penampung sistem menggunakan UID dan GID dalam rentang
startUIDRangeRootlessContainers
hingga startUIDRangeRootlessContainers
+ 2999.
Contoh berikut menunjukkan kutipan file manifes untuk Cluster referensi:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: name-of-cluster
spec:
clusterSecurity:
startUIDRangeRootlessContainers: 5000
...
Pilih nilai untuk startUIDRangeRootlessContainers
agar UID dan GID
ruang yang digunakan oleh penampung sistem tidak tumpang tindih dengan ruang yang ditetapkan untuk pengguna
sebagian besar workload standar
dan berbasis cloud.
Cara menonaktifkan mode root
Mulai dari rilis Google Distributed Cloud 1.10, bidang kontrol Kubernetes
container dan container sistem dijalankan
sebagai pengguna non-root secara {i>default<i}.
Google Distributed Cloud menetapkan UID dan GID untuk pengguna ini dalam rentang tersebut
2000
—4999
. Namun, penetapan ini dapat menyebabkan
masalah jika UID dan
GID telah dialokasikan untuk proses yang berjalan di dalam lingkungan Anda.
Mulai rilis Google Distributed Cloud 1.11, Anda dapat menonaktifkan rootless saat mengupgrade cluster. Saat mode rootless dinonaktifkan, Kubernetes kontainer bidang kontrol dan kontainer sistem berjalan sebagai pengguna {i>root<i}.
Untuk menonaktifkan mode rootless, lakukan langkah-langkah berikut:
Tambahkan bagian
clusterSecurity
berikut ke konfigurasi cluster file:apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: example namespace: cluster-example spec: ... clusterSecurity: enableRootlessContainers: false ...
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 sendiri fitur tersebut. 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. Hal ini diperlukan agar
pengontrol dapat membuat perubahan pada cluster, seperti menerapkan upgrade
cluster. Misalnya, jika Anda men-deploy kebijakan NoUpdateServiceAccount
pada
Google Distributed Cloud, Anda harus menetapkan parameter berikut di Constraint
:
parameters:
allowedGroups:
- system:masters
allowedUsers: []
Nonaktifkan port hanya baca kubelet
Mulai rilis 1.15.0, Google Distributed Cloud dinonaktifkan secara default pada port
10255
, port hanya baca kubelet. Setiap beban kerja pelanggan
yang dikonfigurasi untuk
membaca data dari port kubelet yang tidak aman ini 10255
harus dimigrasikan untuk menggunakan
kubelet port 10250.
Hanya cluster yang dibuat dengan versi 1.15.0 atau lebih tinggi yang menonaktifkan port ini oleh
secara default. Port hanya baca kubelet 10255
tetap dapat diakses untuk cluster
dibuat dengan versi yang lebih rendah dari 1.15.0, bahkan setelah cluster diupgrade ke
versi 1.15.0 atau yang lebih tinggi.
Perubahan ini dibuat karena kubelet membocorkan
informasi sensitivitas rendah pada
port 10255
, yang tidak diautentikasi. Informasi tersebut meliputi seluruh
informasi konfigurasi untuk semua Pod yang berjalan di Node, yang bisa berguna
terhadap penyerang. Dasbor juga mengekspos metrik
dan informasi status, yang dapat
memberikan insight yang sensitif terhadap bisnis.
Penonaktifan port hanya baca kubelet direkomendasikan oleh CIS Kubernetes {i>Benchmark<i}.
Pemeliharaan
Memantau buletin keamanan dan mengupgrade cluster Anda adalah keamanan yang penting tindakan yang perlu diambil setelah klaster Anda aktif dan berjalan.
Memantau buletin keamanan
Tim keamanan GKE memublikasikan buletin keamanan kerentanan dengan tingkat keparahan yang tinggi dan kritis.
Buletin ini mengikuti penomoran kerentanan Google Cloud umum dan ditautkan dari halaman buletin Google Cloud utama dan Catatan rilis Google Distributed Cloud.
Ketika tindakan pelanggan diperlukan untuk mengatasi masalah ini, kerentanan, Google akan menghubungi pelanggan melalui email. Selain itu, Google mungkin juga menghubungi pelanggan dengan kontrak dukungan melalui saluran dukungan.
Untuk informasi selengkapnya tentang cara Google mengelola kerentanan keamanan dan patch untuk GKE dan GKE Enterprise, lihat Patching keamanan.
Upgrade cluster
Kubernetes secara rutin memperkenalkan fitur keamanan baru dan memberikan keamanan patching. Rilis Google Distributed Cloud menggabungkan keamanan Kubernetes penyempurnaan untuk mengatasi kerentanan keamanan yang dapat memengaruhi cluster Anda.
Anda bertanggung jawab untuk menjaga agar cluster Google Distributed Cloud Anda selalu tanggal. Untuk setiap rilis, tinjau catatan rilis. Untuk meminimalkan risiko keamanan pada cluster Anda, rencanakan untuk mengupdate ke patch baru dirilis setiap bulan dan versi minor setiap empat bulan.
Salah satu dari banyak keuntungan upgrade cluster adalah cluster tersebut secara otomatis
memperbarui file kubeconfig cluster. File {i>kubeconfig<i} mengautentikasi
pengguna ke cluster. File {i>kubeconfig<i} ditambahkan ke direktori cluster Anda 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, masa berlaku file kubeconfig akan berakhir 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 latensi rendah dan ketersediaan tinggi yang memungkinkan Anda mentransfer data dengan andal antara mesin bare metal lokal dan Jaringan Virtual Private Cloud (VPC) Google Cloud. Untuk mempelajari lebih lanjut tentang Cloud Interconnect, lihat Penyediaan Dedicated Interconnect ringkasan.
Cloud VPN menghubungkan jaringan peer Anda dengan aman ke Jaringan Virtual Private Cloud (VPC) melalui IPsec VPN koneksi jarak jauh. 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 untuk 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 lebih lanjut perimeter layanan, lihat Detail perimeter layanan dan konfigurasi.
Untuk melindungi Google Distributed Cloud sepenuhnya, 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 --skip-api-check
untuk mengabaikan panggilan Service Usage API (serviceusage.googleapis.com
).
Service Usage API tidak didukung oleh Kontrol Layanan VPC.