Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Diese Seite bietet eine Einführung in die Etablierung guter Sicherheitspraktiken für Google Distributed Cloud Die Informationen auf dieser Seite sind keine umfassende Liste von Best Practices.
Die Anwendung von Best Practices für die Sicherheit in Google Distributed Cloud umfasst die Anwendung von Konzepten aus Kubernetes und Google Kubernetes Engine (GKE) sowie Konzepte, die es nur bei Google Distributed Cloud gibt.
Kubernetes-Sicherheit
Wir empfehlen Ihnen, die allgemeinen Sicherheitsrichtlinien von Kubernetes zu befolgen, wenn Sie Google Distributed Cloud verwenden.
Google Distributed Cloud erweitert die GKE insofern, als Sie GKE-Cluster lokal auf Ihren eigenen Linux-Servern erstellen können. Weitere Informationen zur GKE-Sicherheit finden Sie unter GKE-Sicherheitsübersicht. Denken Sie beim Lesen daran, dass die Vorschläge für die Sicherheit der Steuerungsebeneund die Knotensicherheit nicht zutreffen, da Ihre Steuerungsebene und Knoten vor Ort ausgeführt werden.
Sicherheit von Google Distributed Cloud
In den folgenden Abschnitten finden Sie Informationen dazu, wie Sie bewährte Sicherheitspraktiken für Google Distributed Cloud festlegen.
Hardwaresicherheit
Schützen Sie Ihre Rechenzentren vor Ort mit branchenüblichen physischen Sicherheits- und Schutzfunktionen.
Achten Sie darauf, dass der Zugriff auf Ihre Administrator-Workstation stark eingeschränkt ist. Die Administrator-Workstation speichert sensible Daten wie kubeconfig-Dateien, SSH-Schlüssel und Dienstkontoschlüssel.
Knotensicherheit
Halten Sie Ihr Betriebssystem auf dem neuesten Stand, indem Sie Softwarepakete aktualisieren und Sicherheits-Patches installieren.
Google Distributed Cloud fügt Ihren Clusterknoten standardmäßig das Docker-Repository apt und den erforderlichen GPG-Schlüssel hinzu. Als Alternative zum Hinzufügen von Paket-Repositories zu jedem Clusterknoten in Ihrer Bereitstellung können Sie Ihren Cluster für die Verwendung eines privaten Paket-Repositorys für Container-Images konfigurieren.
Neue Features und Funktionen, die die neuesten Sicherheitsfunktionen und -technologien nutzen.
Updates für gebündelte Software und Komponenten.
Für eine geringere externe Sichtbarkeit und andere Sicherheitsvorteile können Sie eine Registry-Spiegelung konfigurieren, um Google Distributed Cloud-Komponenten aus einer lokalen Kopie der öffentlichen Registry zu installieren.
Arbeitslasten mit Binärautorisierung schützen.
Die Binärautorisierung ist ein Dienst in der Cloud Console, der Softwarelieferkettensicherheit für Anwendungen in der Cloud bietet. Mit der Binärautorisierung werden interne Prozesse, die die Qualität und Integrität Ihrer Software gewährleisten, erfolgreich abgeschlossen, bevor eine Anwendung in Ihrer Produktionsumgebung bereitgestellt wird.
Workload Identity verwenden, um Pods Zugriff auf Google Cloud-Ressourcen zu gewähren. Mit Workload Identity kann ein Kubernetes-Dienstkonto als IAM-Dienstkonto ausgeführt werden. Pods, die als Kubernetes-Dienstkonto ausgeführt werden, haben die Berechtigungen des IAM-Dienstkontos.
Schränken Sie die Gefährdung Ihrer Cluster im öffentlichen Internet ein, indem Sie sie hinter einem Proxy installieren und Firewallregeln erstellen. Verwenden Sie auch die entsprechenden Kontrollen in Ihrer Netzwerkumgebung, um den öffentlichen Zugriff auf den Cluster zu beschränken.
Authentifizierungssicherheit
Identität mit GKE Identity Service verwalten.
GKE Identity Service ist ein Authentifizierungsdienst, mit dem Sie Ihre bestehenden Identitätslösungen zur Authentifizierung in mehrere Umgebungen der Google Kubernetes Engine (GKE) Enterprise Edition einbringen können. Sie können sich bei Ihren Google Distributed Cloud-Clustern über die Befehlszeile (alle Anbieter) oder über die Google Cloud-Konsole (nur OIDC) anmelden und diese nutzen. Dabei verwenden Sie Ihren bestehenden Identitätsanbieter.
Verbindung zu registrierten Clustern mit dem Connect-Gateway. Der Connect-Gateway baut auf der Leistungsfähigkeit von Flotten auf und ermöglicht es GKE Enterprise- Nutzern, sich mit registrierten Clustern zu verbinden und Befehle auf konsistente und sichere Weise auszuführen.
Sicherheit von Anmeldedaten
Zertifizierungsstellen rotieren
Google Distributed Cloud verwendet Zertifikate und private Schlüssel zur Authentifizierung und Verschlüsselung von Verbindungen zwischen Systemkomponenten in Clustern. Für eine sichere Clusterkommunikation sollten Sie die Zertifizierungsstelle Ihres Nutzerclusters regelmäßig und bei einem möglichen Sicherheitsverstoß rotieren.
Dienstkontoschlüssel rotieren Um das Sicherheitsrisiko durch gehackte Schlüssel zu verringern, sollten Sie Ihre Dienstschlüssel regelmäßig zu rotieren.
Ihre Sicherheit überwachen
Kubernetes Audit-Logging verwenden
Mit Audit-Logging können Administratoren Ereignisse in Ihren Google Distributed Cloud-Umgebungen speichern, abfragen, verarbeiten und melden.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-08-30 (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)."]]
