Configura políticas de autorización en sidecars en GKE

Versión preliminar : Políticas de autorización en sidecars

Esta función está sujeta a las "Condiciones de la oferta previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de la fase previa a la DG están disponibles “sin modificaciones” y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En esta página, se proporcionan instrucciones para configurar diferentes tipos de políticas de autorización en sidecars de Cloud Service Mesh en GKE.

Antes de comenzar

Debes conocer la API de Gateway y las extensiones de autorización.

Antes de crear una política de autorización, debes completar los siguientes pasos:

Accede a tu cuenta de Google Cloud . Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Network Security, Network Services APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Network Security, Network Services APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

Nota: Después de crear o cambiar una política de autorización, los sidecars pueden tardar hasta 15 minutos en comenzar a aplicarla.

AuthzPolicy para todo el espacio de nombres

Si deseas rechazar un patrón de tráfico esperado para todo el espacio de nombres, configura una política de autorización para rechazar cualquier solicitud HTTP entrante a todas las cargas de trabajo en un espacio de nombres:

cat >ns-authz-policy-deny.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: ns-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/bad_token"
  action: DENY
  enforcementLevel: L7
EOF
kubectl apply -f ns-authz-policy-deny.yaml

El selector: {} vacío se orienta a todos los Pods del espacio de nombres.

Si deseas permitir un patrón de tráfico esperado para todo el espacio de nombres, configura una política de autorización que permita cualquier solicitud HTTP entrante a todas las cargas de trabajo de un espacio de nombres:

cat >ns-authz-policy-allow.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: ns-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/headers"
        methods: ["GET"]
  action: ALLOW
  enforcementLevel: L7
EOF
kubectl apply -f ns-authz-policy-allow.yaml

El selector: {} vacío se orienta a todos los Pods del espacio de nombres.

Rechaza las solicitudes entrantes a una carga de trabajo

Si tienes una carga de trabajo que solo debe realizar llamadas salientes, como un trabajo cron, configura una política de autorización para rechazar cualquier solicitud HTTP entrante a la carga de trabajo:

cat >deny-path-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: my-workload-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/deny_path"
  action: DENY
  enforcementLevel: L7
EOF
kubectl apply -f deny-path-authz-policy.yaml

El resultado es similar al siguiente:

gcpauthzpolicy.networking.gke.io/my-workload-authz created

Después de aplicar esta política, se rechazará cualquier solicitud HTTP entrante a la ruta de acceso /deny_path en los Pods que coincidan con la app: EXAMPLE_APP y el emisor recibirá un código de respuesta HTTP 403 Forbidden.

Permite solicitudes entrantes específicas para una carga de trabajo

También puedes configurar una política de ALLOW que permita solo las solicitudes que coincidan con un criterio específico y rechace el resto.

En el siguiente ejemplo, se configura una política de autorización en el Deployment example-app para permitir solo solicitudes de mTLS desde Pods con la identidad spiffe://cluster.local/NAMESPACE/pod1.

cat >allow-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: my-workload-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - from:
      sources:
      - principals:
        - principal:
            type: Exact
            value: "spiffe://cluster.local/NAMESPACE/pod1"
  action: ALLOW
  enforcementLevel: L7
EOF
kubectl apply -f allow-authz-policy.yaml

El resultado es similar al siguiente:

gcpauthzpolicy.networking.gke.io/my-workload-authz created

Solo las solicitudes entrantes autenticadas con mTLS que presenten la identidad SPIFFE exacta spiffe://cluster.local/NAMESPACE/pod1 recibirán un HTTP 200 OK. El proxy rechazará cualquier otra solicitud con un error HTTP 403 Forbidden.

Delega a un motor de autorización externo

Puedes usar tu propio motor de autorización y configurar Cloud Service Mesh para delegar todas las decisiones de autorización de una carga de trabajo al motor configurado.

1. Instala la CRD de GCPAuthzExtension si aún no está instalada:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/main/config/crd/networking.gke.io_gcpauthzextensions.yaml
   

2. Implementa una carga de trabajo de extensión de autorización basada en textos destacados en Kubernetes que admita el protocolo gRPC ext_proc y configura un recurso de extensión de autorización:

   cat >authz-extension.yaml <<EOF
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzExtension
   metadata:
     name: my-authz-ext
     namespace: NAMESPACE
   spec:
     backendRef:
       group: ""
       kind: Service
       name: authz-service
       port: PORT
     authority: "authz-service.NAMESPACE.svc.cluster.local"
     forwardHeaders:
     - Authorization
     failOpen: false
     timeout: "100ms"
     wireFormat: ExtProcGRPC
   EOF
   kubectl apply -f authz-extension.yaml
   

   Reemplaza lo siguiente:

   • NAMESPACE: Es el espacio de nombres del Service de authz-service y las cargas de trabajo.
   • PORT: Es el puerto del Service de authz-service que entrega la API de gRPC de ext_proc.

   Este comando crea una extensión de autorización basada en llamadas que se ejecuta como un servicio de Kubernetes authz-service.

   El resultado es similar al siguiente:

   gcpauthzextension.networking.gke.io/my-authz-ext created
   

3. Configura la política de autorización para delegar las decisiones de autorización de la carga de trabajo a la extensión de autorización configurada antes:

   cat >authz-policy.yaml <<EOF
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzPolicy
   metadata:
     name: my-workload-authz
     namespace: NAMESPACE
   spec:
     targetRefs:
     - group: ""
       kind: Pod
       selector:
         matchLabels:
           app: EXAMPLE_APP
     rules:
     - from:
         sources:
         - principals:
           - principal:
               type: Exact
               value: "spiffe://cluster.local/NAMESPACE/pod1"
       to:
         operations:
         - paths:
           - type: Exact
             value: "/api/payments-schedule"
     action: CUSTOM
     enforcementLevel: L7
     customProviders:
       extensionRefs:
       - group: networking.gke.io
         kind: GCPAuthzExtension
         name: my-authz-ext
   EOF
   kubectl apply -f authz-policy.yaml
   

   El resultado es similar al siguiente:

   gcpauthzpolicy.networking.gke.io/my-workload-authz created
   

   El proxy espera a que la extensión de autorización responda antes de reenviar la solicitud a la aplicación. Si la extensión rechaza la solicitud finalizando la llamada con un error, o si la llamada falla o se agota el tiempo de espera mientras failOpen es false, el emisor recibe una respuesta HTTP 500. Si la extensión envía una respuesta inmediata, el emisor recibe el código de estado de esa respuesta.