Ative funcionalidades opcionais no plano de controlo gerido

Esta página descreve como ativar funcionalidades opcionais na Cloud Service Mesh gerida. Para obter informações sobre o plano de controlo no cluster, consulte o artigo Ativar funcionalidades opcionais no plano de controlo no cluster.

Quando aprovisiona o Cloud Service Mesh gerido, as funcionalidades suportadas diferem com base na implementação do painel de controlo, e determinadas funcionalidades só estão disponíveis através da lista de autorizações. Consulte as funcionalidades suportadas para ver detalhes. Se estiver a usar uma configuração baseada no IstioOperator, a ferramenta Migrar do IstioOperator pode ajudar a fazer a conversão para a configuração suportada pelo plano de controlo gerido.

Imagem de proxy sem distribuição

Se fez a integração direta no Cloud Service Mesh com uma TRAFFIC_DIRECTOR implementação do plano de controlo> gerida, apenas o tipo de imagem sem distribuição é suportado. Não pode alterá-lo.
Se a sua frota usou originalmente a implementação do ISTIOD plano de controlo e foi migrada para a implementação TRAFFIC_DIRECTOR, o tipo de imagem permaneceu inalterado durante a migração, e pode alterar o tipo de imagem para distroless.

Como prática recomendada, deve restringir o conteúdo de um tempo de execução do contentor apenas aos pacotes necessários. Esta abordagem melhora a segurança e a relação sinal/ruído dos scanners de vulnerabilidades e exposições comuns (CVE). O Istio fornece imagens de proxy baseadas em imagens de base sem distribuição.

A imagem do proxy sem distribuição não contém binários que não sejam o proxy. Por conseguinte, não é possível exec um shell nem usar curl, ping ou outras utilidades de depuração no contentor. No entanto, pode usar contentores efémeros para anexar a um pod de carga de trabalho em execução para poder inspecioná-lo e executar comandos personalizados. Por exemplo, consulte o artigo Recolher registos da malha de serviços na nuvem.

A seguinte configuração ativa as imagens sem distribuição para toda a malha de serviços na nuvem. Uma alteração do tipo de imagem requer que cada pod seja reiniciado e reinjetado para entrar em vigor.

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

Pode substituir o imageType através da seguinte anotação de pod.

sidecar.istio.io/proxyImageType: debug

Depois de alterar o tipo de imagem de uma implementação através da anotação, a implementação deve ser reiniciada.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Uma vez que não requer 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 predefinição, outboundTrafficPolicy está definido como ALLOW_ANY. Neste 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 estão definidas entradas de serviço, pode alterar o comportamento predefinido de ALLOW_ANY para REGISTRY_ONLY.

A seguinte configuração configura o outboundTrafficPolicy para 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).

Pode fazer as alterações de configuração necessárias anteriores no configmap através do seguinte comando:
```
kubectl edit configmap istio-release-channel -n istio-system -o yaml
```

Execute o seguinte comando para ver o configmap:

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

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

Autenticação do utilizador final

Pode configurar a autenticação de utilizadores do Cloud Service Mesh gerido para a autenticação de utilizadores finais baseada no navegador e o controlo de acesso aos seus workloads implementados. Para mais informações, consulte o artigo Configurar a autenticação de utilizadores da malha de serviços na nuvem.

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

Se fez a integração diretamente no Cloud Service Mesh com uma TRAFFIC_DIRECTOR implementação do plano de controlo> gerida, não pode alterar esta definição.

Pode usar o campo minProtocolVersion para especificar a versão mínima do TLS para as ligações TLS entre as suas cargas de trabalho. Para mais informações sobre a definição da versão mínima do TLS e a verificação da configuração do TLS das suas cargas de trabalho, consulte o artigo Configuração da versão mínima do TLS da carga de trabalho do Istio.

O exemplo seguinte mostra uma ConfigMap que define a versão mínima do 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