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 Ambient Networking.

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 las redes de Ambient de Cloud Service Mesh habilitadas.
  • Un espacio de nombres inscrito en Ambient Networking (por ejemplo, ambient-test) con cargas de trabajo de cliente y servidor de ejemplo 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 de GCPAuthzPolicy basadas en la identidad que coinciden con CLIENT_CERT_URI_SAN requieren mTLS activo para extraer la identidad de SPIFFE del cliente.

Para obtener una configuración detallada del entorno, consulta Prepara Ambient Networking de GKE.

Política de denegación predeterminada

De forma predeterminada, la API de AuthorizationPolicy de GKE Ambient permite todo el tráfico, a menos que esté restringido por una política, 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 ALLOW lo permita de forma explícita.

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 ninguna regla definida.
  • Usa esta acción para establecer un matchLabels: {} de referencia en todo el espacio de nombres para orientar todos los Pods. No puedes usar DENY_BY_DEFAULT para las restricciones por Pod.

Configura una política de autorización de rechazo predeterminado

Para establecer un modelo de referencia de denegación predeterminada en un espacio de nombres y permitir el acceso de forma selectiva a cargas de trabajo específicas, sigue estos pasos:

  1. Crea y aplica un GCPAuthzPolicy con la acción establecida en DENY_BY_DEFAULT en 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

    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 de forma predeterminada. 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 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 una política de autorización rechaza una solicitud, el proxy del nodo escribe una entrada de registro de acceso en Cloud Logging con el nombre de registro gke-ambient-node-proxy-accesslog. La entrada contiene el siguiente campo en la carga útil de JSON:

  • jsonPayload.error_details: - 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:

resource.type="k8s_container"
logName="projects/PROJECT_ID/logs/gke-ambient-node-proxy-accesslog"
jsonPayload.error_details=~"rbac_access_denied"

Para obtener más información, consulta Verifica 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 Ambient Networking a los extremos externos o a Internet, puedes enrutar el tráfico de salida a través de Secure Web Proxy (SWP).

Para obtener instrucciones sobre cómo configurar los recursos GCPBackend y GCPEgressPolicy, consulta Enruta el tráfico de salida de Ambient a través de Secure Web Proxy.