Ativar recursos opcionais no plano de controle gerenciado
Esta página descreve como ativar recursos opcionais em ambientes do Cloud 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 um Cloud Service Mesh gerenciado, os recursos com suporte são diferentes
com base na implementação do plano de controle, e alguns recursos são
disponível pela lista de permissões. Consulte
recursos compatíveis para saber mais.
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ê se integrou diretamente ao Cloud Service Mesh com um
TRAFFIC_DIRECTOR
gerenciado implementação do plano de controle, somente o tipo de imagem distroless será aceito. Não é possível mudar isso.Se a frota usava originalmente a implementação do plano de controle
ISTIOD
e foi migrada 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.
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 no 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 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
Após 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 não exige uma imagem base de depuração, a maioria dos tipos de depuração de proxy
usa 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. Controlar e restringir o tráfego
apenas aos serviços externos para os quais
Entradas de serviço
for definida, é possível mudar o comportamento padrão de ALLOW_ANY
para
REGISTRY_ONLY
.
A configuração a seguir define o
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
, verifique 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 com controle de acesso e autenticação de usuário final baseada em navegador nas do Google Cloud. Para mais informações, consulte Como configurar a autenticação de usuário do Cloud Service Mesh.
Configure a versão de TLS mínima para suas cargas de trabalho
Se você se integrou diretamente ao Cloud Service Mesh com um TRAFFIC_DIRECTOR
gerenciado
implementação do plano de controle,
não será possível alterar 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