Configura la seguridad del transporte

Puedes proteger el tráfico entre servicios en Cloud Service Mesh con las APIs de Istio aplicando la TLS mutua (mTLS) estricta. En las cargas de trabajo de Kubernetes, la mTLS automática está habilitada de forma predeterminada: los proxies de sidecar del cliente envían automáticamente tráfico de mTLS a los sidecars, pero los servicios de destino siguen aceptando solicitudes encriptadas y de texto simple.

Las políticas de PeerAuthentication te permiten restringir los servicios para que solo acepten mTLS. Puedes aplicar una política a toda la malla, a un espacio de nombres específico o a una carga de trabajo individual. Para conocer los campos compatibles en las distintas plataformas, consulta Funciones compatibles.

Habilita TLS mutua por espacio de nombres

A fin de habilitar mTLS para todas las cargas de trabajo dentro de un espacio de nombres en particular, usa una política de autenticación de todo el espacio de nombres. Especifica el espacio de nombres que se aplica en metadata.

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "AUTH_POLICY_NAME"
  namespace: "NAMESPACE"
spec:
  mtls:
    mode: STRICT
EOF

Resultado esperado:

peerauthentication.security.istio.io/AUTH_POLICY_NAME created

Habilita TLS mutua por carga de trabajo

Para establecer una política de PeerAuthentication para una carga de trabajo específica, debes configurar la sección selector y especificar las etiquetas que coincidan con la carga de trabajo de destino. Sin embargo, Cloud Service Mesh no puede agregar políticas a nivel de la carga de trabajo para el tráfico mTLS saliente a un servicio. Debes configurar una regla de destino para administrar ese comportamiento.

  1. Aplica una política de autenticación a una carga de trabajo específica en tu espacio de nombres:

    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
    EOF
    

    Resultado esperado:

    peerauthentication.security.istio.io/AUTH_POLICY_NAME created
  2. Configura una regla de destino que coincida:

    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
    EOF
    

    Resultado esperado:

    destinationrule.networking.istio.io/WORKLOAD created

Aplica la mTLS en toda la malla

Para evitar que todos tus servicios de la malla acepten tráfico de texto sin formato, configura una política PeerAuthentication en toda la malla con el modo mTLS establecido en STRICT (el valor predeterminado es PERMISSIVE). La política PeerAuthentication de toda la malla no debe tener un selector y debe aplicarse en el espacio de nombres raíz, istio-system. Cuando implementas la política, el plano de control aprovisiona automáticamente certificados TLS para que las cargas de trabajo puedan autenticarse entre sí.

Para aplicar mTLS en toda la malla, sigue estos pasos:

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "AUTH_POLICY_NAME"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

Resultado esperado:

peerauthentication.security.istio.io/AUTH_POLICY_NAME created

Inhabilita mTLS para CSM administrado

Cloud Service Mesh no admite el valor mtls.mode: DISABLE en un recurso PeerAuthentication.

Para inhabilitar mTLS de forma correcta en Cloud Service Mesh, debes definir de forma explícita el comportamiento del cliente con los requisitos del servidor mediante la API de DestinationRule.

Descripción general de conceptos

  1. Del lado del servidor: Usa un recurso PeerAuthentication para establecer el valor predeterminado del proxy del lado del servidor.
  2. Enfoque del cliente: Usas un recurso DestinationRule para indicar de forma explícita a los proxies del cliente que usen texto sin formato cuando se comuniquen con ese servidor específico.

Ejemplos

Paso 1: Configura PeerAuthentication

En este ejemplo, usaremos la política predeterminada de PERMISSIVE, por lo que no es necesario definirla de forma explícita.

Paso 2: Configura la DestinationRule del cliente

Esta configuración indica a los clientes que usen texto sin formato cuando llamen a 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

Busca y borra políticas de PeerAuthentication

Para obtener una lista de todas las políticas de PeerAuthentication en la malla de servicios, haz lo siguiente:

kubectl get peerauthentication --all-namespaces

Si se aplica una política PeerAuthentication de forma forzosa, puedes borrarla con kubectl delete:

kubectl delete peerauthentication -n NAMESPACE AUTH_POLICY_NAME

¿Qué sigue?