Este documento descreve como reforçar a segurança dos seus clusters criados com o Google Distributed Cloud (apenas software) em hardware sem sistema operativo.
Proteja os seus contentores com o SELinux
Pode proteger os seus contentores ativando o SELinux, que é suportado para o Red Hat Enterprise Linux (RHEL). Se as suas máquinas anfitriãs estiverem a executar o RHEL e quiser ativar o SELinux para o seu cluster, tem de ativar o SELinux em todas as máquinas anfitriãs. Consulte o artigo Proteja os seus contentores com o SELinux para ver detalhes.
Use seccomp para restringir contentores
O modo de computação segura (seccomp) está disponível na versão 1.11 e superior do
Google Distributed Cloud. A execução de contentores com um perfil seccomp melhora a segurança do cluster porque restringe as chamadas do sistema que os contentores podem fazer ao kernel. Isto reduz a probabilidade de as vulnerabilidades do kernel serem exploradas.
O perfil seccomp predefinido contém uma lista de chamadas do sistema que um contentor pode fazer. Todas as chamadas do sistema que não estejam na lista são proibidas. seccomp
está ativado por predefinição em clusters da versão 1.11 e superiores. Isto significa que todos os contentores do sistema e cargas de trabalho do cliente são executados com o perfil seccomp predefinido do tempo de execução do contentor. Mesmo os contentores e as cargas de trabalho que não especificam um perfil nos respetivos ficheiros de configuração estão sujeitos a restrições.seccompseccomp
Como desativar o seccomp ao nível do cluster ou em cargas de trabalho específicas
Só pode desativar o seccomp durante a criação ou a atualização do cluster.
Não é possível usar o bmctl update para desativar esta funcionalidade. Se quiser desativar o
seccomp num cluster, adicione a seguinte secção clusterSecurity ao ficheiro de configuração do cluster:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: example
namespace: cluster-example
spec:
...
clusterSecurity:
enableSeccomp: false
...
No caso improvável de algumas das suas cargas de trabalho precisarem de executar chamadas de sistema que seccomp bloqueia por predefinição, não tem de desativar seccomp em todo o cluster. Em alternativa, pode destacar cargas de trabalho específicas para execução em
unconfined mode. A execução de uma carga de trabalho em unconfined mode liberta essa carga de trabalho das restrições que o perfil seccomp impõe ao resto do cluster.
Para executar um contentor no unconfined mode, adicione a seguinte secção securityContext ao manifesto do pod:
apiVersion: v1
kind: Pod
....
spec:
securityContext:
seccompProfile:
type: Unconfined
....
Não executar contentores como utilizador root
Por predefinição, os processos nos contentores são executados como root. Isto representa um potencial problema de segurança, porque se um processo sair do contentor, esse processo é executado como root na máquina anfitriã. Por conseguinte, é aconselhável executar todas as suas cargas de trabalho como um utilizador não root.
As secções seguintes descrevem duas formas de executar contentores como um utilizador não root.
Método n.º 1: adicione a instrução USER em Dockerfile
Este método usa um Dockerfile para garantir que os contentores não são executados como um utilizador root. Num Dockerfile, pode especificar como o processo dentro de um contentor deve ser executado. O fragmento seguinte de um Dockerfile mostra como fazê-lo:
....
#Add a user with userid 8877 and name nonroot
RUN useradd −u 8877 nonroot
#Run Container as nonroot
USER nonroot
....
Neste exemplo, o comando do Linux useradd -u cria um utilizador denominado nonroot no contentor. Este utilizador tem um User ID (UID) de 8877.
A linha seguinte no Dockerfile executa o comando USER nonroot. Este comando especifica que, a partir deste ponto na imagem, os comandos são executados como o utilizador nonroot.
Conceda autorizações ao UID 8877 para que os processos do contentor possam ser executados
corretamente para nonroot.
Método n.º 2: adicione campos securityContext no ficheiro de manifesto do Kubernetes
Este método usa um ficheiro de manifesto do Kubernetes para garantir que os contentores não são executados como um utilizador do root. As definições de segurança são especificadas para um pod e, por sua vez, aplicadas a todos os contentores no pod.
O exemplo seguinte mostra um excerto de um ficheiro de manifesto para um determinado Pod:
apiVersion: v1
kind: Pod
metadata:
name: name-of-pod
spec:
securityContext:
runAsUser: 8877
runAsGroup: 8877
....
O campo runAsUser especifica que, para todos os contentores no pod, todos os processos são executados com o ID do utilizador 8877. O campo runAsGroup especifica que estes processos têm um ID do grupo principal (GID) de 8877. Lembre-se de conceder as autorizações necessárias e suficientes ao UID 8877 para que os processos do contentor possam ser executados corretamente.
Isto garante que os processos num contentor são executados como UID 8877, que tem menos privilégios do que a raiz.
Os contentores do sistema no software Google Distributed Cloud apenas ajudam a instalar e gerir clusters. Os UIDs e os GIDs usados por estes contentores podem ser controlados pelo campo startUIDRangeRootlessContainers na especificação do cluster. O campo startUIDRangeRootlessContainers é um campo opcional que, se não for especificado, tem um valor de 2000. Os valores permitidos
para startUIDRangeRootlessContainers são 1000-57000. O valor de startUIDRangeRootlessContainers só pode ser alterado durante as atualizações. Os contentores do sistema usam os UIDs e os GIDs no intervalo de startUIDRangeRootlessContainers a startUIDRangeRootlessContainers + 2999.
O exemplo que se segue mostra um excerto de um ficheiro de manifesto para um recurso Cluster:
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: name-of-cluster
spec:
clusterSecurity:
startUIDRangeRootlessContainers: 5000
...
Escolha o valor para startUIDRangeRootlessContainers para que os espaços UID e GID usados pelos contentores do sistema não se sobreponham aos atribuídos às cargas de trabalho do utilizador.
Como desativar o modo sem acesso root
A partir da versão 1.10 do Google Distributed Cloud, os contentores do plano de controlo do Kubernetes e os contentores do sistema são executados como utilizadores não root por predefinição.
O Google Distributed Cloud atribui a estes utilizadores UIDs e GIDs no intervalo
2000-4999. No entanto, esta atribuição pode causar problemas se esses UIDs e
GIDs já tiverem sido atribuídos a processos em execução no seu ambiente.
A partir da versão 1.11, pode desativar o modo sem acesso de superutilizador quando atualiza o cluster. Quando o modo sem acesso de raiz está desativado, os contentores do plano de controlo do Kubernetes e os contentores do sistema são executados como o utilizador raiz.
Para desativar o modo sem acesso root, siga estes passos:
Adicione a seguinte secção
clusterSecurityao ficheiro de configuração do cluster:apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: example namespace: cluster-example spec: ... clusterSecurity: enableRootlessContainers: false ...Atualize o cluster. Para mais detalhes, consulte o artigo Atualize clusters.
Restrinja a capacidade de as cargas de trabalho se automodificarem
Determinadas cargas de trabalho do Kubernetes, especialmente cargas de trabalho do sistema, têm autorização para se automodificarem. Por exemplo, algumas cargas de trabalho são dimensionadas automaticamente na vertical. Embora seja conveniente, isto pode permitir que um atacante que já comprometeu um nó avance ainda mais no cluster. Por exemplo, um atacante pode ter uma carga de trabalho no próprio nó que se altera para ser executada como uma conta de serviço mais privilegiada que existe no mesmo espaço de nomes.
Idealmente, as cargas de trabalho não devem ter autorização para se modificarem a si próprias. Quando a automodificação é necessária, pode limitar as autorizações aplicando restrições do Gatekeeper ou do Policy Controller, como NoUpdateServiceAccount da biblioteca Gatekeeper de código aberto, que fornece várias políticas de segurança úteis.
Quando implementa políticas, normalmente, é necessário permitir que os controladores que gerem o ciclo de vida do cluster ignorem as políticas. Isto é necessário para que os controladores possam fazer alterações ao cluster, como aplicar atualizações do cluster. Por exemplo, se implementar a política NoUpdateServiceAccount nos seus clusters, tem de definir os seguintes parâmetros no Constraint:
parameters:
allowedGroups:
- system:masters
allowedUsers: []
Desative a porta só de leitura do kubelet
A partir da versão 1.15.0, o Google Distributed Cloud desativa por predefinição a porta
10255, a porta de leitura do kubelet. Todas as cargas de trabalho de clientes configuradas para ler dados desta porta kubelet não segura 10255 devem migrar para usar a porta kubelet segura 10250.
Apenas os clusters criados com a versão 1.15.0 ou superior têm esta porta desativada por predefinição. A porta só de leitura do kubelet 10255 permanece acessível para clusters criados com uma versão inferior a 1.15.0, mesmo após uma atualização do cluster para a versão 1.15.0 ou superior.
Esta alteração foi feita porque o kubelet divulga informações de baixa sensibilidade através da porta 10255, que não está autenticada. As informações incluem as informações de configuração completas de todos os pods em execução num nó, o que pode ser valioso para um atacante. Também expõe métricas e informações de estado, que podem fornecer estatísticas sensíveis para a empresa.
A desativação da porta só de leitura do kubelet é recomendada pela CIS Kubernetes Benchmark.
Manutenção
A monitorização dos boletins de segurança e a atualização dos clusters são medidas de segurança importantes a tomar assim que os clusters estiverem em funcionamento.
Monitorize boletins de segurança
A equipa de segurança do GKE publica boletins de segurança para vulnerabilidades de gravidade elevada e crítica.
Estes boletins seguem um esquema de numeração de vulnerabilidades comum e têm links a partir da página principal de boletins e das notas de lançamento. Google Cloud Google Cloud
Quando é necessária a ação do cliente para resolver estas vulnerabilidades elevadas e críticas, a Google contacta os clientes por email. Além disso, a Google também pode contactar os clientes com contratos de apoio técnico através dos canais de apoio técnico.
Para mais informações sobre como a Google gere as vulnerabilidades de segurança e as correções para o GKE, consulte o artigo Aplicação de patches de segurança.
Atualize clusters
O Kubernetes introduz regularmente novas funcionalidades de segurança e fornece patches de segurança. Os lançamentos do Google Distributed Cloud incorporam melhorias de segurança do Kubernetes que resolvem vulnerabilidades de segurança que podem afetar os seus clusters.
É responsável por manter os seus clusters atualizados. Para cada lançamento, reveja as notas de lançamento. Para minimizar os riscos de segurança para os seus clusters, planeie fazer atualizações para novos lançamentos de patches todos os meses e versões secundárias a cada quatro meses.
Uma das muitas vantagens da atualização de um cluster é que este atualiza automaticamente o ficheiro kubeconfig do cluster. O ficheiro kubeconfig autentica um utilizador num cluster. O ficheiro kubeconfig é adicionado ao diretório do cluster quando
cria um cluster com o bmctl. O nome e o caminho predefinidos são
bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Quando atualiza um cluster, o ficheiro kubeconfig desse cluster é renovado automaticamente. Caso contrário, o ficheiro kubeconfig expira um ano após a sua criação.
Para ver informações sobre como atualizar os seus clusters, consulte o artigo Atualize os seus clusters.
Use os VPC Service Controls com o Cloud Interconnect ou o Cloud VPN
O Cloud Interconnect oferece ligações de baixa latência e alta disponibilidade que lhe permitem transferir dados de forma fiável entre as suas máquinas bare metal no local e asGoogle Cloud redes da nuvem virtual privada (VPC). Para saber mais acerca do Cloud Interconnect, consulte a vista geral do aprovisionamento do Dedicated Interconnect.
O Cloud VPN liga em segurança a sua rede de pares à sua rede de nuvem virtual privada (VPC) através de uma ligação IPsec VPN. Para saber mais sobre a Cloud VPN, consulte a vista geral da Cloud VPN.
O VPC Service Controls funciona com o Cloud Interconnect ou o Cloud VPN para oferecer segurança adicional aos seus clusters. Os VPC Service Controls ajudam a mitigar o risco de exfiltração de dados. Com os VPC Service Controls, pode adicionar projetos a perímetros de serviço que protegem recursos e serviços de pedidos originados fora do perímetro. Para saber mais sobre os perímetros de serviço, consulte o artigo Detalhes e configuração do perímetro de serviço.
Para proteger totalmente os clusters criados com o Google Distributed Cloud, tem de usar o VIP restrito e adicionar as seguintes APIs ao perímetro de serviço:
- API Artifact Registry (
artifactregistry.googleapis.com) - API Resource Manager (
cloudresourcemanager.googleapis.com) - API Compute Engine (
compute.googleapis.com) - API do gateway de ligação (
connectgateway.googleapis.com) - API Google Container Registry (
containerregistry.googleapis.com) - API GKE Connect (
gkeconnect.googleapis.com) - GKE Hub API (
gkehub.googleapis.com) - API GKE On-Prem (
gkeonprem.googleapis.com) - API Identity and Access Management (IAM) (
iam.googleapis.com) - Cloud Logging API (
logging.googleapis.com) - Cloud Monitoring API (
monitoring.googleapis.com) - Config Monitoring for Ops API (
opsconfigmonitoring.googleapis.com) - API Service Control (
servicecontrol.googleapis.com) - API Cloud Storage (
storage.googleapis.com)