Tutorial: proteger o GKE Enterprise

Como configurar o ambiente do Cloud Shell

Neste tutorial, você usará a linha de comando do Cloud Shell e o editor para fazer alterações na configuração do cluster.

Para inicializar o ambiente shell para o tutorial, a implantação de amostra do Anthos fornece um script que realiza as seguintes ações:

• Instala todas as ferramentas de linha de comando ausentes para trabalhar de forma interativa e verificar as alterações na implantação:

  • kubectl
  • kubectx
  • istioctl
  • nomos

• Define o contexto do Kubernetes para anthos-sample-cluster1

• Clona o repositório que o Config Sync usa para sincronizar suas alterações de configuração no cluster. As alterações confirmadas e enviadas por push ao repositório upstream são sincronizadas com a infraestrutura pelo Config Sync. Essa é a prática recomendada para aplicar alterações à sua infraestrutura.

Para configurar o ambiente:

1. Verifique se você tem uma sessão ativa do Cloud Shell. É possível iniciar o Cloud Shell clicando em Ativar o Cloud Shell no console do Google Cloud no seu projeto de tutorial.

2. Crie um diretório no qual trabalhar:

   mkdir tutorial
   cd tutorial
   

3. Faça o download do script de inicialização:

   curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env
   

4. Crie o script de inicialização no seu ambiente do Cloud Shell:

   source init-anthos-sample-deployment.env
   

   Saída:

   /google/google-cloud-sdk/bin/gcloud
   /google/google-cloud-sdk/bin/kubectl
   Your active configuration is: [cloudshell-13605]
   export PROJECT as anthos-launch-demo-1
   export KUBECONFIG as ~/.kube/anthos-launch-demo-1.anthos-trial-gcp.config
   Fetching cluster endpoint and auth data.
   kubeconfig entry generated for anthos-sample-cluster1.
   Copying gs://config-management-release/released/latest/linux_amd64/nomos...
   \ [1 files][ 40.9 MiB/ 40.9 MiB]
   Operation completed over 1 objects/40.9 MiB.
   Installed nomos into ~/bin.
   Cloned ACM config repo: ./anthos-sample-deployment-config-repo
   

5. Altere o diretório para o repositório de configuração e use-o como o diretório de trabalho do restante deste tutorial:

   cd anthos-sample-deployment-config-repo
   

Como aplicar mTLS na malha de serviço

Antes da expansão global, seu CIO exigia que todos os dados do usuário fossem criptografados em trânsito para proteger informações confidenciais em conformidade com a legislação regional de criptografia e privacidade de dados.

Então, seu tráfego está seguro no momento?

1. Acesse a página Cloud Service Mesh no seu projeto onde a implantação de amostra do Anthos está implantada:

   Acessar a página do Cloud Service Mesh

2. Clique em transactionhistory na lista de serviços. Como você viu em Explorar o GKE Enterprise, a página de detalhes do serviço mostra toda a telemetria disponível para esse serviço.

3. Na página transactionhistory, no menu Navegação, selecione Serviços conectados. Você pode ver as conexões Entrada e Saída do serviço. Um ícone de cadeado desbloqueado indica que algum tráfego foi observado nessa porta que não está usando o TLS mútuo (mTLS).

mTLS é um protocolo de segurança que garante que o tráfego seja seguro e confiável em ambas as direções entre dois serviços. Cada serviço aceita somente tráfego criptografado de serviços autenticados. Como você pode ver, o Cloud Service Mesh mostra claramente que o tráfego não está criptografado na sua malha. As cores são usadas no Cloud Service Mesh para indicar se o tráfego não criptografado tem uma combinação de texto simples e mTLS (laranja) ou apenas texto simples (vermelho).

Com o GKE Enterprise, você está a apenas algumas etapas de estar em conformidade. Em vez de fazer alterações no nível do código-fonte e recriar e reimplantar o aplicativo para lidar com essa situação, é possível aplicar a nova política de criptografia de maneira declarativa pela configuração usando o Config Sync para implantar automaticamente a nova configuração usando um repositório Git central.

Nesta seção, você fará o seguinte:

1. Ajuste a configuração da política no repositório Git para garantir que os serviços usem comunicações criptografadas por meio do mTLS.

2. Conte com o Config Sync para coletar automaticamente a alteração de política do repositório e ajustar a política do Cloud Service Mesh.

3. Verifique se a alteração da política ocorreu no cluster que está configurado para sincronizar com o repositório.

Confirmar configuração do Config Sync

1. O comando nomos é uma ferramenta de linha de comando que permite interagir com o Config Sync Operator e executar outras tarefas úteis do Config Synct a partir da máquina local ou Cloud Shell. Para verificar se o Config Management está instalado e configurado corretamente no cluster, execute nomos status:

   nomos status
   

   Saída:

   Connecting to clusters...
   Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
   -------   -------                  -----------  -----------------   -----------   ---------------
   *         anthos-sample-cluster1   SYNCED       abef0b01            master        Healthy
   

   A resposta confirma que o Config Sync está configurado para sincronizar o cluster com a ramificação principal do repositório de configuração. O asterisco na primeira coluna indica que o contexto atual é definido como anthos-sample-cluster1. Se você não encontrar isso, alterne o contexto atual para anthos-sample-cluster1:

   kubectl config use-context anthos-sample-cluster1
   

   Saída:

   Switched to context "anthos-sample-cluster1".
   

2. Verifique se você está na ramificação master:

   git checkout master
   

   Saída:

   Already on 'master'
   Your branch is up to date with 'origin/master'.
   

3. Verifique seu repositório de configuração upstream:

   git remote -v
   

   Saída:

   origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (fetch)
   origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (push)
   

4. Verifique se você ainda está no diretório anthos-sample-deployment-config-repo e execute o seguinte comando para verificar a configuração do git. Essa função auxiliar é originada no ambiente pelo script de inicialização e executa os comandos git config para verificar os valores user.email e user.name atuais da configuração do git. Se esses valores não estiverem configurados, a função definirá padrões no nível do repositório com base na conta do Google Cloud ativa no momento.

   init_git
   

   Saída (exemplo)

   Configured local git user.email to user@example.com
   Configured local git user.name to user
   

Agora você está pronto para confirmar alterações da política no seu repositório. Quando você envia essas confirmações para o repositório upstream (origem), o Config Sync garante que essas alterações sejam aplicadas ao cluster que você configurou para ele gerenciar.

Atualizar uma política para criptografar todo o tráfego de serviços

A configuração do Cloud Service Mesh é especificada de maneira declarativa usando arquivos YAML. Para criptografar todo o tráfego de serviços, modifique o YAML que especifica os tipos de tráfego que os serviços podem aceitar e o YAML que especifica o tipo de tráfego que os serviços enviam para determinados destinos.

1. O primeiro arquivo YAML que você precisa analisar é namespaces/istio-system/peer-authentication.yaml, que é uma política de autenticação no nível da malha que especifica os tipos de tráfego que todos os serviços na malha aceitam por padrão.

   cat namespaces/istio-system/peer-authentication.yaml
   

   Saída:

   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "default"
     namespace: "istio-system"
   spec:
     mtls:
       mode: PERMISSIVE
   

   Como você pode ver, o modo mTLS PeerAuthentication é PERMISSIVE, o que significa que os serviços aceitam tráfego HTTP e mTLS de texto simples.

2. Modifique namespaces/istio-system/peer-authentication.yaml para permitir apenas a comunicação criptografada entre os serviços definindo o modo mTLS como STRICT:

   cat <<EOF> namespaces/istio-system/peer-authentication.yaml
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "default"
     namespace: "istio-system"
   spec:
     mtls:
       mode: STRICT
   EOF
   

3. Em seguida, observe a Regra de destino em namespaces/istio-system/destination-rule.yaml. Ele especifica regras para enviar tráfego para os destinos especificados, inclusive se o tráfego é criptografado. Observe que o TLSmode é DISABLE, o que significa que o tráfego é enviado em texto simples para todos os hosts correspondentes.

   cat namespaces/istio-system/destination-rule.yaml
   

   Saída:

   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     annotations:
       meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
     name: default
     namespace: istio-system
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: DISABLE
   

4. Modifique namespaces/istio-system/destination-rule.yaml para que o Istio defina uma política de tráfego que ative o TLS para todos os hosts correspondentes no cluster usando o TLSmode ISTIO_MUTUAL:

   cat <<EOF> namespaces/istio-system/destination-rule.yaml
   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     annotations:
       meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
     name: default
     namespace: istio-system
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: ISTIO_MUTUAL
   EOF
   

Enviar suas alterações para o repositório

Você está quase pronto para enviar as alterações de configuração. No entanto, recomendamos algumas verificações antes de confirmar as atualizações.

1. Execute nomos vet para garantir que a configuração seja válida:

   nomos vet
   

   Nenhuma saída indica que não houve erros de validação.

2. Assim que você enviar as alterações, o Config Sync as escolherá e as aplicará ao sistema. Para evitar resultados inesperados, recomendamos verificar se o estado atual ativo da sua configuração não mudou desde que você fez edições. Usar kubectl para verificar se destinationrule reflete que o mTLS está desativado para o cluster:

   kubectl get destinationrule default -n istio-system -o yaml
   

   Saída:

   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   ...
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: DISABLE
   

3. Agora, confirme e envie essas alterações para o repositório upstream. O comando a seguir usa uma função auxiliar chamada watchmtls que foi originada no ambiente pelo script init. Essa função auxiliar executa uma combinação de nomos status com o comando kubectl que você tentou anteriormente. Ela observa o cluster em busca de alterações até você pressionar Ctrl+C para sair. Monitore a exibição até ver que as alterações foram aplicadas e sincronizadas no cluster.

   git commit -am "enable mtls"
   git push origin master && watchmtls
   

   Também é possível exibir as alterações refletidas nas páginas do Cloud Service Mesh no GKE Enterprise.

   Acessar a página do Cloud Service Mesh

   Você verá que o ícone de cadeado vermelho desbloqueado foi alterado. O ícone de cadeado aparece laranja (tráfego misto) em vez de verde (tráfego totalmente criptografado) porque estamos procurando por padrão na última hora com uma combinação de mTLS e texto simples. Se você verificar novamente após uma hora, verá um cadeado verde que indica que todo o tráfego de serviço foi criptografado.

Como usar o Policy Controller para configurar proteções

Sua equipe de segurança está preocupada com possíveis ataques raiz que podem ocorrer ao executar pods com contêineres privilegiados (contêineres com acesso raiz). Embora a configuração atual não implante contêineres privilegiados, você quer proteger o máximo possível de vetores de ameaças que podem comprometer o desempenho ou, pior ainda, os dados do cliente.

Apesar da investigação da equipe, você ainda pode estar vulnerável a ataques raiz inadvertidamente a partir de futuras atualizações de configuração por meio do processo de entrega contínua. Você decide configurar uma proteção de segurança para se proteger contra esse perigo.

Aplicar proteções

As proteções são controles administrativos automatizados, destinados a aplicar políticas que protegem seu ambiente. O Policy Controller inclui suporte para definir e aplicar regras personalizadas não cobertas por objetos nativos do Kubernetes. O Policy Controller verifica, audita e aplica proteções que correspondem aos requisitos exclusivos de segurança, conformidade regulatória e governança da sua organização.

Usar o Policy Controller

O Policy Controller do Config Management foi desenvolvido em um mecanismo de política de código aberto chamado Gatekeeper, que é usado para impor políticas sempre que um recurso no cluster é criado, atualizado ou excluído. Essas políticas são definidas usando restrições da biblioteca de modelos do Policy Controller ou de outros modelos de restrição do Gatekeeper.

A Implantação de amostra do Anthos no Google Cloud já tem o Policy Controller instalado e também a biblioteca de modelos do Policy Controller está ativada. Aproveite isso ao implementar a proteção usando uma restrição atual para contêineres com privilégios da biblioteca.

Aplicar uma restrição de política aos contêineres com privilégios

Para atender às preocupações da equipe de segurança, aplique a restrição K8sPSPPrivilegedContainer. Essa restrição nega a execução de pods com contêineres privilegiados.

1. Usando o terminal do Cloud Shell, crie um novo arquivo constraint.yaml com o texto da restrição da biblioteca, da seguinte maneira:

   cat <<EOF> ~/tutorial/anthos-sample-deployment-config-repo/cluster/constraint.yaml
   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: K8sPSPPrivilegedContainer
   metadata:
     name: psp-privileged-container
   spec:
     match:
       kinds:
         - apiGroups: [""]
           kinds: ["Pod"]
       excludedNamespaces: ["kube-system"]
   EOF
   

2. Use nomos vet para verificar se a configuração atualizada é válida antes de aplicá-la.

   nomos vet
   

   O comando é retornado silenciosamente, desde que não haja erros.

3. Confirme e envie as alterações para aplicar a política. Use nomos status com o comando watch para confirmar se as alterações foram aplicadas ao seu cluster. Pressione Ctrl+C para sair do comando "watch" quando terminar.

   git add .
   git commit -m "add policy constraint for privileged containers"
   git push && watch nomos status
   

   Saída:

   Connecting to clusters...
   Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
   -------   -------                  -----------  -----------------   -----------   ---------------
   *         anthos-sample-cluster1   SYNCED       f2898e92            master        Healthy
   

Testar sua política

Depois de aplicar a política, é possível testá-la tentando executar um pod com um contêiner privilegiado.

1. No terminal do Cloud Shell, use o seguinte comando para criar um novo arquivo no diretório do tutorial, nginx-privileged.yaml, com o conteúdo desta especificação de exemplo:

   cat <<EOF> ~/tutorial/nginx-privileged.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-privileged-disallowed
     labels:
       app: nginx-privileged
   spec:
     containers:
     - name: nginx
       image: nginx
       securityContext:
         privileged: true
   EOF
   

2. Tente iniciar o pod com kubectl apply.

   kubectl apply -f ~/tutorial/nginx-privileged.yaml
   

   Saída:

   Error from server ([denied by psp-privileged-container] Privileged container is not allowed: nginx, securityContext: {"privileged": true}): error when creating "~/nginx-privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by psp-privileged-container] Privileged container is not allowed: nginx, security
   Context: {"privileged": true}
   

   O erro mostra que o controlador de admissão do Gatekeeper que monitora o ambiente do Kubernetes aplicou sua nova política. Isso impediu a execução do pod devido à presença de um contêiner privilegiado na especificação do pod.

O conceito de políticas controladas por versão que você pode aplicar para configurar proteções com o Controlador de Políticas é avançado, porque ele padroniza, unifica e centraliza a governança de seus clusters, aplicando suas políticas usando monitoramento ativo da pós-implantação do ambiente.

Você pode encontrar muitos outros tipos de políticas a serem usadas como proteção para seu ambiente no repositório do Gatekeeper.

Como explorar a implantação ainda mais

Neste tutorial, mostramos como trabalhar com alguns recursos de segurança do GKE Enterprise, mas ainda há muito mais a explorar e fazer no GKE Enterprise com nossa implantação. Teste outro tutorial ou continue a explorar a implantação do Anthos no Google Cloud antes de seguir as instruções de limpeza da próxima seção.