Nesta página, descrevemos como ativar recursos opcionais no Cloud Service Mesh com istiod 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 ativados por padrão variam de acordo com a 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.
Imagem de proxy distroless
Se você tiver integrado diretamente ao Cloud Service Mesh com uma implementação de plano de controle
TRAFFIC_DIRECTOR
gerenciada, apenas o tipo de imagem distroless será compatível. Não é possível alterá-la.Se a frota usava originalmente a implementação do plano de controle
ISTIOD
e foi migrado para a implementaçãoTRAFFIC_DIRECTOR
, o tipo de imagem não foi alterado durante a migração e você pode mudar o tipo de imagem para distroless por conta própria.
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 usar exec
em um shell ou usar curl
, ping
ou outros
utilitários de depuração dentro do contêiner. No entanto, é possível usar contêineres temporários para anexar a um pod de carga de trabalho em execução para inspecioná-lo e executar comandos personalizados. Por exemplo, consulte
Como 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
Substitua imageType
usando a anotação de pod a seguir.
sidecar.istio.io/proxyImageType: debug
Depois de alterar o tipo de imagem de uma implantação usando a anotação, a implantação precisa ser reiniciada.
kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME
Como ela 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 as
entradas de serviço
estão definidas, altere o comportamento padrão de ALLOW_ANY
para
REGISTRY_ONLY
.
A configuração a seguir define
outboundTrafficPolicy
comoREGISTRY_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
ouasm-managed-rapid
).É possível fazer as alterações anteriores necessárias no configmap usando o seguinte comando:
kubectl edit configmap istio-release-channel -n istio-system -o yaml
Execute este comando para ver o configmap:
kubectl get configmap istio-release-channel -n istio-system -o yaml
Para verificar se o
outboundTrafficPolicy
está ativado comREGISTRY_ONLY
, confira se as linhas abaixo aparecem na seçãomesh:
.... apiVersion: v1 data: mesh: | outboundTrafficPolicy: mode: REGISTRY_ONLY ...
Autenticação de usuário final
É possível configurar a autenticação de usuário gerenciada do Cloud Service Mesh para autenticação de 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 de usuários do Cloud 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