Stay organized with collections
Save and categorize content based on your preferences.
This page provides an introduction to establishing good security practices for
Google Distributed Cloud. The guidance on this page is not intended to provide you with
a comprehensive list of best practices.
Using good practices for security on Google Distributed Cloud involves applying
concepts from Kubernetes and Google Kubernetes Engine (GKE), as well as concepts
that are unique to Google Distributed Cloud.
Kubernetes security
We recommend that you follow general Kubernetes guidelines for security when
you're using Google Distributed Cloud.
Google Distributed Cloud extends GKE to let you create
GKE clusters on your own Linux servers on your own premises. To
learn more about GKE security, see the GKE
security overview. As
you're reading, keep in mind that because your control plane and nodes run
on-premises, the suggestions for
control plane security
and node security
don't apply.
Google Distributed Cloud security
The following sections provide guidance for establishing good security practices
for Google Distributed Cloud.
Hardware security
Secure your on-premises data centers with industry standard physical
security and safety features.
Ensure that access to your admin workstation
is highly restricted. The admin workstation stores sensitive data such as
kubeconfig files, SSH keys, and service account keys.
Node security
Keep your operating system up-to-date by updating software packages and
installing security patches.
By default, Google Distributed Cloud adds the Docker apt repository and the
needed GPG key to your cluster nodes. As an alternative to adding adding
package repositories to each cluster node in your deployment, you can
configure your cluster to use a private package
repository for container images.
Isolate your traffic and data by using an admin and user cluster
deployment. This
deployment type helps you to achieve the following types of isolation:
Workload traffic is isolated from administrative, or management plane
traffic.
Cluster access is isolated by group or role.
Production workloads are isolated from development workloads.
New features and functions that take advantage of latest security
posture and technologies.
Updates for bundled software and components.
For reduced external exposure and other security benefits, you can
configure a registry mirror to
install Google Distributed Cloud components from a local copy of the public
registry.
Secure your workloads with
Binary Authorization.
Binary Authorization is a service on Google Cloud that provides software
supply-chain security for applications that run in the cloud. With
Binary Authorization, you can ensure that internal processes that safeguard the
quality and integrity of your software have successfully completed before an
application is deployed to your production environment.
Use Workload Identity Federation for GKE
to give Pods access to Google Cloud resources. Workload Identity Federation for GKE
allows a Kubernetes service account to run as an IAM service account. Pods
that run as the Kubernetes service account have the permissions of the IAM
service account.
Manage identity with
GKE Identity Service.
GKE Identity Service is an authentication service that lets you bring
your existing identity solutions for authentication to multiple
Google Kubernetes Engine (GKE) Enterprise edition environments. You can sign in to and use your
Google Distributed Cloud clusters from the command line (all providers) or from
the Google Cloud console (OIDC only), all using your existing identity
provider.
Connect to registered clusters with the
Connect gateway. The
Connect gateway builds on the power of fleets to let
GKE Enterprise users connect to and run commands against
registered clusters in a consistent and secure way.
Credential security
Rotate certificate
authorities.
Google Distributed Cloud uses certificates and private keys to authenticate
and encrypt connections between system components in clusters. To maintain
secure cluster communication, rotate your user cluster certificate
authorities periodically and whenever there is a possible security breach.
Rotate service account
keys. To
reduce the security risk caused by leaked keys, we recommend that you
regularly rotate your service keys.
Monitor your security
Use Kubernetes 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.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[],[],null,["# Security overview\n\nThis 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-------------------\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------------\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---------------------------------\n\nThe following sections provide guidance for establishing good security practices\nfor Google Distributed Cloud.\n\n### Hardware 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\n### Node 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\n### Cluster 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\n### Workload 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\n### Network 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\n### Authentication 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 Kubernetes Engine (GKE) Enterprise edition 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 GKE Enterprise users connect to and run commands against\n registered clusters in a consistent and secure way.\n\n### Credential 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\n### Monitor 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)."]]