Configurar a segurança de transporte
No Cloud Service Mesh com APIs do Istio para cargas de trabalho do Kubernetes, o TLS mútuo automático (mTLS automático) é ativado por padrão. Com o mTLS automático, um proxy sidecar do cliente detecta automaticamente se o servidor tem um sidecar. O sidecar do cliente envia mTLS para cargas de trabalho com sidecars e texto simples para cargas de trabalho sem sidecars. No entanto, os serviços aceitam tráfego de texto simples e mTLS. Ao injetar proxies sidecar nos seus pods, recomendamos que você também configure seus serviços para aceitar apenas tráfego mTLS.
Com o Cloud Service Mesh, é possível configurar seus serviços para aceitar apenas mTLS
aplicando uma política PeerAuthentication. O Cloud Service Mesh oferece a
flexibilidade de aplicar a política a toda a malha de serviço, a um namespace ou
a uma carga de trabalho individual. Quando você especifica uma política para uma carga de trabalho específica,
essa política tem precedência. Por exemplo, uma política específica de carga de trabalho
tem precedência sobre uma específica de namespace. Se nenhuma política for especificada para a
carga de trabalho, ela herdará a do namespace ou da malha.
Consulte Recursos compatíveis para saber quais
campos do CR PeerAuthentication são compatíveis com a plataforma.
Ativar o TLS mútuo por namespace
Para ativar o mTLS para todas as cargas de trabalho em um namespace específico, use uma
política de autenticação em todo o namespace. Especifique o namespace a que ele se aplica
em metadata.
kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "AUTH_POLICY_NAME"
namespace: "NAMESPACE"
spec:
mtls:
mode: STRICT
EOF
Resposta esperada:
peerauthentication.security.istio.io/AUTH_POLICY_NAME created
Ativar o TLS mútuo por carga de trabalho
Para definir uma política PeerAuthentication para uma carga de trabalho específica, configure
a seção selector e especifique os rótulos que correspondem à carga de trabalho pretendida.
No entanto, o Cloud Service Mesh não agrega políticas no nível da carga de trabalho para o tráfego mTLS de
saída para um serviço. Você precisa configurar uma regra de destino para gerenciar esse comportamento.
Aplique uma política de autenticação a uma carga de trabalho específica no seu namespace:
cat <<EOF | kubectl apply -n NAMESPACE -f - apiVersion: "security.istio.io/v1beta1" kind: "PeerAuthentication" metadata: name: "AUTH_POLICY_NAME" namespace: "NAMESPACE" spec: selector: matchLabels: app: WORKLOAD mtls: mode: STRICT EOFResposta esperada:
peerauthentication.security.istio.io/AUTH_POLICY_NAME created
Configure uma regra de destino correspondente:
cat <<EOF | kubectl apply -n NAMESPACE -f - apiVersion: "networking.istio.io/v1alpha3" kind: "DestinationRule" metadata: name: "DEST_RULE_NAME" spec: host: "WORKLOAD.NAMESPACE.svc.cluster.local" trafficPolicy: tls: mode: ISTIO_MUTUAL EOFResposta esperada:
destinationrule.networking.istio.io/WORKLOAD created
Aplique o mTLS em toda a malha
Para impedir que todos os serviços na malha aceitem tráfego de texto simples, defina
uma política PeerAuthentication para toda a malha com o modo mTLS definido como STRICT (o
padrão é PERMISSIVE). para criar um anexo da VLAN de monitoramento. A política PeerAuthentication em toda a malha não pode
ter um seletor e precisa ser aplicada no namespace raiz, istio-system. Quando
você implanta a política, o plano de controle provisiona automaticamente certificados TLS
para que as cargas de trabalho possam ser autenticadas entre si.
Para aplicar o mTLS em toda a malha:
kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "AUTH_POLICY_NAME"
namespace: "istio-system"
spec:
mtls:
mode: STRICT
EOF
Saída esperada:
peerauthentication.security.istio.io/AUTH_POLICY_NAME created
Como desativar o mTLS para o CSM gerenciado
O Cloud Service Mesh não oferece suporte ao valor mtls.mode: DISABLE em um recurso PeerAuthentication.
Para desativar o mTLS no Cloud Service Mesh, é necessário definir explicitamente
o comportamento do cliente com os requisitos do servidor usando a
API DestinationRule.
Visão geral conceitual
- Do lado do servidor: use um recurso
PeerAuthenticationpara definir o valor padrão do proxy do lado do servidor. - Abordagem do lado do cliente: você usa um recurso
DestinationRulepara informar explicitamente aos proxies do lado do cliente que usem texto simples ao se comunicar com esse servidor específico.
Exemplos
Etapa 1: configurar o PeerAuthentication
Neste exemplo, vamos usar a política padrão PERMISSIVE e, portanto, não precisamos definir explicitamente a política.
Etapa 2: configurar o DestinationRule do lado do cliente
Essa configuração informa aos clientes para usar texto simples ao chamar httpbin.
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: "DEST_RULE_NAME"
namespace: sample-namespace
spec:
host: "WORKLOAD.NAMESPACE.svc.cluster.local"
trafficPolicy:
tls:
mode: DISABLE
Encontrar e excluir políticas do PeerAuthentication
Para uma lista de todas as políticas PeerAuthentication na malha de serviço:
kubectl get peerauthentication --all-namespaces
Se houver uma política PeerAuthentication em vigor, exclua-a com
kubectl delete:
kubectl delete peerauthentication -n NAMESPACE AUTH_POLICY_NAME