Tutorial: proteger o GKE Enterprise

O GKE Enterprise oferece uma plataforma consistente para criar e fornecer serviços seguros, com recursos de segurança integrados em todos os níveis que trabalham separadamente e em conjunto para fornecer proteção contra problemas de segurança. Este tutorial apresenta alguns dos recursos de segurança avançados do GKE Enterprise usando a implantação de amostra do Anthos no Google Cloud. O Anthos Sample Deployment implanta um ambiente prático real do GKE Enterprise com um cluster do GKE, uma malha de serviço e um aplicativo Bank of GKE Enterprise com vários microsserviços.

Objetivos

Neste tutorial, você conhecerá alguns dos recursos de segurança do GKE Enterprise nas seguintes tarefas:

Aplicar o TLS mútuo (mTLS) na malha de serviço usando o Config Management para garantir a comunicação segura de ponta a ponta.
Configure uma proteção de segurança que garanta que pods com contêineres privilegiados não sejam implantados acidentalmente usando o Policy Controller.

Custos

A menos que você já tenha comprado uma assinatura, a implantação do aplicativo Bank of Anthos gera cobranças de pagamento por utilização para o GKE Enterprise no Google Cloud , conforme listado na página de preços.

Você também é responsável por outros Google Cloud custos incorridos ao executar o aplicativo Bank of Anthos, como cobranças por VMs do Compute Engine e balanceadores de carga.

Recomendamos limpar depois do tutorial ou explorar a implantação para evitar cobranças adicionais.

Antes de começar

Este tutorial é um acompanhamento do tutorial Explorar o Anthos. Antes de começar este tutorial, siga as instruções desta página para configurar seu projeto e instalar a implantação de amostra do Anthos.

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:
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:

Verifique se você tem uma sessão ativa do Cloud Shell. É possível iniciar o Cloud Shell clicando em Ativar o Cloud Shell no Google Cloud console do seu projeto de tutorial.
Crie um diretório no qual trabalhar:
```
mkdir tutorial
cd tutorial
```

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

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

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?

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
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.
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:

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.
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.
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

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".
```

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'.

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)

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 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.

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.

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

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

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.

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.
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
```
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 ativada. Google Cloud 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.

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

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.

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.

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

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 por conta própria, antes de seguir as instruções de limpeza na próxima seção.

Limpar

Depois de terminar de explorar o aplicativo Bank of Anthos, limpe os recursos criados no Google Cloud para que eles não ocupem cota e você não receba cobranças por eles no futuro.

Opção 1. É possível excluir o projeto. No entanto, se você quiser manter o projeto, use a opção 2 para excluir a implantação.
Opção 2. Se você quiser manter o projeto atual, use terraform destroy para excluir o cluster e o aplicativo de exemplo.

Excluir o projeto (opção 1)

A maneira mais fácil de evitar o faturamento é excluir o projeto criado para o tutorial.

Cuidado: excluir um projeto tem os seguintes efeitos:

Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Excluir a implantação (opção 2)

Essa abordagem exclui o aplicativo Bank of Anthos e o cluster, mas não o projeto. Execute os seguintes comandos no Cloud Shell:

Mude para o diretório que hospeda os scripts de instalação:
```
cd bank-of-anthos/iac/tf-anthos-gke
```
Exclua o exemplo e o cluster:
```
terraform destroy
```
Insira o ID do projeto quando solicitado.

Se você planeja reimplantar, verifique se todos os requisitos foram atendidos conforme descrito na seção Antes de começar.

A seguir

Há muito mais para explorar na nossa documentação do GKE Enterprise.

Ver mais tutoriais

Saiba mais sobre o gerenciamento de serviços com a implantação de amostra do Anthos em Gerenciar serviços com o GKE Enterprise.
Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.

Saiba mais sobre o GKE Enterprise

Saiba mais sobre o GKE Enterprise nas informações gerais técnicas.
Descubra como configurar o GKE Enterprise em um ambiente de produção real no nosso guia de configuração.
Descubra como fazer mais com o Cloud Service Mesh na seção de documentação.
Saiba mais sobre o Policy Controller no guia do Policy Controller.
Saiba mais sobre configuração declarativa e centralizada e gerenciamento de políticas na documentação do Config Sync e na documentação do Policy Controller.

Tutorial: proteger o GKE Enterprise Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Objetivos

Custos

Antes de começar

Como configurar o ambiente do Cloud Shell

Como aplicar mTLS na malha de serviço

Confirmar configuração do Config Sync

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

Enviar suas alterações para o repositório

Como usar o Policy Controller para configurar proteções

Aplicar proteções

Usar o Policy Controller

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

Testar sua política

Como explorar a implantação ainda mais

Limpar

Excluir o projeto (opção 1)

Excluir a implantação (opção 2)

A seguir

Ver mais tutoriais

Saiba mais sobre o GKE Enterprise

Tutorial: proteger o GKE Enterprise