Políticas de autorización y seguridad de redes perimetrales

En esta página, se muestra cómo crear políticas de autorización en redes ambientales.

Requisitos previos

Antes de completar los pasos de este documento, debes cumplir con las siguientes condiciones:

  • Un clúster de GKE en ejecución con la red ambiental de Cloud Service Mesh habilitada.
  • Un espacio de nombres inscrito en redes ambientales (por ejemplo, ambient-test) con cargas de trabajo de cliente y servidor de muestra implementadas.
  • TLS mutua (mTLS) habilitada entre las cargas de trabajo del cliente y del servidor con un GCPServerTLSPolicy (con mtlsMode: Strict) y un GCPClientTLSPolicy. Las reglas basadas en la identidad GCPAuthzPolicy que coinciden con CLIENT_CERT_URI_SAN requieren mTLS activo para extraer la identidad SPIFFE del cliente.

Para obtener información detallada sobre la configuración del entorno, consulta Cómo preparar la red ambiental de GKE.

Política de denegación predeterminada

De forma predeterminada, la API de la política de autorización ambiental de GKE permite todo el tráfico, a menos que la política lo restrinja, lo que coincide con el comportamiento estándar de NetworkPolicy de Kubernetes.

La acción DENY_BY_DEFAULT te permite cambiar este comportamiento predeterminado. Cuando se aplica a un espacio de nombres, esta política bloquea todo el tráfico a las cargas de trabajo en ese espacio de nombres, a menos que una política de ALLOW lo permita explícitamente.

En esta página, se muestra cómo configurar y usar DENY_BY_DEFAULT en Cloud Service Mesh para establecer una postura segura de forma predeterminada para tus cargas de trabajo.

Limitaciones

Antes de aplicar una política de DENY_BY_DEFAULT, ten en cuenta las siguientes limitaciones:

  • Solo puedes crear una política de DENY_BY_DEFAULT por espacio de nombres.
  • Una política con la acción DENY_BY_DEFAULT no puede tener reglas definidas.
  • Usa esta acción para establecer un valor de referencia matchLabels: {} a nivel del espacio de nombres para segmentar todos los Pods. No puedes usar DENY_BY_DEFAULT para restricciones por Pod.

Configura una política de autorización de denegación predeterminada

Para establecer un valor predeterminado de rechazo en un espacio de nombres y permitir de forma selectiva el acceso a cargas de trabajo específicas, sigue estos pasos:

  1. Crea y aplica un GCPAuthzPolicy con la acción establecida en DENY_BY_DEFAULT a tu espacio de nombres.

    cat <<EOF > deny-by-default-policy.yaml && kubectl apply -f deny-by-default-policy.yaml
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: deny-by-default-authz
  namespace: ambient-test
spec:
  action: DENY_BY_DEFAULT
  enforcementLevel: L4
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels: {}
EOF

    El resultado es similar al siguiente:

     gcpauthzpolicy.networking.gke.io/deny-by-default-authz created

    De forma predeterminada, esta política bloquea todo el tráfico entrante (este-oeste y de entrada) a las cargas de trabajo en el espacio de nombres ambient-test. No restringe el tráfico saliente que se origina en las cargas de trabajo del espacio de nombres.

  2. Para permitir el tráfico de forma selectiva, crea y aplica una política de ALLOW:

    cat <<EOF > allow-policy.yaml && kubectl apply -f allow-policy.yaml
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: allow-client-to-server
  namespace: ambient-test
spec:
  action: ALLOW
  enforcementLevel: L4
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
  rules:
  - from:
      sources:
      - principals:
      - principalSelector: CLIENT_CERT_URI_SAN
        principal:
          type: Exact
          value: spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client
EOF

    Reemplaza PROJECT_ID con el ID del proyecto.

    La propagación de la política puede tardar hasta tres minutos después de la aceptación del controlador. Espera tres minutos antes de continuar.

  3. Prueba la conectividad del cliente al servidor. Debería tener éxito porque coincide con la política ALLOW.

    kubectl exec -it deploy/client -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local

  4. Prueba la conectividad del servidor a sí mismo (o a cualquier otra carga de trabajo sin una política de permiso explícita). Debería fallar debido a la política de DENY_BY_DEFAULT.

    kubectl exec -it deploy/server -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local

    El resultado es similar al siguiente:

    curl: (52) Empty reply from server.

Logging

Cuando la política de autorización rechaza una solicitud, los registros de acceso del proxy de GKE Ambient contienen los siguientes campos en la carga útil de JSON:

  • jsonPayload.error_details: Establecer en - rbac_access_denied_matched_policy[none]

Puedes usar el Explorador de registros en la consola de Cloud de Confiance para ver las entradas del registro de acceso de las conexiones rechazadas. Consulta Cómo verificar que el tráfico esté autenticado y autorizado.

Políticas de seguridad de salida

Para inspeccionar y controlar el tráfico saliente de las cargas de trabajo de redes ambientales hacia extremos externos o Internet, puedes enrutar el tráfico de salida a través de Secure Web Proxy (SWP).

Si deseas obtener instrucciones para configurar los recursos GCPBackend y GCPEgressRouting, consulta Cómo enrutar el tráfico de salida ambiental a través de Secure Web Proxy.