O Anthos Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Ativar recursos opcionais no plano de controle gerenciado

Com o Cloud Service Mesh gerenciado, é possível ativar recursos opcionais da malha personalizando recursos ConfigMap no cluster. É possível configurar o reforço da segurança, como imagens de proxy sem distribuição, restringir o tráfego de saída externo com políticas de tráfego de saída e personalizar a amostragem de rastreamento enquanto o Google gerencia a manutenção e os upgrades do plano de controle.

A disponibilidade de recursos varia de acordo com a implementação do plano de controle e o canal de lançamento. Para mais informações, consulte Recursos compatíveis com as APIs do Istio (plano de controle gerenciado) e Ativar recursos opcionais em um plano de controle no cluster.

Imagem de proxy distroless

Clusters integrados diretamente (clusters integrados diretamente ao plano de controle gerenciado do TRAFFIC_DIRECTOR): apenas o tipo de imagem distroless é compatível. Não é possível mudar essa opção. A imagem default não é compatível.
Clusters migrados (clusters migrados do plano de controle ISTIOD para TRAFFIC_DIRECTOR): o tipo de imagem é definido como padrão para a imagem default (que contém binários de depuração). Você pode ativar explicitamente as imagens distroless para melhorar a segurança.

O distroless é o tipo de imagem recomendado para melhorar a segurança. Como prática recomendada, restrinja o conteúdo de um ambiente de execução do contêiner apenas aos pacotes necessários. Essa abordagem melhora a segurança e a proporção de sinal para ruído dos verificadores de vulnerabilidades e exposições comuns (CVEs, na sigla em inglês). O Istio fornece imagens de proxy com base em imagens de base distroless.

A imagem distroless não contém binários além do proxy. Portanto, não é possível aplicar exec a um shell ou usar curl, ping ou outros utilitários de depuração no contêiner. No entanto, é possível usar contêineres efêmeros para anexar a um pod de carga de trabalho em execução e inspecioná-lo e executar comandos personalizados. Por exemplo, consulte Coletar registros do Cloud Service Mesh.

A configuração a seguir ativa imagens distroless para todo o Cloud Service Mesh. Uma alteração no tipo de imagem requer que cada pod seja reiniciado e seja reinjetado para entrar em vigor.

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: istio-release-channel
       namespace: istio-system
     data:
       mesh: |-
         defaultConfig:
           image:
             imageType: distroless

É possível substituir o imageType usando a seguinte anotação de pod. Em clusters com o plano de controle TRAFFIC_DIRECTOR gerenciado, apenas distroless é compatível como um valor de substituição explícito. debug ou outros tipos de imagens não distroless não são permitidos.

sidecar.istio.io/proxyImageType: distroless

Após mudar o tipo de imagem de uma implantação usando a anotação, a implantação precisa ser reiniciada. Para reverter para a imagem padrão, remova a anotação sidecar.istio.io/proxyImageType ou o campo imageType do MeshConfig e reinicie a implantação.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Como não exige uma imagem base de depuração, a maioria dos tipos de depuração de proxy deve usar gcloud beta container fleet mesh debug proxy-status / proxy-config (detalhes).

Política de tráfego de saída

Por padrão, outboundTrafficPolicy é definido como ALLOW_ANY. Nesse modo, todo o tráfego para qualquer serviço externo é permitido. Para controlar e restringir o tráfego apenas aos serviços externos para os quais entradas de serviço estão definidas, é possível mudar o comportamento padrão de ALLOW_ANY para REGISTRY_ONLY.

A configuração a seguir configura o outboundTrafficPolicy como REGISTRY_ONLY:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
data:
  mesh: |-
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY

em que release-channel é o canal de lançamento (asm-managed, asm-managed-stable ou asm-managed-rapid).

Você pode fazer as alterações de configuração necessárias no configmap usando o comando a seguir:
```
kubectl edit configmap istio-release-channel -n istio-system -o yaml
```

Execute este comando para exibir o configmap:

kubectl get configmap istio-release-channel -n istio-system -o yaml

Para verificar se outboundTrafficPolicy está ativado com REGISTRY_ONLY, verifique se as seguintes linhas aparecem na seção mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    outboundTrafficPolicy:
     mode: REGISTRY_ONLY
...
```

Autenticação de usuário final

É possível configurar a autenticação gerenciada do usuário do Cloud Service Mesh para autenticação do usuário final baseada em navegador e controle de acesso às cargas de trabalho implantadas. Para mais informações, consulte Como configurar a autenticação do usuário do Cloud Service Mesh.

Configure a versão de TLS mínima para suas cargas de trabalho

Se você fez a integração diretamente ao Cloud Service Mesh com uma implementação do plano de controle TRAFFIC_DIRECTOR gerenciada, não será possível mudar essa configuração.

Use o campo minProtocolVersion para especificar a versão de TLS mínima para as conexões TLS entre as cargas de trabalho. Para mais informações sobre como configurar a versão de TLS mínima e verificar a configuração de TLS das cargas de trabalho, consulte Configuração de versão de TLS mínima de carga de trabalho do Istio.

O exemplo a seguir mostra um ConfigMap definindo a versão mínima de TLS para cargas de trabalho como 1.3:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
data:
  mesh: |-
    meshMTLS:
      minProtocolVersion: TLSV1_3