Configura la seguridad del transporte
En Cloud Service Mesh con las APIs de Istio para cargas de trabajo de Kubernetes, la TLS mutua automática (mTLS automática) está habilitada de forma predeterminada. Con la mTLS automática, un proxy de sidecar del cliente detecta automáticamente si el servidor tiene un sidecar. El sidecar del cliente envía mTLS a las cargas de trabajo con sidecars y envía texto sin formato a las cargas de trabajo sin sidecars. Sin embargo, ten en cuenta que los servicios aceptan el texto sin formato y el tráfico mTLS. A medida que inyectes proxies de sidecar a tus Pods, recomendamos que también configures tus servicios para que solo acepten tráfico mTLS.
Con Cloud Service Mesh, puedes aplicar una política de PeerAuthentication para configurar tus servicios de modo que solo acepten mTLS. Cloud Service Mesh te brinda la flexibilidad para aplicar una política de autenticación a toda la malla de servicios, a un espacio de nombres o a una carga de trabajo individual. Cuando especificas una política para una carga de trabajo específica, esa política tiene prioridad. Por ejemplo, una política específica de carga de trabajo tiene prioridad sobre una específica de espacio de nombres. Si no se especifica ninguna política para la carga de trabajo, hereda la política del espacio de nombres o la malla.
Consulta Funciones compatibles para obtener detalles sobre qué
campos del PeerAuthentication CR son compatibles con la plataforma.
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
Si quieres configurar 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 deseada.
Sin embargo, Cloud Service Mesh no puede agregar políticas a nivel de las cargas de trabajo para el tráfico mTLS saliente a un servicio. Debes configurar una regla de destino para administrar ese comportamiento.
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 EOFResultado esperado:
peerauthentication.security.istio.io/AUTH_POLICY_NAME created
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 EOFResultado 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 correctamente mTLS 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
- Servidor: Usas un recurso
PeerAuthenticationpara establecer el valor predeterminado del proxy del servidor. - Cliente: Usas un recurso
DestinationRulepara 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 definir la política de forma explícita.
Paso 2: Configura 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 de PeerAuthentication de forma forzosa, puedes borrarla con kubectl delete:
kubectl delete peerauthentication -n NAMESPACE AUTH_POLICY_NAME