Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini memberikan pengantar untuk menerapkan praktik keamanan yang baik untuk
Google Distributed Cloud. Panduan di halaman ini tidak dimaksudkan untuk memberi Anda
daftar lengkap praktik terbaik.
Menggunakan praktik terbaik untuk keamanan di Google Distributed Cloud melibatkan penerapan konsep dari Kubernetes dan Google Kubernetes Engine (GKE), serta konsep yang unik untuk Google Distributed Cloud.
Keamanan Kubernetes
Sebaiknya ikuti panduan umum Kubernetes untuk keamanan saat Anda menggunakan Google Distributed Cloud.
Google Distributed Cloud memperluas GKE untuk memungkinkan Anda membuat cluster GKE di server Linux Anda sendiri di lokasi Anda sendiri. Untuk
mempelajari lebih lanjut keamanan GKE, lihat ringkasan
keamanan GKE. Saat
membaca, perlu diingat bahwa karena bidang kontrol dan node Anda berjalan
di tempat, saran untuk
keamanan bidang kontrol
dan keamanan node
tidak berlaku.
Keamanan Google Distributed Cloud
Bagian berikut memberikan panduan untuk menerapkan praktik keamanan yang baik untuk Google Distributed Cloud.
Keamanan hardware
Amankan pusat data lokal Anda dengan fitur keamanan dan keselamatan fisik standar industri.
Pastikan akses ke workstation admin Anda sangat dibatasi. Workstation admin menyimpan data sensitif seperti file kubeconfig, kunci SSH, dan kunci akun layanan.
Keamanan node
Selalu update sistem operasi Anda dengan mengupdate paket software dan menginstal patch keamanan.
Secara default, Google Distributed Cloud menambahkan repositori Docker apt dan kunci GPG yang diperlukan ke node cluster Anda. Sebagai alternatif untuk menambahkan repositori paket ke setiap node cluster dalam deployment, Anda dapat mengonfigurasi cluster untuk menggunakan repositori paket pribadi untuk image container.
Pisahkan traffic dan data Anda dengan menggunakan deployment cluster admin dan pengguna. Jenis
deployment ini membantu Anda mencapai jenis isolasi berikut:
Traffic workload diisolasi dari traffic administratif atau bidang pengelolaan.
Akses cluster diisolasi menurut grup atau peran.
Workload produksi diisolasi dari workload pengembangan.
Fitur dan fungsi baru yang memanfaatkan teknologi dan postur keamanan terbaru.
Update untuk software dan komponen yang disertakan.
Untuk mengurangi eksposur eksternal dan manfaat keamanan lainnya, Anda dapat mengonfigurasi mirror registri untuk menginstal komponen Google Distributed Cloud dari salinan lokal registri publik.
Amankan beban kerja Anda dengan
Otorisasi Biner.
Otorisasi Biner adalah layanan di Google Cloud yang menyediakan keamanan supply chain software untuk aplikasi yang berjalan di cloud. Dengan Otorisasi Biner, Anda dapat memastikan bahwa proses internal yang menjaga kualitas dan integritas software telah berhasil diselesaikan sebelum aplikasi di-deploy ke lingkungan produksi.
Gunakan Workload Identity Federation for GKE
untuk memberi Pod akses ke Google Cloud resource. Workload Identity Federation untuk GKE memungkinkan akun layanan Kubernetes berjalan sebagai akun layanan IAM. Pod
yang dijalankan sebagai akun layanan Kubernetes memiliki izin akun layanan IAM.
Mengelola identitas dengan
GKE Identity Service.
GKE Identity Service adalah layanan autentikasi yang memungkinkan Anda membawa solusi identitas yang sudah ada untuk autentikasi ke beberapaGoogle Cloud lingkungan. Anda dapat login ke dan menggunakan cluster Google Distributed Cloud dari command line (semua penyedia) atau dari konsol Google Cloud (khusus OIDC), semuanya menggunakan penyedia identitas yang sudah ada.
Hubungkan ke cluster terdaftar dengan
gateway Connect. Gateway
Connect dibangun berdasarkan kemampuan fleet untuk memungkinkan
pengguna terhubung dan menjalankan perintah terhadap cluster terdaftar dengan cara yang
konsisten dan aman.
Keamanan kredensial
Rotasi otoritas sertifikat.
Google Distributed Cloud menggunakan sertifikat dan kunci pribadi untuk mengautentikasi
dan mengenkripsi koneksi antara komponen sistem dalam cluster. Untuk mempertahankan komunikasi cluster yang aman, rotasi otoritas sertifikat cluster pengguna Anda secara berkala dan setiap kali ada kemungkinan pelanggaran keamanan.
Merotasi kunci akun layanan. Untuk
mengurangi risiko keamanan yang disebabkan oleh kebocoran kunci, sebaiknya Anda
merotasi kunci layanan secara rutin.
Memantau keamanan Anda
Menggunakan logging audit Kubernetes.
Logging audit memungkinkan administrator menyimpan, membuat kueri, memproses, dan memberi tahu peristiwa yang terjadi di lingkungan Google Distributed Cloud Anda.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[],[],null,["This page provides an introduction to establishing good security practices for\nGoogle Distributed Cloud. The guidance on this page is not intended to provide you with\na comprehensive list of best practices.\n\nUsing good practices for security on Google Distributed Cloud involves applying\nconcepts from Kubernetes and Google Kubernetes Engine (GKE), as well as concepts\nthat are unique to Google Distributed Cloud.\n\nKubernetes security\n\nWe recommend that you follow general Kubernetes guidelines for security when\nyou're using Google Distributed Cloud.\n\nFor an introduction to Kubernetes security guidelines, see the [Security\nChecklist](https://kubernetes.io/docs/concepts/security/security-checklist/)\nand [Overview of Cloud Native\nSecurity](https://kubernetes.io/docs/concepts/security/overview/)\nin the Kubernetes documentation.\n\nGKE security\n\nGoogle Distributed Cloud extends GKE to let you create\nGKE clusters on your own Linux servers on your own premises. To\nlearn more about GKE security, see the [GKE\nsecurity overview](/kubernetes-engine/docs/concepts/security-overview). As\nyou're reading, keep in mind that because your control plane and nodes run\non-premises, the suggestions for\n[control plane security](/kubernetes-engine/docs/concepts/security-overview#control_plane_security)\nand [node security](/kubernetes-engine/docs/concepts/security-overview#node_security)\ndon't apply.\n\nGoogle Distributed Cloud security\n\nThe following sections provide guidance for establishing good security practices\nfor Google Distributed Cloud.\n\nHardware security\n\n- Secure your on-premises data centers with industry standard physical\n security and safety features.\n\n- Ensure that access to your [admin workstation](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/workstation-prerequisites)\n is highly restricted. The admin workstation stores sensitive data such as\n `kubeconfig` files, SSH keys, and service account keys.\n\nNode security\n\n- Keep your operating system up-to-date by updating software packages and\n installing security patches.\n\n- For added control over workload image pulls and related security benefits,\n you can [configure worker nodes to authenticate to a private registry](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/configure-node-private-reg). Private registry support\n for nodes is available for [Preview](/products#product-launch-stages) for\n version 1.29 clusters.\n\n- By default, Google Distributed Cloud adds the Docker `apt` repository and the\n needed GPG key to your cluster nodes. As an alternative to adding adding\n package repositories to each cluster node in your deployment, you can\n configure your cluster to [use a private package\n repository](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/package-server) for container images.\n\nCluster security\n\n- [Harden the security of your Google Distributed Cloud\n clusters](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/hardening-your-cluster).\n\n- Isolate your traffic and data by using an [admin and user cluster\n deployment](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/install-prep#admin_user_model). This\n deployment type helps you to achieve the following types of isolation:\n\n - Workload traffic is isolated from administrative, or management plane traffic.\n - Cluster access is isolated by group or role.\n - Production workloads are isolated from development workloads.\n- [Upgrade your clusters](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/upgrade-best-practices) to a\n [supported version](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support#version-support). Using a\n supported version provides you with the following security benefits:\n\n - Fixes for security vulnerabilities.\n - New features and functions that take advantage of latest security posture and technologies.\n - Updates for bundled software and components.\n- For reduced external exposure and other security benefits, you can\n [configure a registry mirror](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/registry-mirror) to\n install Google Distributed Cloud components from a local copy of the public\n registry.\n\nWorkload security\n\n- [Secure your containers using Security-Enhanced Linux\n (SELinux)](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/configure-selinux).\n\n- [Secure your workloads with\n Binary Authorization](/binary-authorization/docs/overview-on-prem).\n Binary Authorization is a service on Google Cloud that provides software\n supply-chain security for applications that run in the cloud. With\n Binary Authorization, you can ensure that internal processes that safeguard the\n quality and integrity of your software have successfully completed before an\n application is deployed to your production environment.\n\n- Use [Workload Identity Federation for GKE](/kubernetes-engine/docs/how-to/workload-identity)\n to give Pods access to Google Cloud resources. Workload Identity Federation for GKE\n allows a Kubernetes service account to run as an IAM service account. Pods\n that run as the Kubernetes service account have the permissions of the IAM\n service account.\n\n- [Follow the best practices for GKE\n RBAC](/kubernetes-engine/docs/best-practices/rbac).\n\nNetwork security\n\n- [Choose a secure connection between your Google Distributed Cloud and\n Google Cloud](/kubernetes-engine/distributed-cloud/bare-metal/docs/concepts/connect-on-prem-gcp#enhancing_your_fundamental_connection).\n After your fundamental connection is in place, add features that enhance the\n security of your connection.\n\n- Limit the exposure of your clusters to the public internet by [installing\n them behind a proxy and creating firewall\n rules](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/proxy). Also use\n the appropriate controls in your network environment to limit public access\n to the cluster.\n\nAuthentication security\n\n- [Manage identity with\n GKE Identity Service](/kubernetes-engine/distributed-cloud/bare-metal/docs/installing/identity-manage).\n GKE Identity Service is an authentication service that lets you bring\n your existing identity solutions for authentication to multiple\n Google Cloud environments. You can sign in to and use your\n Google Distributed Cloud clusters from the command line (all providers) or from\n the Google Cloud console (OIDC only), all using your existing identity\n provider.\n\n- [Connect to registered clusters with the\n Connect gateway](/kubernetes-engine/enterprise/multicluster-management/gateway). The\n Connect gateway builds on the power of fleets to let\n users connect to and run commands against registered clusters in a\n consistent and secure way.\n\nCredential security\n\n- [Rotate certificate\n authorities](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/ca-rotation).\n Google Distributed Cloud uses certificates and private keys to authenticate\n and encrypt connections between system components in clusters. To maintain\n secure cluster communication, rotate your user cluster certificate\n authorities periodically and whenever there is a possible security breach.\n\n- [Rotate service account\n keys](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/update-secrets). To\n reduce the security risk caused by leaked keys, we recommend that you\n regularly rotate your service keys.\n\nMonitor your security\n\n- [Use Kubernetes audit\n logging](/kubernetes-engine/distributed-cloud/bare-metal/docs/how-to/audit-logging). Audit logging provides a way for administrators to retain, query, process, and alert on events that occur in your Google Distributed Cloud environments.\n\nFor more information about monitoring cluster security, see\n[Monitor fleet security posture](/kubernetes-engine/fleet-management/docs/secure#monitor-fleets-scale)."]]
