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

Nesta página, descrevemos como ativar recursos opcionais no Cloud Service Mesh gerenciado. Para informações sobre o plano de controle no cluster, consulte Como ativar recursos opcionais no plano de controle no cluster.

Ao provisionar o Cloud Service Mesh gerenciado, os recursos compatíveis variam de acordo com a implementação do plano de controle, e alguns recursos só estão disponíveis na lista de permissões. Consulte os recursos compatíveis para mais detalhes. Se você estiver usando uma configuração baseada em IstioOperator, o

Imagem de proxy distroless

Clusters integrados diretamente (clusters integrados diretamente ao plano de controle TRAFFIC_DIRECTOR gerenciado): apenas o tipo de imagem distroless é compatível. Não é possível mudar isso. 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 a imagem default (que contém binários de depuração). É possível 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 exec 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 para 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. Para 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 imagem não distroless não são permitidos).

sidecar.istio.io/proxyImageType: distroless

Depois de 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 requer uma imagem de base de depuração, a maioria dos tipos de depuração de proxy precisa 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 alterar o comportamento padrão de ALLOW_ANY para REGISTRY_ONLY.

A configuração a seguir configura a 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 seu canal de lançamento (asm-managed, asm-managed-stable ou asm-managed-rapid).

É possível fazer as mudanças de configuração necessárias anteriores 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 linhas a seguir 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ê tiver integrado diretamente ao Cloud Service Mesh com uma implementação do TRAFFIC_DIRECTOR plano de controle gerenciado, 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