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:
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
ouasm-managed-rapid
).Execute este comando para ver o configmap:
kubectl get configmap istio-release-channel -n istio-system -o yaml
Para verificar se a geração de registros de acesso está ativada, verifique se a linha
accessLogFile: /dev/stdout
aparece na seçãomesh:
.... apiVersion: v1 data: mesh: | .... accessLogFile: /dev/stdout ...
Ativar o Cloud Tracing
Execute os seguintes comandos para ativar o Cloud Trace:
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
ouasm-managed-rapid
).Execute este comando para ver o configmap:
kubectl get configmap istio-release-channel -n istio-system -o yaml
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:{} ...
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
A configuração a seguir configura 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
).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
Execute este comando para ver o configmap:
kubectl get configmap istio-release-channel -n istio-system -o yaml
Para verificar se
outboundTrafficPolicy
está ativado comREGISTRY_ONLY
, verifique se as seguintes linhas aparecem na seçãomesh:
.... 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