Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, você encontra uma introdução para estabelecer boas práticas de segurança para
o Google Distributed Cloud. As orientações nesta página não têm o objetivo de fornecer uma lista abrangente de práticas recomendadas.
O uso de práticas recomendadas de segurança no Google Distributed Cloud envolve a aplicação
de conceitos do Kubernetes e do Google Kubernetes Engine (GKE), bem como conceitos
exclusivos do Google Distributed Cloud.
Segurança do Kubernetes
Recomendamos que você siga as diretrizes gerais de segurança do Kubernetes ao
usar o Google Distributed Cloud.
O Google Distributed Cloud estende o GKE para permitir que você crie
clusters do GKE nos seus próprios servidores Linux no local. Para saber mais sobre a segurança do GKE, consulte a visão geral de segurança do GKE. Como você está lendo, tenha em mente que, como seu plano de controle e os nós são executados no local, as sugestões para segurança do plano de controle e segurança do nó não se aplicam.
Segurança do Google Distributed Cloud
As seções a seguir fornecem orientações para estabelecer boas práticas de segurança
para o Google Distributed Cloud.
Segurança de hardware
Proteja seus data centers locais com recursos de segurança física e proteção padrão do setor.
Certifique-se de que o acesso à estação de trabalho do administrador
seja altamente restrito. A estação de trabalho do administrador armazena dados confidenciais, como
arquivos kubeconfig, chaves SSH e chaves da conta de serviço.
Segurança de nós
Atualize seu pacote de software e instale patches de segurança para manter seu sistema operacional atualizado.
Por padrão, o Google Distributed Cloud adiciona o repositório apt do Docker e a
chave GPG necessária aos nós do cluster. Como alternativa à adição de repositórios de pacotes a cada nó de cluster na implantação, é possível configurar o cluster para usar um repositório de pacotes privado para imagens de contêineres.
Novos recursos e funções que aproveitam as tecnologias
e a postura de segurança mais recentes.
Atualizações para pacotes de software e componentes.
Para reduzir a exposição externa e outros benefícios de segurança, é possível
configurar um espelho de registro para
instalar componentes do Google Distributed Cloud em uma cópia local do registro
público.
Proteja suas cargas de trabalho com
autorização binária.
A autorização binária é um serviço do
Google Cloud que fornece segurança de cadeia de fornecimento de software para aplicativos executados na nuvem. Com a autorização binária, é possível garantir que os processos internos que protegem a qualidade e a integridade do software sejam concluídos com êxito antes que um aplicativo seja implantado em seu ambiente de produção.
Use a federação de identidade da carga de trabalho para GKE
para conceder aos pods acesso aos recursos do Google Cloud. A federação de identidade da carga de trabalho para GKE
permite que uma conta de serviço do Kubernetes seja executada como uma conta de serviço do IAM. Os pods executados como conta de serviço do Kubernetes têm as permissões da conta de serviço do IAM.
Gerencie a identidade com o
serviço de identidade do GKE.
O Serviço de identidade do GKE é um serviço de autenticação que permite levar
as soluções de identidade atuais para autenticação em vários
ambientes da edição Enterprise do Google Kubernetes Engine (GKE). Você pode fazer login e usar os
clusters da Google Distributed Cloud pela linha de comando (todos os provedores) ou pelo
Console do Google Cloud (somente OIDC), usando seu provedor de identidade
atual.
Conecte-se a clusters registrados com o gateway do Connect. O
gateway do Connect se baseia no poder das frotas para permitir
que os usuários do GKE se conectem e executem comandos
nos clusters registrados do GKE de maneira simples, consistente e segura.
Segurança de credenciais
Rotacionar autoridades certificadoras
O Google Distributed Cloud usa certificados e chaves privadas para autenticar
e criptografar conexões entre componentes do sistema em clusters. Para manter a comunicação segura no cluster, rotacione as autoridades certificadoras do cluster de usuário
periodicamente e sempre que houver uma possível violação de segurança.
Use a geração de registros de auditoria do Kubernetes.
Com a geração de registros de auditoria, os administradores podem reter, consultar, processar
e alertar sobre eventos que ocorrem nos seus respectivos ambientes do Google Distributed Cloud.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-11-26 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)."]]
