Ativar recursos opcionais no Anthos Service Mesh gerenciado

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

Quando você provisiona o Anthos Service Mesh gerenciado, os recursos ativados por padrão diferem por plataforma. Se você estiver usando uma configuração baseada em IstioOperator hoje, a ferramenta Migrar do IstioOperator poderá ajudar a converter na configuração compatível com o plano de controle gerenciado.

Registros de acesso do Envoy

Execute os seguintes comandos para ativar a geração de registros de acesso do Envoy:

  1. Execute o seguinte comando para adicionar accessLogFile: /dev/stdout:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    data:
      mesh: |-
        accessLogFile: /dev/stdout
    kind: ConfigMap
    metadata:
      name: istio-release-channel
      namespace: istio-system
    EOF
    

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

  2. Execute este comando para ver o configmap:

    kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  3. Para verificar se a geração de registros de acesso está ativada, verifique se a linha accessLogFile: /dev/stdout aparece na seção mesh:.

    ...
    apiVersion: v1
    data:
      mesh: |
        ....
        accessLogFile: /dev/stdout
    ...
    

Ativar o Cloud Tracing

Execute os seguintes comandos para ativar o Cloud Trace:

  1. Execute este comando:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    data:
      mesh: |-
        defaultConfig:
          tracing:
            stackdriver: {}
    kind: ConfigMap
    metadata:
      name: istio-release-channel
      namespace: istio-system
    EOF
    

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

  2. Execute este comando para ver o configmap:

    kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  3. Para verificar se o Cloud Trace está ativado, verifique se as seguintes linhas aparecem na seção mesh:.

    ...
    apiVersion: v1
    data:
      mesh: |
        ....
        defaultConfig:
          tracing:
            stackdriver:{}
    ...
    
  4. Reinicie os proxies.

    Atualmente, a configuração do rastreador faz parte da configuração de inicialização do proxy. Por isso, cada pod precisa ser reiniciado e reinjetado para coletar a atualização do rastreador. Por exemplo, é possível usar o seguinte comando para reiniciar pods que pertencem a uma implantação:

    kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Para mais informações sobre cabeçalhos de trace compatíveis, consulte Como acessar traces.

Imagem de proxy distroless

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 configuração a seguir ativa imagens distroless para todo o Anthos 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

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. Se você precisar de acesso a essas ferramentas para implantações específicas, modifique imageType usando a anotação de pod a seguir.

sidecar.istio.io/proxyImageType: debug

Após alterar o tipo de imagem de uma implantação pela anotação, a implantação precisa ser reiniciada.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Para a maioria dos tipos de depuração de proxy, o istioctl proxy-cmd precisa ser usado, o que não exige uma imagem base de depuração.

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 as entradas de serviço estão definidas, é possível alterar o comportamento padrão de ALLOW_ANY para REGISTRY_ONLY

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

  2. Você pode fazer as alterações necessárias acima no configmap usando o comando abaixo

    kubectl edit configmap istio-release-channel -n istio-system -o yaml
    
  3. Execute este comando para ver o configmap:

    kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  4. 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 Anthos 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 Anthos Service Mesh.

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

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