Reforce a segurança da sua app com o Cloud Service Mesh, o Config Sync e o Policy Controller

Este tutorial mostra como melhorar a postura de segurança do cluster e da app. Imagine que é um administrador de plataforma cuja organização está a gerir as apps para a respetiva loja online com o Cloud Service Mesh, um conjunto de ferramentas que ajuda a monitorizar e gerir uma malha de serviços fiável. É responsável por garantir que a sua rede de malha e apps estão seguras.

Pode evitar a configuração incorreta e validar automaticamente as políticas do Cloud Service Mesh com o Policy Controller e o Config Sync. O Policy Controller permite a aplicação de políticas totalmente programáveis para os seus clusters. O Policy Controller também inclui uma biblioteca predefinida de modelos de restrições que pode usar com o pacote de segurança do Cloud Service Mesh para auditar a conformidade das vulnerabilidades de segurança e das práticas recomendadas da sua malha. O Config Sync reconcilia continuamente o estado dos clusters com um conjunto central de ficheiros de configuração declarativos do Kubernetes. A utilização conjunta do Policy Controller e do Config Sync permite-lhe aplicar continuamente restrições às configurações de políticas da Cloud Service Mesh.

O diagrama seguinte mostra uma vista geral de como a Cloud Service Mesh, o Policy Controller e o Config Sync funcionam em conjunto neste tutorial para gerir e proteger um gateway de entrada e as apps de exemplo da Online Boutique que usa neste tutorial:

Objetivos

• Crie um cluster do Google Kubernetes Engine (GKE) e registe o cluster numa frota.
• Instale o Policy Controller, o Config Sync e o Cloud Service Mesh num cluster.
• Configure o Config Sync para sincronizar vários repositórios
• Aplique as práticas recomendadas para implementar configurações, apps e recursos do Istio com o Config Sync.
• Implemente configurações de clusters, as apps de exemplo da Online Boutique e um gateway de entrada com o Config Sync.
• Tire partido do conjunto de políticas da malha de serviços na nuvem do Policy Controller para aplicar as seguintes práticas recomendadas de segurança:
  • Certifique-se de que todas as cargas de trabalho na malha têm injeção automática de sidecar.
  • Encriptar todo o tráfego na malha.
  • Garantir que todas as cargas de trabalho na malha têm um controlo de acesso detalhado.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

• GKE.
• GKE Enterprise. The billing for GKE Enterprise includes billing for the Cloud Service Mesh, Config Sync, and Policy Controller.

Para gerar uma estimativa de custos com base na sua utilização prevista, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Quando terminar as tarefas descritas neste documento, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

Antes de começar

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Verify that billing is enabled for your Google Cloud project.

Prepare o seu ambiente

Nesta secção, prepara o seu ambiente para poder instalar o Cloud Service Mesh, o Policy Controller e o Config Sync:

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

2. Atualize para a versão mais recente da CLI do Google Cloud:

   gcloud components update
   

3. Para armazenar os ficheiros que criar neste tutorial, crie um diretório:

   mkdir ~/asm-acm-tutorial-dir
   

4. Para simplificar o resto 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
   MEMBERSHIP=asm-acm-tutorial
   PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)')
   

   Substitua PROJECT_ID pelo ID do projeto que quer usar para este tutorial.

   Se lhe for pedido para autorizar o Cloud Shell, clique em Autorizar para concluir a operação.

5. Ative as APIs de que precisa para este tutorial:

   gcloud

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

   Config Connector

   Este tutorial inclui recursos do Config Connector. Pode usar estes recursos para concluir as mesmas tarefas que conclui no separador gcloud. Para usar estes recursos, instale o Config Connector e aplique os recursos da forma mais adequada para o seu ambiente.

   Use o seguinte manifesto Services:

   apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
   kind: Service
   metadata:
     annotations:
       cnrm.cloud.google.com/deletion-policy: "abandon"
       cnrm.cloud.google.com/disable-dependent-services: "false"
     name: mesh.googleapis.com
   spec:
     resourceID: mesh.googleapis.com
     projectRef:
       external: PROJECT_ID
   ---
   apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
   kind: Service
   metadata:
     annotations:
       cnrm.cloud.google.com/deletion-policy: "abandon"
       cnrm.cloud.google.com/disable-dependent-services: "false"
     name: anthos.googleapis.com
   spec:
     resourceID: anthos.googleapis.com
     projectRef:
       external: PROJECT_ID
   

   Esta operação pode demorar mais de um minuto a ser concluída.

Configure um cluster do GKE

Nesta secção, cria um cluster do GKE e, em seguida, regista-o numa frota. As frotas são um Google Cloud conceito para organizar logicamente clusters e outros recursos, o que lhe permite usar e gerir capacidades de vários clusters e aplicar políticas consistentes nos seus sistemas.

O cluster que criar nesta secção é o cluster no qual instala o Cloud Service Mesh, o Policy Controller e o Config Sync. Também é o cluster onde implementa as apps de exemplo da Online Boutique.

Para configurar o cluster, conclua os seguintes passos:

1. Crie um cluster do GKE:

   gcloud

   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}
   

   Config Connector

   Use os seguintes manifestos ContainerCluster e ContainerNodePool:

   apiVersion: container.cnrm.cloud.google.com/v1beta1
   kind: ContainerNodePool
   metadata:
     annotations:
       cnrm.cloud.google.com/project-id: PROJECT_ID
     name: asm-acm-tutorial
   spec:
     clusterRef:
       name: asm-acm-tutorial
     location: us-east4-a
     nodeConfig:
       machineType: e2-standard-4
     nodeCount: 4
   ---
   apiVersion: container.cnrm.cloud.google.com/v1beta1
   kind: ContainerCluster
   metadata:
     annotations:
       cnrm.cloud.google.com/project-id: PROJECT_ID
       cnrm.cloud.google.com/remove-default-node-pool: "true"
     labels:
       mesh_id: proj-PROJECT_NUMBER
     name: asm-acm-tutorial
   spec:
     location: us-east4-a
     initialNodeCount: 1
     workloadIdentityConfig:
       workloadPool: PROJECT_ID.svc.id.goog
   

   Substitua PROJECT_NUMBER pelo valor da variável de ambiente PROJECT_NUMBER obtida anteriormente.

   Esta operação pode demorar mais de cinco minutos a ser concluída.

2. Para garantir a criação bem-sucedida do cluster do GKE, descreva o respetivo estado:

   gcloud container clusters list \
       --zone ${CLUSTER_ZONE} \
       --project ${PROJECT_ID}
   

   O resultado é semelhante ao seguinte:

   NAME                LOCATION      MASTER_VERSION   MASTER_IP      MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
   asm-acm-tutorial    us-east4-a    1.23.12-gke.100  35.186.179.30  e2-standard-4  1.23.12-gke.100  3          RUNNING
   

3. Ligue-se ao cluster do GKE:

   gcloud container clusters get-credentials ${CLUSTER} \
       --zone ${CLUSTER_ZONE} \
       --project ${PROJECT_ID}
   

4. Registe o cluster numa frota:

   gcloud

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

   O resultado é semelhante ao seguinte:

   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.
   

   Config Connector

   Use o seguinte manifesto GKEHubMembership:

   apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
   kind: GKEHubMembership
   metadata:
     annotations:
       cnrm.cloud.google.com/project-id: PROJECT_ID
     name: asm-acm-tutorial
   spec:
     location: global
     authority:
       issuer: https://container.googleapis.com/v1/projects/PROJECT_ID/locations/us-east4-a/clusters/asm-acm-tutorial
     endpoint:
       gkeCluster:
         resourceRef:
           name: asm-acm-tutorial
   

5. Para garantir o registo bem-sucedido do cluster do GKE, descreva o respetivo estado:

   gcloud container fleet memberships list
   

   O resultado é semelhante ao seguinte:

   NAME              EXTERNAL_ID                           LOCATION
   asm-acm-tutorial  0e12258c-8831-4d81-b5c0-5e7099a468cc  global
   

Explore os repositórios

Na secção de instalação seguinte, aplica um ficheiro acm-config.yaml de manifesto. Esta configuração do manifesto sincroniza o cluster a partir da pasta asm-acm-tutorial do repositório de exemplo. Esta pasta contém todos os ficheiros de configuração necessários para concluir o resto do tutorial.

Para simplificar este tutorial, usa comandos sed para atualizar o acm-config.yaml. Com o ficheiro acm-config.yaml, o Config Sync implementa os manifestos necessários para cada passo deste tutorial. A atualização de um único ficheiro ajuda a focar-se nos conceitos e no fluxo de proteção dos seus clusters, malha e aplicações sem manipular repetidamente os ficheiros e executar repetidamente comandos git.

Para usar a capacidade do Config Sync de sincronizar vários repositórios, use os seguintes recursos:

• root-sync, como um repositório RootSync contém todas as configurações no seu cluster, incluindo RepoSyncs, Constraints, ClusterRole, RoleBindings e recursos incluídos em alguns espaços de nomes do sistema, como istio-system.
• ingress-gateway, como primeiro RepoSync, contém todos os recursos necessários para implementar um gateway de entrada e protegê-lo progressivamente ao longo deste tutorial.
• online-boutique, como um segundo RepoSync, contém todos os recursos necessários para implementar as apps Online Boutique e protegê-las progressivamente ao longo deste tutorial.

Instale o Policy Controller, o Config Sync e a malha de serviço do Google Cloud gerida

Agora que criou e registou o cluster, pode instalar o Config Sync, o Policy Controller e o Cloud Service Mesh no cluster e configurar o cluster para sincronizar a partir das configurações do RootSync predefinido:

1. Ative o operador ConfigManagement, que gere o Config Sync e o Policy Controller:

   gcloud

   gcloud beta container fleet config-management enable
   

   Config Connector

   Use o seguinte manifesto GKEHubFeature:

   apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
   kind: GKEHubFeature
   metadata:
     name: configmanagement
   spec:
     projectRef:
       external: PROJECT_ID
     location: global
     resourceID: configmanagement
   

2. Ative o Cloud Service Mesh na sua frota.

   gcloud

   gcloud container fleet mesh enable
   

   Config Connector

   Use o seguinte manifesto GKEHubFeature:

   apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
   kind: GKEHubFeature
   metadata:
     name: servicemesh
   spec:
     projectRef:
       external: PROJECT_ID
     location: global
     resourceID: servicemesh
   

3. Ative a gestão automática do Cloud Service Mesh para permitir que a Google aplique a configuração recomendada do Cloud Service Mesh gerido:

   gcloud

   gcloud container fleet mesh update \
       --management automatic \
       --memberships ${MEMBERSHIP}
   

   Config Connector

   Use o seguinte manifesto GKEHubFeatureMembership:

   apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
   kind: GKEHubFeatureMembership
   metadata:
     name: servicemesh-membership
   spec:
     projectRef:
       external: PROJECT_ID
     location: global
     membershipRef:
       name: asm-acm-tutorial
     featureRef:
       name: servicemesh
     mesh:
       management: MANAGEMENT_AUTOMATIC
   

4. Ative o Config Sync e o Policy Controller:

   gcloud

   Guarde o seguinte manifesto como acm-config.yaml no diretório ~/asm-acm-tutorial-dir:

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

   Para saber mais sobre os campos de configuração da CLI gcloud, consulte os campos de especificação de aplicação da gcloud.

   Aplique o ficheiro:

   gcloud beta container fleet config-management apply \
       --membership ${MEMBERSHIP} \
       --config ~/asm-acm-tutorial-dir/acm-config.yaml
   

   Config Connector

   Use o seguinte manifesto GKEHubFeatureMembership:

   apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
   kind: GKEHubFeatureMembership
   metadata:
     name: configmanagement-membership
   spec:
     projectRef:
       external: PROJECT_ID
     location: global
     membershipRef:
       name: asm-acm-tutorial
     featureRef:
       name: configmanagement
     configmanagement:
       configSync:
         sourceFormat: unstructured
         git:
           policyDir: asm-acm-tutorial/root-sync/init
           secretType: none
           syncBranch: main
           syncRepo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
       policyController:
         enabled: true
         referentialRulesEnabled: true
         templateLibraryInstalled: true
   

   O Policy Controller e o Config Sync estão instalados no seu cluster. Em seguida, o Config Sync começa a sincronizar todas as configurações do RootSync predefinido com o seu cluster. Estas configurações instalam e configuram os seguintes componentes principais:

   • Os objetos RepoSync que configuram as apps Online Boutique e o gateway de entrada são sincronizados:

     apiVersion: configsync.gke.io/v1beta1
     kind: RepoSync
     metadata:
       name: repo-sync
     spec:
       override:
         enableShellInRendering: true
       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

     apiVersion: configsync.gke.io/v1beta1
     kind: RepoSync
     metadata:
       name: repo-sync
     spec:
       override:
         enableShellInRendering: true
       sourceFormat: unstructured
       git:
         repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
         revision: HEAD
         branch: main
         dir: asm-acm-tutorial/ingress-gateway/init
         auth: none

   • Uma vez que os reconciliadores RepoSync precisam de autorizações adicionais para criar recursos do Istio, também são aplicados ao seu cluster um ClusterRole e dois objetos RoleBinding para conceder estas autorizações:

     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"
       - "gateways"
       verbs:
       - "*"

     apiVersion: rbac.authorization.k8s.io/v1
     kind: RoleBinding
     metadata:
       name: repo-sync
     subjects:
     - kind: ServiceAccount
       name: ns-reconciler-onlineboutique
       namespace: config-management-system
     roleRef:
       kind: ClusterRole
       name: edit
       apiGroup: rbac.authorization.k8s.io

     apiVersion: rbac.authorization.k8s.io/v1
     kind: RoleBinding
     metadata:
       name: repo-sync
     subjects:
     - kind: ServiceAccount
       name: ns-reconciler-asm-ingress
       namespace: config-management-system
     roleRef:
       kind: ClusterRole
       name: edit
       apiGroup: rbac.authorization.k8s.io

5. Para garantir a instalação bem-sucedida do Policy Controller e do Config Sync, verifique o estado:

   gcloud beta container fleet config-management status
   

   O resultado é semelhante ao seguinte:

   Name: asm-acm-tutorial
   Status: SYNCED
   Last_Synced_Token: 4b3384d
   Sync_Branch: main
   Last_Synced_Time: 2022-05-04T21:32:58Z
   Policy_Controller: INSTALLED
   

   Se vir PENDING ou NOT_INSTALLED nas linhas Status ou Policy_Controller, aguarde alguns minutos e execute gcloud beta container fleet config-management status novamente.

6. Para garantir a instalação bem-sucedida da Cloud Service Mesh, descreva o respetivo estado:

   gcloud container fleet mesh describe
   

   O resultado é semelhante ao seguinte:

   createTime: '2022-09-13T23:12:56.477042921Z'
   membershipSpecs:
     projects/PROJECT_NUMBER/locations/global/memberships/asm-acm-tutorial:
       mesh:
         management: MANAGEMENT_AUTOMATIC
   membershipStates:
     projects/PROJECT_NUMBER/locations/global/memberships/asm-acm-tutorial:
       servicemesh:
         controlPlaneManagement:
           details:
           - code: REVISION_READY
             details: 'Ready: asm-managed'
           state: ACTIVE
         dataPlaneManagement:
           details:
           - code: OK
             details: Service is running.
           state: ACTIVE
       state:
         code: OK
         description: |-
           Revision(s) ready for use: asm-managed.
           All Canonical Services have been reconciled successfully.
         updateTime: '2022-09-14T00:19:10.571552206Z'
   name: projects/PROJECT_ID/locations/global/features/servicemesh
   resourceState:
     state: ACTIVE
   spec: {}
   state:
     state: {}
   updateTime: '2022-09-14T00:19:14.135113118Z'
   

   Se vir state.code: ERROR em vez de state.code: OK, aguarde alguns minutos e execute gcloud container fleet mesh describe novamente. Antes de avançar com o tutorial, tem de se certificar de que o campo servicemesh.controlPlaneManagement.details.code tem o valor REVISION_READY.

Implemente um gateway de entrada e uma aplicação de exemplo

Nesta secção, implementa a aplicação de exemplo Online Boutique e um gateway de entrada para gerir o tráfego de entrada.

1. Implemente a aplicação de exemplo Online Boutique e o gateway de entrada.

   O comando seguinte usa sed para atualizar o manifesto acm-config.yaml de modo a fazer com que o Config Sync implemente os recursos de que precisa para implementar o gateway de entrada e a app de exemplo.

   sed -i "s,root-sync/init,root-sync/deployments,g" ~/asm-acm-tutorial-dir/acm-config.yaml
   gcloud beta container fleet config-management apply \
       --membership ${MEMBERSHIP} \
       --config ~/asm-acm-tutorial-dir/acm-config.yaml
   

   Tenha em atenção que este passo pode demorar alguns minutos a ser concluído.

2. Veja o estado do Config Sync para o RootSync e os dois RepoSyncs:

   gcloud alpha anthos config sync repo describe
   

   O resultado é semelhante ao seguinte:

   getting 3 RepoSync and RootSync from projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial
   [
     {
       "clusters": [
         "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
       ],
       "commit": "95a30c052566357afb9db3d7f6153d9c0f219c03",
       "errors": [],
       "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/root-sync/deployments@main",
       "status": "SYNCED"
     },
     {
       "clusters": [
         "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
       ],
       "commit": "95a30c052566357afb9db3d7f6153d9c0f219c03",
       "errors": [],
       "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/ingress-gateway/deployments@main",
       "status": "SYNCED"
     },
     {
       "clusters": [
         "projects/PROJECT_ID/locations/global/memberships/asm-acm-tutorial"
       ],
       "commit": "95a30c052566357afb9db3d7f6153d9c0f219c03",
       "errors": [],
       "source": "https://github.com/GoogleCloudPlatform/anthos-config-management-samples//asm-acm-tutorial/online-boutique/deployments@main",
       "status": "SYNCED"
     }
   ]
   

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

   Para ver apenas as informações de um repositório, pode usar as flags --sync-name e --sync-namespace. Para ver os recursos geridos em detalhe, adicione a flag --managed-resources. Para mais informações, consulte o artigo Veja o estado da sincronização de configuração em vários clusters.

3. Aguarde até que o endereço IP público do gateway de entrada seja aprovisionado:

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

4. Obtenha 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}")
   

5. Visite o endereço IP a partir do seu navegador para verificar se a app Online Boutique foi implementada com êxito:

   echo http://${EXTERNAL_IP}
   

Aplique políticas para proteger a sua malha

Nas secções seguintes, vai usar o Policy Controller para aplicar políticas do conjunto de políticas do Cloud Service Mesh criando restrições.

Aplique a injeção de proxies complementares

Nesta secção, aplica políticas para garantir que todas as cargas de trabalho na malha têm a injeção automática de sidecar ativada.

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

   O comando seguinte usa sed para atualizar o manifesto acm-config.yaml para que o Config Sync implemente os recursos associados.

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

   O comando anterior implementa os seguintes recursos:

   • Um K8sRequiredLabels Constraint que requer que qualquer Namespace na malha contenha a etiqueta de injeção de proxy sidecar da malha de serviços na nuvem específica:

     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 de sidecar do proxy do Istio:

     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

2. Veja o estado do Config Sync para RootSync:

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

   O resultado é semelhante ao seguinte:

   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 vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

3. Verifique se os Constraints foram criados:

   kubectl get constraints
   

   O Policy Controller pode demorar alguns minutos a avaliar estas restrições. Se não vir valores na coluna TOTAL-VIOLATIONS, aguarde e execute kubectl get constraints novamente.

   O resultado é semelhante ao seguinte:

   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 configurámos corretamente os nossos Namespaces e Pods, existem 0 TOTAL-VIOLATIONS para estes Constraints.

4. Para ver estas Constraints em funcionamento, experimente criar um Namespace no seu cluster sem um label nem um annotation:

   kubectl create namespace test
   

   O resultado é semelhante ao seguinte erro:

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

Aplique a encriptação de tráfego

Nesta secção, aplica políticas para garantir que todo o tráfego na malha está encriptado.

1. Para aplicar a encriptação de tráfego, aplique restrições.

   O comando seguinte usa sed para atualizar o manifesto acm-config.yaml para que o Config Sync implemente os recursos associados.

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

   O comando anterior implementa os seguintes recursos:

   • Um AsmPeerAuthnMeshStrictMtls Constraint que aplica o mTLS ao nível da malha PeerAuthentication no espaço de nomes istio-system:

     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 espaço de nomes gatekeeper-system. Esta restrição referencial permite que o AsmPeerAuthnMeshStrictMtls Constraint faça referência a outro objeto na respetiva definição (por exemplo, pesquisar qualquer PeerAuthentication no istio-system Namespace):

     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"

   • Uma DestinationRuleTLSEnabled Constraint que proíbe a desativação do TLS para todos os anfitriões e subconjuntos de anfitriões no Istio DestinationRules:

     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 AsmPeerAuthnStrictMtls Constraint que impõe que todos os PeerAuthentications não podem substituir STRICT mTLS:

     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

2. Veja o estado do Config Sync para RootSync:

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

   O resultado é semelhante ao seguinte:

   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 vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

3. Execute o seguinte comando para obter mais informações sobre a violação de PeerAuthentication:

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

   O resultado é semelhante ao seguinte:

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

4. Corrija o problema implementando um PeerAuthentication no istio-system. Para impedir que todos os seus serviços na malha aceitem tráfego de texto simples, defina uma política de malha com o modo mTLS definido como STRICT.PeerAuthentication Quando implementa a política, o plano de controlo aprovisiona automaticamente certificados TLS para que as cargas de trabalho possam autenticar-se entre si.

   O comando seguinte usa sed para atualizar o manifesto acm-config.yaml para que o Config Sync implemente os recursos associados.

   sed -i "s,root-sync/enforce-strict-mtls,root-sync/fix-strict-mtls,g" ~/asm-acm-tutorial-dir/acm-config.yaml
   gcloud beta container fleet config-management apply \
       --membership ${MEMBERSHIP} \
       --config ~/asm-acm-tutorial-dir/acm-config.yaml
   

   O comando anterior implementa o seguinte STRICT mTLS PeerAuthentication no espaço de nomes istio-system. Isto aplica o mTLS STRICT a toda a malha:

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

5. Veja o estado do Config Sync para RootSync:

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

   O resultado é semelhante ao seguinte:

   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 vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

6. Verifique se os Constraints foram criados:

   kubectl get constraints
   

   Tenha em atenção que pode demorar alguns minutos até que o Policy Controller avalie estes Constraints. Aguarde e execute novamente este comando kubectl get constraints até obter valores na coluna TOTAL-VIOLATIONS para cada linha.

   O resultado é semelhante ao seguinte:

   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
   

Aplique o controlo de acesso detalhado

Nesta secção, aplica políticas para garantir que todas as cargas de trabalho na malha têm um controlo de acesso detalhado.

1. Para aplicar o controlo de acesso detalhado, aplique restrições.

   O comando seguinte usa sed para atualizar o manifesto acm-config.yaml para que o Config Sync implemente os recursos associados.

   sed -i "s,root-sync/fix-strict-mtls,root-sync/enforce-authorization-policies,g" ~/asm-acm-tutorial-dir/acm-config.yaml
   gcloud beta container fleet config-management apply \
       --membership ${MEMBERSHIP} \
       --config ~/asm-acm-tutorial-dir/acm-config.yaml
   

   O comando anterior implementa os seguintes recursos:

   • Um AsmAuthzPolicyDefaultDeny Constraint que aplica a negação predefinida ao nível da malha AuthorizationPolicy no espaço de nomes istio-system:

     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 impõe que qualquer AuthorizationPolicies está a definir principais de origem detalhados (exceto "*"). Apenas o gateway de entrada no espaço de nomes asm-ingress é uma exceção a esta regra para receber o tráfego dos utilizadores finais e redirecionar o tráfego para a app frontend da Online Boutique.

     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

2. Veja o estado do Config Sync para RootSync:

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

   O resultado é semelhante ao seguinte:

   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 vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

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

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

   O resultado é semelhante ao seguinte:

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

4. Corrija o problema implementando o AuthorizationPolicy no espaço de nomes istio-system.

   O comando seguinte usa sed para atualizar o manifesto acm-config.yaml para que o Config Sync implemente os recursos associados.

   sed -i "s,root-sync/enforce-authorization-policies,root-sync/fix-default-deny-authorization-policy,g" ~/asm-acm-tutorial-dir/acm-config.yaml
   gcloud beta container fleet config-management apply \
       --membership ${MEMBERSHIP} \
       --config ~/asm-acm-tutorial-dir/acm-config.yaml
   

   O comando anterior implementa o seguinte deny-all AuthorizationPolicy no espaço de nomes istio-system:

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

5. Veja o estado do Config Sync para RootSync:

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

   O resultado é semelhante ao seguinte:

   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 vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

6. Verifique se os Constraints foram criados:

   kubectl get constraints
   

   Tenha em atenção que pode demorar alguns minutos até que o Policy Controller avalie estes Constraints. Aguarde e execute novamente este comando kubectl get constraints até obter valores na coluna TOTAL-VIOLATIONS para cada linha.

   O resultado é semelhante ao seguinte:

   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
   

7. Visite a app Online Boutique a partir do navegador:

   echo http://${EXTERNAL_IP}
   

   Deve receber o erro: RBAC: access denied, que confirma que a política de negação por predefinição AuthorizationPolicy é aplicada a toda a malha.

8. Corrija este problema implementando AuthorizationPolicies mais detalhadas nos espaços de nomes asm-ingress e onlineboutique.

   O comando seguinte usa sed para atualizar o manifesto acm-config.yaml para que o Config Sync implemente os recursos associados.

   sed -i "s,root-sync/fix-default-deny-authorization-policy,root-sync/deploy-authorization-policies,g" ~/asm-acm-tutorial-dir/acm-config.yaml
   gcloud beta container fleet config-management apply \
       --membership ${MEMBERSHIP} \
       --config ~/asm-acm-tutorial-dir/acm-config.yaml
   

   O comando anterior implementa os seguintes recursos:

   • Um AuthorizationPolicy no asm-ingress espaço de nomes:

     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 espaço de nomes onlineboutique . Segue-se o exemplo para a app cartservice:

     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"

   • Um ServiceAccount por app nos espaços de nomes asm-ingress e onlineboutique para ter uma identidade exclusiva por app avaliada como principal no AuthorizationPolicies. Segue-se o exemplo para a app cartservice:

     apiVersion: v1
     kind: ServiceAccount
     metadata:
       name: cartservice

9. Veja o estado do Config Sync para o RootSync e os dois RepoSyncs:

   gcloud alpha anthos config sync repo describe
   

   O resultado é semelhante ao seguinte:

   getting 3 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/deploy-authorization-policies@main",
       "status": "SYNCED"
     },
     {
       "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/ingress-gateway/authorization-policies@main",
       "status": "SYNCED"
     },
     {
       "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 vir status: RECONCILING em vez de status: SYNCED, aguarde alguns minutos e execute gcloud alpha anthos config sync repo describe novamente.

   Para ver apenas as informações de um repositório, pode usar as flags --sync-name e --sync-namespace. Para ver em detalhe os recursos geridos, pode adicionar a flag --managed-resources. Para mais informações, consulte o artigo Veja o estado da sincronização de configuração em vários clusters.

10. Visite novamente a app Online Boutique a partir do navegador:

    echo http://${EXTERNAL_IP}
    

    Se aguardar alguns minutos, já deve ver o Website a funcionar novamente conforme esperado.

Veja o estado das funcionalidades de segurança do GKE Enterprise

Pode ver o estado das funcionalidades de segurança do GKE Enterprise, incluindo as políticas de autenticação e autorização, na Google Cloud consola.

1. Na Google Cloud consola, aceda à página GKE Enterprise Security.

   Aceder à segurança do GKE Enterprise

   O Resumo das políticas apresenta o estado da segurança da aplicação, incluindo o controlo de acesso ao serviço (AuthorizationPolicies) e o mTLS.

2. Clique em Auditoria de políticas para ver os estados das políticas de cargas de trabalho para o cluster e ambos os espaços de nomes (asm-ingress e onlineboutique).

   Os cartões Controlo de acesso ao serviço e Estado do mTLS oferecem uma vista geral de alto nível.

   

   A lista Workloads (Cargas de trabalho) mostra o controlo de acesso ao serviço e o estado do mTLS de cada carga de trabalho.

   

Agora, protegeu o cluster e a malha com o Policy Controller e o Config Sync.

Limpar

Para evitar incorrer em custos na sua conta do Google Cloud pelos recursos usados neste tutorial, elimine o projeto que contém os recursos ou mantenha o projeto e elimine os recursos individuais.

Elimine o projeto

Atenção: a eliminação de um projeto tem os seguintes efeitos:

• Tudo no projeto é eliminado. Se usou um projeto existente para as tarefas neste documento, quando o elimina, também elimina qualquer outro trabalho que tenha feito no projeto.
• Os IDs dos projetos personalizados são perdidos. Quando criou este projeto, pode ter criado um ID do projeto personalizado que quer usar no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, elimine os recursos selecionados no projeto em vez de eliminar o projeto inteiro.

Se planeia explorar várias arquiteturas, tutoriais ou inícios rápidos, a reutilização de projetos pode ajudar a evitar exceder os limites de quota de projetos.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Elimine recursos individuais

Para eliminar os recursos individuais:

1. Anule o registo do cluster na frota:

   gcloud

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

   O resultado é semelhante ao seguinte:

   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.
   

   Config Connector

   kubectl delete -f ~/asm-acm-tutorial-dir/fleet-membership.yaml
   

2. Elimine o cluster:

   gcloud

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

   Prima y quando lhe for pedido. Este comando pode demorar mais de cinco minutos a ser concluído.

   O resultado é semelhante ao seguinte:

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

   Config Connector

   kubectl delete -f ~/asm-acm-tutorial-dir/container-cluster.yaml
   

3. Elimine os ficheiros que criou:

   rm -r ~/asm-acm-tutorial-dir
   

O que se segue?

• Descubra as práticas recomendadas de segurança da Cloud Service Mesh.
• Saiba mais sobre o pacote de políticas de malha de serviços na nuvem.
• Explore a biblioteca de modelos de restrições do Policy Controller.
• Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.