Aumente a segurança do seu app com o Anthos Service Mesh e o Anthos Config Management

Neste tutorial, mostramos como melhorar a postura de segurança do cluster e do app. Imagine que você é o administrador de uma plataforma onde uma organização gerencia os apps da loja on-line com o Anthos Service Mesh, um pacote de ferramentas que ajuda a monitorar e gerenciar uma malha de serviço confiável. Você é responsável por garantir a segurança da malha e dos apps.

É possível evitar configurações incorretas e validar automaticamente as políticas do Anthos Service Mesh usando o Policy Controller e o Config Sync do Anthos Config Management. O Policy Controller permite a aplicação de políticas totalmente programáveis nos clusters. O Policy Controller também tem uma biblioteca padrão de modelos de restrição que pode ser usada com o pacote de segurança do Anthos Service Mesh para auditar a manutenção da conformidade com as práticas recomendadas e controle de vulnerabilidades de segurança da malha. O Config Sync reconcilia continuamente o estado dos clusters com um conjunto central de arquivos de configuração declarativos do Kubernetes. Usar o Policy Controller e o Config Sync juntos permite que você aplique restrições continuamente nas configurações de políticas do Anthos Service Mesh.

O diagrama a seguir oferece uma visão geral de como o Anthos Service Mesh, o Policy Controller e o Config Sync funcionam juntos para gerenciar e proteger os apps de exemplo da Online Boutique utilizados neste tutorial:

Um diagrama que mostra a arquitetura criada para este tutorial

Objetivos

Criar um cluster do Google Kubernetes Engine (GKE) e registrá-lo em uma frota.
Instalar o Policy Controller, o Config Sync e o Anthos Service Mesh em um cluster.
Implantar os apps de exemplo da Online Boutique e um gateway de entrada.
Aproveitar o pacote de políticas do Anthos Service Mesh para aplicar as seguintes práticas recomendadas:
- Garantir que todas as cargas de trabalho na malha tenham injeção automática de arquivo secundário.
- Criptografe todo o tráfego na malha.
- Garanta que todas as cargas de trabalho na malha tenham controle de acesso granular.

Custos

Neste tutorial, usamos os seguintes componentes faturáveis do Google Cloud:

GKE.
Anthos. O faturamento do Anthos inclui o faturamento do Anthos Service Mesh e dos componentes do Anthos Config Management.

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Para mais informações, consulte Limpeza.

Antes de começar

No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

Acessar o seletor de projetos
Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como verificar se o faturamento está ativado em um projeto.

Preparar o ambiente

Nesta seção, você vai preparar o ambiente para instalar o Anthos Service Mesh, o Policy Controller e o Config Sync:

Abra uma sessão do Cloud Shell. Para abrir essa sessão, clique em Ativar o Cloud Shell no canto superior direito desta página e clique em Confirmar. Uma sessão do Cloud Shell é aberta dentro de um quadro inferior na página. Execute os seguintes comandos nessa sessão do Cloud Shell.
Faça upgrade para a versão mais recente do Google Cloud CLI:
```
gcloud components update
```
Para armazenar os arquivos criados neste tutorial, crie um diretório usando uma variável de ambiente:
```
WORK_DIR=~/asm-acm-tutorial-dir
mkdir $WORK_DIR
```
Para simplificar o restante do tutorial, crie as seguintes variáveis de ambiente:
```
PROJECT_ID=PROJECT_ID
gcloud config set project $PROJECT_ID
CLUSTER=asm-acm-tutorial
CLUSTER_ZONE=us-east4-a
PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)')
```
Substitua PROJECT_ID pelo ID do projeto que quer usar neste tutorial.

Se for solicitado que você autorize o Cloud Shell, clique em Autorizar para concluir a operação.

Ative as APIs necessárias para este tutorial:

gcloud services enable \
    container.googleapis.com \
    gkehub.googleapis.com \
    mesh.googleapis.com \
    anthos.googleapis.com

A conclusão dessa operação pode levar mais de um minuto.

Configurar um cluster do GKE

Nesta seção, você criará um cluster do GKE e o registrará em uma frota. As frotas são um conceito do Google Cloud para organizar logicamente clusters e outros recursos. Elas permitem que você use e gerencie recursos de vários clusters e aplique políticas consistentes nos seus sistemas.

O cluster criado nesta seção é o que recebe a instalação do Anthos Service Mesh, Policy Controller e Config Sync. É também o cluster em que você implanta os apps de exemplo da Online Boutique.

Para configurar o cluster, siga estas etapas:

Crie um cluster do GKE:

gcloud container clusters create ${CLUSTER} \
    --zone ${CLUSTER_ZONE} \
    --machine-type=e2-standard-4 \
    --num-nodes 4 \
    --workload-pool ${PROJECT_ID}.svc.id.goog \
    --labels mesh_id=proj-${PROJECT_NUMBER}

A conclusão dessa operação pode levar mais de cinco minutos.

A saída será assim:

kubeconfig entry generated for asm-acm-tutorial.
NAME: asm-acm-tutorial
LOCATION: us-east4-a
MASTER_VERSION: 1.21.10-gke.2000
MASTER_IP: 34.85.159.120
MACHINE_TYPE: e2-standard-4
NODE_VERSION: 1.21.10-gke.2000
NUM_NODES: 4
STATUS: RUNNING

Registre o cluster em uma frota.

gcloud container fleet memberships register ${CLUSTER} \
    --project=${PROJECT_ID} \
    --gke-cluster=${CLUSTER_ZONE}/${CLUSTER} \
    --enable-workload-identity

A saída será assim:

kubeconfig entry generated for asm-acm-tutorial.
Waiting for membership to be created...done.
Created a new membership [projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial] for the cluster [asm-acm-tutorial]
Generating the Connect Agent manifest...
Deploying the Connect Agent on cluster [asm-acm-tutorial] in namespace [gke-connect]...
Deployed the Connect Agent on cluster [asm-acm-tutorial] in namespace [gke-connect].
Finished registering the cluster [asm-acm-tutorial] with the Fleet.

Explorar o repositório

Na seção de instalação a seguir, você aplica um manifesto do Anthos Config Management acm-config.yaml. Esse manifesto configura o cluster para ser sincronizado na pasta asm-acm-tutorial do repositório de amostra do Anthos Config Management. Essa pasta contém todos os arquivos de configuração necessários para concluir o restante do tutorial.

Para simplificar a experiência neste tutorial, use comandos sed para atualizar o arquivo acm-config.yaml e implantar os manifestos necessários em cada etapa. Atualizar um único arquivo ajuda você a se concentrar nos conceitos e no fluxo da proteção dos clusters, da malha e dos aplicativos sem manipular repetidamente os arquivos e executar comandos git add|commit|push.

Antes de aplicar o manifesto acm-config.yaml, é útil entender a estrutura e o conteúdo gerais do repositório.

Para usar a capacidade do Config Sync de sincronizar com vários repositórios, o repositório asc-acm-tutorial contém duas pastas de nível superior: root-sync e online-boutique.

Pasta `root-sync`

A pasta root-sync é o repositório raiz. Esse repositório é dividido em várias subpastas, cada uma delas contendo recursos e políticas para uma parte diferente deste tutorial.

Há duas pastas que contêm recursos para configurar o app de exemplo da Online Boutique e o gateway de entrada:

init: recursos para configurar o RepoSync para os apps da Online Boutique.
deployments: recursos para implantar o gateway de entrada e os namespaces e apps da Online Boutique.

Há três pastas que contêm recursos para implantar as diferentes políticas do Anthos Service Mesh:

enforce-sidecar-injection: recursos para implantar políticas para aplicar a injeção de arquivo secundário para Namespace e Pod.
enforce-strict-mtls: recursos para implantar políticas para aplicar mTLS STRICT em toda a malha e para qualquer PeerAuthentication
enforce-authorization-policies: recursos para implantar políticas para aplicar a deny padrão da AuthorizationPolicy a toda a malha e aplicar restrições de origem granulares para qualquer AuthorizationPolicies.

As três pastas restantes contêm recursos para implantar os recursos que corrigem as violações de políticas do Anthos Service Mesh:

fix-strict-mtls: recursos para implantar STRICT mTLS PeerAuthentication padrão na página istio-system namespace.
fix-default-deny-authorization-policy: recursos para implantar deny AuthorizationPolicy padrão no namespace istio-system.
deploy-authorization-policies: recursos para implantar os recursos AuthorizationPolicy granulares para fazer com que os apps de exemplo da Online Boutique funcionem.

Pasta `online-boutique`

A pasta online-boutique é um repositório de namespace. Esse repositório contém os recursos necessários para implantar os apps de exemplo da Online Boutique usando o Kustomize.

Instalar o Policy Controller, Config Sync e Anthos Service Mesh gerenciado

Agora que você criou e registrou seu cluster, é possível instalar o Config Sync, Policy Controller e Anthos Service Mesh no cluster e configurá-lo para sincronização usando as configurações da pasta asc-acm-tutorial:

Ative o Anthos Config Management na frota:

gcloud beta container fleet config-management enable

Ative o Anthos Service Mesh na frota:
```
gcloud container fleet mesh enable
```
Ative o gerenciamento do plano de controle automático do Anthos Service Mesh para permitir que o Google aplique a configuração recomendada do Anthos Service Mesh gerenciado:
```
gcloud container fleet mesh update \
    --control-plane automatic \
    --memberships ${CLUSTER}
```

Para instalar e configurar o Config Sync e o Policy Controller, crie o seguinte manifesto do Anthos Config Management:

cat <<EOF > $WORK_DIR/acm-config.yaml
applySpecVersion: 1
spec:
  policyController:
    enabled: true
    templateLibraryInstalled: true
    referentialRulesEnabled: true
  configSync:
    enabled: true
    sourceFormat: unstructured
    syncRepo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    syncBranch: main
    secretType: none
    policyDir: asm-acm-tutorial/root-sync/init
EOF

Para saber mais sobre os campos de configuração do Anthos Config Management, consulte gcloud apply spec fields.

Aplique o arquivo:
```
gcloud beta container fleet config-management apply \
    --membership ${CLUSTER} \
    --config $WORK_DIR/acm-config.yaml
```
Depois de aplicar esse arquivo, o Policy Controller e o Config Sync serão instalados no cluster. Em seguida, o Config Sync começa a sincronizar todas as configurações na pasta asm-acm-tutorial com o cluster. Essas configurações instalam e configuram os seguintes componentes-chave:
- O objeto RepoSync que configura o app da Online Boutique é sincronizado:
  
  asm-acm-tutorial/root-sync/init/repo-sync/reposync.yaml
  
  Ver no GitHub
```
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: repo-sync
spec:
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    revision: HEAD
    branch: main
    dir: asm-acm-tutorial/online-boutique/init
    auth: none
```
- Como o reconciliador RepoSync precisa de outras permissões para criar recursos do Istio, o repositório também contém papéis e vinculações de papéis de cluster para conceder essas permissões. Este é o manifesto do papel de cluster aplicado automaticamente ao cluster:
  
  asm-acm-tutorial/root-sync/init/istio-clusterrole.yaml
  
  Ver no GitHub
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
  name: custom:aggregate-to-edit:istio
rules:
- apiGroups:
  - "networking.istio.io"
  - "security.istio.io"
  resources:
  - "virtualservices"
  - "authorizationpolicies"
  verbs:
  - "*"
```
Para garantir a instalação bem-sucedida do Policy Controller e do Config Sync, veja o status do Anthos Config Management:
```
gcloud beta container fleet config-management status
```
A saída será assim:
```
Name: asm-acm-tutorial
Status: SYNCED
Last_Synced_Token: 4b3384d
Sync_Branch: main
Last_Synced_Time: 2022-05-04T21:32:58Z
Policy_Controller: INSTALLED
Hierarchy_Controller: PENDING
```
Se você vir PENDING ou NOT_INSTALLED nas linhas Status ou Policy_Controller, aguarde alguns minutos e execute gcloud beta container fleet config-management status novamente.

Para garantir a instalação do Anthos Service Mesh, descreva o status dele:

gcloud container fleet mesh describe

A saída será assim:

createTime: '2022-05-05T23:33:44.041608250Z'
membershipSpecs:
  projects/841604900168/locations/global/memberships/asm-acm-tutorial:
    mesh:
      controlPlane: AUTOMATIC
membershipStates:
  projects/841604900168/locations/global/memberships/asm-acm-tutorial:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
      updateTime: '2022-05-05T23:45:38.800808838Z'
name: projects/PROJECT_ID/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
spec: {}
state:
  state: {}
updateTime: '2022-05-05T23:45:44.848011023Z'

Se você vir state.code: ERROR em vez de state.code: OK, aguarde alguns minutos e execute gcloud container fleet mesh describe novamente. Antes de prosseguir com o tutorial, verifique se o campo servicemesh.controlPlaneManagement.details[].code tem o valor REVISION_READY.

Implantar um gateway de entrada e um app de exemplo

Nesta seção, você implantará o aplicativo de amostra Online Boutique e um gateway de entrada para gerenciar o tráfego de entrada.

Implante o aplicativo de amostra Online Boutique e o gateway de entrada.

O comando a seguir usa sed para atualizar o manifesto acm-config.yaml para que o Config Sync implante os recursos necessários para implantar o gateway de entrada e o app de amostra.
```
sed -i "s,root-sync/init,root-sync/deployments,g" $WORK_DIR/acm-config.yaml
gcloud beta container fleet config-management apply \
    --membership ${CLUSTER} \
    --config $WORK_DIR/acm-config.yaml
```
Essa etapa pode levar alguns minutos para ser concluída.

Veja o status do Config Sync para o RootSync:

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

A saída é semelhante a:

getting 1 RepoSync and RootSync from projects/project_id/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/project_id/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/deployments@main",
    "status": "SYNCED"
  }
]

Se você vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

Para ver também os recursos gerenciados, adicione a sinalização --managed-resources. Para mais informações, consulte Ver o status do Config Sync em vários clusters.

Veja o status do Config Sync para o RepoSync:

gcloud alpha anthos config sync repo describe \
    --sync-name repo-sync \
    --sync-namespace onlineboutique

A saída é semelhante a:

getting 1 RepoSync and RootSync from projects/project_id/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/project_id/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//online-boutique/deployments@main:HEAD",
    "status": "SYNCED"
  }
]

Se você vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

Aguarde o provisionamento do endereço IP público do gateway de entrada:

until kubectl -n asm-ingress get svc asm-ingressgateway -o jsonpath='{.status.loadBalancer}' | grep "ingress"; do : ; done

Anote o endereço IP público do gateway de entrada:

EXTERNAL_IP=$(kubectl get svc asm-ingressgateway -n asm-ingress -o jsonpath="{.status.loadBalancer.ingress[*].ip}")

Acesse o endereço IP do seu navegador para verificar se o app Online Boutique foi implantado:
```
echo http://${EXTERNAL_IP}
```

Aplicar políticas para proteger a malha

Nas seções a seguir, você aproveita o controlador de políticas para aplicar políticas do pacote de políticas do Anthos Service Mesh criando restrições.

Aplicar injeção de proxies sidecar

Nesta seção, você aplicará políticas para garantir que todas as cargas de trabalho na malha tenham a injeção automática de arquivo secundário ativada.

Para aplicar a injeção de proxies sidecar, aplique restrições.

O comando a seguir usa sed para atualizar o arquivo acm-config.yaml e fazer com que o Config Sync implante os recursos associados.

sed -i "s,root-sync/deployments,root-sync/enforce-sidecar-injection,g" $WORK_DIR/acm-config.yaml
gcloud beta container fleet config-management apply \
    --membership ${CLUSTER} \
    --config $WORK_DIR/acm-config.yaml

O comando anterior aplica os seguintes recursos:

Um Constraint K8sRequiredLabels que requer que qualquer Namespace na malha contenha o rótulo de injeção de arquivo secundário do Anthos Service Mesh:

asm-acm-tutorial/root-sync/enforce-sidecar-injection/namespace-sidecar-injection-label.yaml

Ver no GitHub

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: namespace-sidecar-injection-label
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - ""
      kinds:
      - Namespace
    excludedNamespaces:
    - config-management-monitoring
    - config-management-system
    - default
    - gatekeeper-system
    - gke-connect
    - istio-system
    - kube-node-lease
    - kube-public
    - kube-system
    - resource-group-system
  parameters:
    labels:
    - allowedRegex: enabled
      key: istio-injection

Um AsmSidecarInjection Constraint que proíbe qualquer pod na malha de ignorar a injeção do sidecar do proxy do Istio:

asm-acm-tutorial/root-sync/enforce-sidecar-injection/pod-sidecar-injection-annotation.yaml

Ver no GitHub

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AsmSidecarInjection
metadata:
  name: pod-sidecar-injection-annotation
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - ""
      kinds:
      - Pod
    excludedNamespaces:
    - kube-system
  parameters:
    strictnessLevel: High

Veja o status do Config Sync para o RootSync:

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

A saída é semelhante a:

getting 1 RepoSync and RootSync from projects/project_id/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/project_id/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/enforce-sidecar-injection@main",
    "status": "SYNCED"
  }
]

Se você vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

Verifique se as Constraints foram criadas:

kubectl get constraints

Pode levar alguns minutos para o Policy Controller avaliar essas restrições. Se os valores não aparecerem na coluna TOTAL-VIOLATIONS, aguarde e execute kubectl get constraints novamente.

A saída é semelhante a:

NAME                                                                                       ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
podsidecarinjectionannotation.constraints.gatekeeper.sh/pod-sidecar-injection-annotation   deny                 0

NAME                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
k8srequiredlabels.constraints.gatekeeper.sh/namespace-sidecar-injection-label   deny                 0

Como configuramos corretamente nossos Namespaces e Pods, há 0 TOTAL-VIOLATIONS para esses Constraints.

Para ver essas Constraints em funcionamento, tente criar um Namespace no cluster sem um label nem um annotation:

kubectl create namespace test

A resposta será semelhante a esta:

Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [namespace-sidecar-injection-label] you must provide labels: {"istio-injection"}

Aplicar criptografia de tráfego

Nesta seção, você aplicará políticas para garantir que todo o tráfego na malha seja criptografado.

Para aplicar a criptografia do tráfego, aplique restrições.

O comando a seguir usa sed para atualizar o arquivo acm-config.yaml e fazer com que o Config Sync implante os recursos associados.

sed -i "s,root-sync/enforce-sidecar-injection,root-sync/enforce-strict-mtls,g" $WORK_DIR/acm-config.yaml
gcloud beta container fleet config-management apply \
    --membership ${CLUSTER} \
    --config $WORK_DIR/acm-config.yaml

O comando anterior aplica os seguintes recursos:

Um AsmPeerAuthnMeshStrictMtls Constraint que aplica o mTLS PeerAuthentication no nível da malha no namespace istio-system:

asm-acm-tutorial/root-sync/enforce-strict-mtls/policies/mesh-level-strict-mtls.yaml

Ver no GitHub

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AsmPeerAuthnMeshStrictMtls
metadata:
  name: mesh-level-strict-mtls
spec:
  enforcementAction: deny
  parameters:
    rootNamespace: istio-system
    strictnessLevel: High

Uma restrição referencial Config no namespace gatekeeper-system. Essa restrição referencial permite que o AsmPeerAuthnMeshStrictMtls Constraint faça referência a outro objeto na definição (por exemplo, pesquisar qualquer PeerAuthentication no istio-system Namespace):

asm-acm-tutorial/root-sync/enforce-strict-mtls/gatekeeper-system/config-referential-constraints.yaml

Ver no GitHub
```
apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
spec:
  sync:
    syncOnly:
      - group: ""
        version: "v1"
        kind: "Namespace"
      - group: "security.istio.io"
        version: "v1beta1"
        kind: "PeerAuthentication"
      - group: "security.istio.io"
        version: "v1beta1"
        kind: "AuthorizationPolicy"
```

Um Constraint DestinationRuleTLSEnabled que proíbe a desativação do TLS para todos os hosts e subconjuntos de hosts no DestinationRules do Istio:

asm-acm-tutorial/root-sync/enforce-strict-mtls/policies/destinationrule-tls-enabled.yaml

Ver no GitHub

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: DestinationRuleTLSEnabled
metadata:
  name: destination-rule-tls-enabled
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - networking.istio.io
      kinds:
      - DestinationRule

Um Constraint AsmPeerAuthnStrictMtls que exige que todos os PeerAuthentications não substituam mTLS STRICT:

asm-acm-tutorial/root-sync/enforce-strict-mtls/policies/peerauthentication-strict-mtls.yaml

Ver no GitHub

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AsmPeerAuthnStrictMtls
metadata:
  name: peerauthentication-strict-mtls
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - security.istio.io
      kinds:
      - PeerAuthentication
  parameters:
    strictnessLevel: High

Veja o status do Config Sync para o RootSync:

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

A saída é semelhante a:

getting 1 RepoSync and RootSync from projects/project_id/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/project_id/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/enforce-strict-mtls@main",
    "status": "SYNCED"
  }
]

Se você vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

Execute o seguinte comando para ver mais informações sobre a violação PeerAuthentication:

kubectl get asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/mesh-level-strict-mtls -ojsonpath='{.status.violations}'  | jq

A saída é semelhante a:

[
  {
    "enforcementAction": "deny",
    "kind": "AsmPeerAuthnMeshStrictMtls",
    "message": "Root namespace <istio-system> does not have a strict mTLS PeerAuthentication",
    "name": "mesh-level-strict-mtls"
  }
]

Corrija o problema implantando um PeerAuthentication no istio-system. Para impedir que todos os serviços na malha aceitem tráfego de texto simples, defina uma política PeerAuthentication para toda a malha, com o modo mTLS definido como STRICT. Quando você implanta a política, o plano de controle provisiona certificados TLS automaticamente, para que as cargas de trabalho possam ser autenticadas entre si.

O comando a seguir usa sed para atualizar o arquivo acm-config.yaml e fazer com que o Config Sync implante os recursos associados.
```
sed -i "s,root-sync/enforce-strict-mtls,root-sync/fix-strict-mtls,g" $WORK_DIR/acm-config.yaml
gcloud beta container hub config-management apply \
    --membership ${CLUSTER} \
    --config $WORK_DIR/acm-config.yaml
```
O comando anterior aplica o seguinte PeerAuthentication mTLS STRICT no namespace istio-system. Isso aplica mTLS STRICT a toda a malha:

docs/istio-system-manifests/with-strict-mtls/peerauthentication.yaml

Ver no GitHub
```
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT
```

Veja o status do Config Sync para o RootSync:

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

A saída é semelhante a:

getting 1 RepoSync and RootSync from projects/project_id/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/project_id/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/fix-strict-mtls@main",
    "status": "SYNCED"
  }
]

Se você vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

Verifique se as Constraints foram criadas:

kubectl get constraints

Pode levar alguns minutos para o Policy Controller avaliar esses Constraints. Aguarde e execute novamente o comando kubectl get constraints até receber valores na coluna TOTAL-VIOLATIONS de cada linha.

A saída é semelhante a:

NAME                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
k8srequiredlabels.constraints.gatekeeper.sh/namespace-sidecar-injection-label   deny                 0
NAME                                                                          ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/mesh-level-strict-mtls   deny                 0
NAME                                                                               ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
destinationruletlsenabled.constraints.gatekeeper.sh/destination-rule-tls-enabled   deny                 0
NAME                                                                              ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmpeerauthnstrictmtls.constraints.gatekeeper.sh/peerauthentication-strict-mtls   deny                 0
NAME                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmsidecarinjection.constraints.gatekeeper.sh/pod-sidecar-injection-annotation   deny                 0

Aplicar controle de acesso granular

Nesta seção, você aplicará políticas para garantir que todas as cargas de trabalho na malha tenham controle de acesso granular.

Para aplicar o controle de acesso granular, aplique restrições.

O comando a seguir usa sed para atualizar o arquivo acm-config.yaml e fazer com que o Config Sync implante os recursos associados.
```
sed -i "s,root-sync/fix-strict-mtls,root-sync/enforce-authorization-policies,g" $WORK_DIR/acm-config.yaml
gcloud beta container fleet config-management apply \
    --membership ${CLUSTER} \
    --config $WORK_DIR/acm-config.yaml
```
O comando anterior aplica os seguintes recursos:
- UmaAsmAuthzPolicyDefaultDeny Constraint que aplica a negação padrão da malha AuthorizationPolicy na página istio-system namespace:
  
  asm-acm-tutorial/root-sync/enforce-authorization-policies/policies/default-deny-authorization-policies.yaml
  
  Ver no GitHub
```
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AsmAuthzPolicyDefaultDeny
metadata:
  name: default-deny-authorization-policies
spec:
  enforcementAction: deny
  parameters:
    rootNamespace: istio-system
    strictnessLevel: High
```
- Um AsmAuthzPolicyEnforceSourcePrincipals Constraint, que determina que qualquer AuthorizationPolicies esteja definindo principais de origem granulares (que não sejam "*"). Somente o gateway de entrada no namespace asm-ingress é uma exceção a essa regra para receber o tráfego dos usuários finais e redirecionar o tráfego para o app frontend da boutique on-line.
  
  asm-acm-tutorial/root-sync/enforce-authorization-policies/policies/authz-source-principals-not-all.yaml
  
  Ver no GitHub
```
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: AsmAuthzPolicyEnforceSourcePrincipals
metadata:
  name: authz-source-principals-not-all
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - security.istio.io
      kinds:
      - AuthorizationPolicy
    excludedNamespaces:
      - asm-ingress
```

Veja o status do Config Sync para o RootSync:

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

A saída é semelhante a:

getting 1 RepoSync and RootSync from projects/project_id/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/project_id/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/enforce-authorization-policies@main",
    "status": "SYNCED"
  }
]

Se você vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

Execute o seguinte comando para ver mais informações sobre a violação associada:

kubectl get asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/default-deny-authorization-policies -ojsonpath='{.status.violations}'  | jq

A saída é semelhante a:

[
  {
    "enforcementAction": "deny",
    "kind": "AsmAuthzPolicyDefaultDeny",
    "message": "Root namespace <istio-system> does not have a default deny AuthorizationPolicy",
    "name": "default-deny-authorization-policies"
  }
]

Corrija o problema implantando o AuthorizationPolicy no namespace istio-system.

O comando a seguir usa sed para atualizar o arquivo acm-config.yaml e fazer com que o Config Sync implante os recursos associados.
```
sed -i "s,root-sync/enforce-authorization-policies,root-sync/fix-default-deny-authorization-policy,g" $WORK_DIR/acm-config.yaml
gcloud beta container hub config-management apply \
    --membership ${CLUSTER} \
    --config $WORK_DIR/acm-config.yaml
```
O comando anterior aplica o seguinte AuthorizationPolicy de negação de todos no namespace istio-system:

docs/istio-system-manifests/with-default-deny-authorization-policy/authorizationpolicy.yaml

Ver no GitHub
```
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
spec:
  {}
```

Veja o status do Config Sync para o RootSync:

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

A saída é semelhante a:

getting 1 RepoSync and RootSync from projects/project_id/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/project_id/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/fix-default-deny-authorization-policy@main",
    "status": "SYNCED"
  }
]

Se você vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

Verifique se as Constraints foram criadas:

kubectl get constraints

A saída é semelhante a:

NAME                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmsidecarinjection.constraints.gatekeeper.sh/pod-sidecar-injection-annotation   deny                 0
NAME                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
k8srequiredlabels.constraints.gatekeeper.sh/namespace-sidecar-injection-label   deny                 0
NAME                                                                                      ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/default-deny-authorization-policies   deny                 0
NAME                                                                          ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/mesh-level-strict-mtls   deny                 0
NAME                                                                               ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
destinationruletlsenabled.constraints.gatekeeper.sh/destination-rule-tls-enabled   deny                 0
NAME                                                                              ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmpeerauthnstrictmtls.constraints.gatekeeper.sh/peerauthentication-strict-mtls   deny                 0
NAME                                                                                              ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
asmauthzpolicyenforcesourceprincipals.constraints.gatekeeper.sh/authz-source-principals-not-all   deny                 0

Acesse o app "Online Boutique" no seu navegador:
```
echo http://${EXTERNAL_IP}
```
Você receberá o erro: RBAC: access denied, que confirma que a negação padrão AuthorizationPolicy se aplica à malha inteira.

Para corrigir esse problema, implante uma AuthorizationPolicies mais granular nos namespaces asm-ingress e onlineboutique.

O comando a seguir usa sed para atualizar o arquivo acm-config.yaml e fazer com que o Config Sync implante os recursos associados.

sed -i "s,root-sync/fix-default-deny-authorization-policy,root-sync/deploy-authorization-policies,g" $WORK_DIR/acm-config.yaml
gcloud beta container hub config-management apply \
    --membership ${CLUSTER} \
    --config $WORK_DIR/acm-config.yaml

O comando anterior aplica os seguintes recursos:

Um AuthorizationPolicy no namespace asm-ingress:

docs/ingress-gateway-asm-manifests/with-authorization-policies/authorizationpolicy.yaml

Ver no GitHub

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: asm-ingressgateway
spec:
  selector:
    matchLabels:
      asm: ingressgateway
  rules:
  - to:
    - operation:
        ports:
        - "8080"

Um AuthorizationPolicy por app no namespace onlineboutique. Veja o exemplo do app cartservice:

docs/online-boutique-asm-manifests/authorization-policies/all/authorization-policy-cartservice.yaml

Ver no GitHub

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: cartservice
spec:
  selector:
    matchLabels:
      app: cartservice
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/onlineboutique/sa/frontend
        - cluster.local/ns/onlineboutique/sa/checkoutservice
    to:
    - operation:
        paths:
        - /hipstershop.CartService/AddItem
        - /hipstershop.CartService/GetCart
        - /hipstershop.CartService/EmptyCart
        methods:
        - POST
        ports:
        - "7070"

Uma ServiceAccount por app nos namespaces asm-ingress e onlineboutique para que uma identidade exclusiva por app seja avaliada como principal em AuthorizationPolicies. Veja o exemplo do app cartservice:

docs/online-boutique-asm-manifests/service-accounts/all/service-account-cartservice.yaml

Ver no GitHub
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cartservice
```

Veja o status do Config Sync para o RootSync:

gcloud alpha anthos config sync repo describe \
    --sync-name root-sync \
    --sync-namespace config-management-system

A saída é semelhante a:

getting 1 RepoSync and RootSync from projects/project_id/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/project_id/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/fix-default-deny-authorization-policy@main",
    "status": "SYNCED"
  }
]

Se você vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

Veja o status do Config Sync para o RepoSync:

gcloud alpha anthos config sync repo describe \
    --sync-name repo-sync \
    --sync-namespace onlineboutique

A saída é semelhante a:

getting 1 RepoSync and RootSync from projects/project_id/locations/global/memberships/asm-acm-tutorial
[
  {
    "clusters": [
      "projects/project_id/locations/global/memberships/asm-acm-tutorial"
    ],
    "commit": "7d15d49af13c44aa531a4565b2277ddcf8b81884",
    "errors": [],
    "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/online-boutique/authorization-policies@main",
    "status": "SYNCED"
  }
]

Se você vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

Acesse o app Online Boutique novamente no seu navegador:
```
echo http://${EXTERNAL_IP}
```
Depois de alguns minutos, o site voltará a funcionar.

Ver o status dos recursos de segurança do Anthos

É possível ver o status dos recursos de segurança do Anthos, incluindo políticas de autenticação e autorização, no Console do Google Cloud.

No console, acesse a página Segurança do Anthos.

Acessar a segurança do Anthos

O Resumo da política exibe o status da segurança do aplicativo, incluindo o controle de acesso ao serviço (AuthorizationPolicies) e a mTLS.
Clique em Auditoria de políticas para ver os status da política da carga de trabalho para o cluster e os dois namespaces (asm-ingress e onlineboutique).

Os cards Controle de acesso ao serviço e Status mTLS oferecem uma visão geral de alto nível.

A lista Cargas de trabalho mostra o controle de acesso ao serviço e o status mTLS de cada carga de trabalho.

Você protegeu o cluster e a malha com o Policy Controller e o Config Sync.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Exclua o projeto

No console, acesse a página Gerenciar recursos.
Acessar "Gerenciar recursos"
Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Excluir recursos individuais

Para excluir os recursos individuais:

Cancele o registro do cluster na frota:

gcloud container fleet memberships unregister ${CLUSTER} \
    --project=${PROJECT_ID} \
    --gke-cluster=${CLUSTER_ZONE}/${CLUSTER}

A saída será assim:

kubeconfig entry generated for asm-acm-tutorial.
Waiting for membership to be deleted...done.
Deleting membership CR in the cluster...done.
Deleting namespace [gke-connect] in the cluster...done.

Exclua o cluster:

gcloud container clusters delete ${CLUSTER} \
    --zone ${CLUSTER_ZONE}

Pressione y quando for solicitado. A conclusão desse comando pode levar cerca de cinco minutos.

A saída será assim:

Deleting cluster asm-acm-tutorial...done.
Deleted [https://container.googleapis.com/v1/projects/PROJECT_ID/zones/us-east4-a/clusters/asm-acm-tutorial].

Exclua os arquivos que você criou:
```
rm -r $WORK_DIR
```

A seguir

Descubra práticas recomendadas de segurança do Anthos Service Mesh
Saiba mais sobre o pacote de políticas do Anthos Service Mesh.
Explore a biblioteca de modelos de restrição do Policy Controller.
Explore arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.

Aumente a segurança do seu app com o Anthos Service Mesh e o Anthos Config Management

Objetivos

Custos

Antes de começar

Preparar o ambiente

Configurar um cluster do GKE

Explorar o repositório

Pasta root-sync

Pasta online-boutique

Instalar o Policy Controller, Config Sync e Anthos Service Mesh gerenciado

Implantar um gateway de entrada e um app de exemplo

Aplicar políticas para proteger a malha

Aplicar injeção de proxies sidecar

Aplicar criptografia de tráfego

Aplicar controle de acesso granular

Ver o status dos recursos de segurança do Anthos

Limpar

Exclua o projeto

Excluir recursos individuais

A seguir

Pasta `root-sync`

Pasta `online-boutique`