Descripción general de la política de autorización

Las políticas de autorización te permiten establecer verificaciones de control de acceso y de limpieza de contenido cuando procesas solicitudes o respuestas a través de diferentes servicios deGoogle Cloud , como los balanceadores de cargas de aplicaciones, Agent Gateway (versión preliminar privada) y Secure Web Proxy.

En el caso de Agent Gateway y Secure Web Proxy, la política de autorización se adjunta directamente al recurso de puerta de enlace de estos servicios. En el caso de un balanceador de cargas, la política de autorización se adjunta al recurso de regla de reenvío del balanceador de cargas.

Nota: Si bien algunas partes de este documento se enfocan en las políticas de autorización en relación con Cloud Load Balancing, los conceptos de políticas de autorización que se analizan aquí se aplican a todos los servicios Google Cloud mencionados anteriormente.

Una política de autorización (AuthzPolicy), adjunta a la regla de reenvío de un balanceador de cargas, te permite especificar condiciones que permiten, restringen o delegan la autorización de solicitudes según su fuente y las operaciones previstas. Las solicitudes que pasan estas verificaciones se enrutan al servicio de backend del balanceador de cargas, mientras que las solicitudes que no las pasan se rechazan con una respuesta no autorizada.

Puedes configurar políticas de autorización en la regla de reenvío de todos los balanceadores de cargas de aplicaciones con un esquema de balanceo de cargas de EXTERNAL_MANAGED o INTERNAL_MANAGED. Los siguientes balanceadores de cargas de aplicaciones admiten políticas de autorización:

• Balanceadores de cargas de aplicaciones externos globales

• Balanceadores de cargas de aplicaciones regionales externos
• Balanceadores de cargas de aplicaciones internos regionales

• Balanceadores de cargas de aplicaciones internos entre regiones

Reglas de la política de autorización

Una política de autorización consta de una lista de reglas HTTP que se deben hacer coincidir con la solicitud entrante.

En el caso de una política de autorización con una acción ALLOW o DENY, una regla HTTP (AuthzRule) define las condiciones que determinan si se permite que el tráfico pase por el balanceador de cargas. Se requiere al menos una regla HTTP.

En el caso de una política de autorización con una acción CUSTOM, una regla HTTP (AuthzRule) define las condiciones que determinan si el tráfico se delega en el proveedor personalizado para la autorización. Se requiere un proveedor personalizado, mientras que las reglas HTTP son opcionales.

Una coincidencia de política se produce cuando al menos una regla HTTP coincide con la solicitud o cuando no se definen reglas HTTP en la política.

Una regla HTTP de política de autorización consta de los siguientes campos:

• from: Especifica la identidad del cliente que permite la regla. La identidad se puede derivar de un certificado de cliente en una conexión TLS mutua, o bien puede ser la identidad ambiental asociada con la instancia de máquina virtual (VM) del cliente, como la de una cuenta de servicio o una etiqueta segura.
• to: Especifica las operaciones permitidas por la regla, como las URLs a las que se puede acceder o los métodos HTTP permitidos.
• when: Especifica restricciones adicionales que se deben cumplir. Puedes usar expresiones de Common Expression Language (CEL) para definir las restricciones.

Acciones de la política de autorización

Cuando se evalúa una solicitud, una política de autorización especifica la acción (AuthzAction) que se aplicará a la solicitud. Una política de autorización debe tener al menos una acción, que puede ser una de las siguientes:

• ALLOW: Permite que la solicitud pase al backend si coincide con alguna de las reglas especificadas en una política de ALLOW. Si existen políticas de ALLOW, pero no hay coincidencias, se rechaza la solicitud. En otras palabras, la solicitud se rechaza si ninguna de las políticas de autorización configuradas con una acción ALLOW coincide con la solicitud. En Cloud Logging, esta acción se registra como denied_as_no_allow_policies_matched_request.

  Para que se aplique una acción ALLOW, necesitas al menos una regla HTTP.

• DENY: Rechaza la solicitud si coincide con alguna de las reglas especificadas en una política de DENY. Si existen políticas DENY, pero no hay coincidencias, se permite la solicitud. En otras palabras, la solicitud se permite si ninguna de las políticas de autorización configuradas con una acción DENY coincide con la solicitud. En Cloud Logging, esta acción se registra como allowed_as_no_deny_policies_matched_request.

  Para que se aplique una acción de DENY, necesitas al menos una regla HTTP.

• CUSTOM: Delega la decisión de autorización a un proveedor de autorización personalizado, como IAP o extensiones de servicio. Para obtener más información, consulta Cómo delegar decisiones de autorización.

  Si hay reglas HTTP configuradas para una política de CUSTOM, la solicitud debe coincidir con las reglas HTTP para invocar el proveedor personalizado. Sin embargo, si no se definen reglas HTTP, la política de autorización siempre delega la decisión de autorización en un proveedor de autorización personalizado. Para obtener más información, consulta los ejemplos en Política de autorización para delegar decisiones de autorización.

Orden de evaluación de la política de autorización

Una política de autorización admite políticas de CUSTOM, DENY y ALLOW para el control de acceso. Cuando varias políticas de autorización están asociadas a un solo recurso, primero se evalúa la política CUSTOM, luego la política DENY y, por último, la política ALLOW. La evaluación se determina según las siguientes reglas:

1. Si hay una política CUSTOM que coincide con la solicitud, la política CUSTOM se evalúa con un proveedor de autorización personalizado. Si el proveedor personalizado rechaza la solicitud, esta se deniega. No se evalúan las políticas de DENY o ALLOW, incluso si se configuró alguna.

2. Si hay alguna política DENY que coincida con la solicitud, esta se rechazará. No se evalúa ninguna política de ALLOW, incluso si están configuradas.

3. Si no existen políticas ALLOW, se permite la solicitud.

4. Si alguna de las políticas ALLOW coincide con la solicitud, permítela.

5. Si existen políticas de ALLOW, pero no hay coincidencias, se rechaza la solicitud. En otras palabras, la solicitud se rechaza de forma predeterminada si ninguna de las AuthzPolicies configuradas con la acción ALLOW coincide con la solicitud.

Para los balanceadores de cargas de aplicaciones externos regionales, los balanceadores de cargas de aplicaciones internos regionales, Agent Gateway y Secure Web Proxy (servicios que admiten perfiles de políticas), el orden de evaluación de la política de autorización es el siguiente:Google Cloud

1. Si hay una política de autorización de solicitud personalizada (REQUEST_AUTHZ) que coincide con la solicitud, la política de REQUEST_AUTHZ se evalúa con un proveedor de autorización personalizado. Si el proveedor personalizado rechaza la solicitud, esta se deniega. No se evalúan las políticas de DENY, ALLOW ni CONTENT_AUTHZ, incluso si se configuró alguna.

2. Si hay alguna política DENY que coincida con la solicitud, esta se rechazará. No se evalúan las políticas ALLOW y CONTENT_AUTHZ, incluso si están configuradas.

3. Si no existen políticas de ALLOW, la solicitud continúa con la evaluación de la autorización de contenido (CONTENT_AUTHZ).

4. Si alguna de las políticas de ALLOW coincide con la solicitud, esta se somete a la evaluación de CONTENT_AUTHZ.

5. Si existen políticas de ALLOW, pero no hay coincidencias, se rechaza la solicitud. No se evalúan las políticas de CONTENT_AUTHZ.

6. Si hay una política CONTENT_AUTHZ que coincide con la solicitud, se evalúa en último lugar. Si el proveedor personalizado rechaza la solicitud, esta se deniega.

Perfiles de políticas en políticas de autorización

Vista previa

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.

Los perfiles de políticas en las políticas de autorización se admiten para los siguientes servicios de Google Cloud :

• Balanceadores de cargas de aplicaciones regionales externos
• Balanceadores de cargas de aplicaciones internos regionales
• Agent Gateway
• Proxy web seguro

Un perfil de política (PolicyProfile) en una política de autorización es de los siguientes tipos:

• Perfil de autorización de la solicitud (REQUEST_AUTHZ): Se basa en la información de los encabezados de la solicitud HTTP para permitir o rechazar el tráfico.
• Perfil de autorización de contenido (CONTENT_AUTHZ): Proporciona seguridad y filtrado basados en el contenido para bloquear ataques de inyección de instrucciones, evitar filtraciones de datos sensibles y filtrar contenido dañino.

Puedes configurar una política de autorización con un perfil REQUEST_AUTHZ o un perfil CONTENT_AUTHZ, pero no con ambos. Si no se especifica un perfil de política, la política de autorización usa el perfil REQUEST_AUTHZ de forma predeterminada.

Perfil de solicitud de autorización

Las políticas de autorización que usan el perfil de política REQUEST_AUTHZ pueden evaluar las decisiones de acceso para el tráfico entrante de forma directa o delegarlas. Puedes delegar las decisiones de acceso a Identity-Aware Proxy o a un motor de autorización personalizado con una extensión de autorización. El perfil de política REQUEST_AUTHZ actúa sobre la información de los encabezados de solicitud HTTP para permitir o denegar una solicitud.

Una política de autorización con el perfil de política REQUEST_AUTHZ puede tener una acción ALLOW, DENY o CUSTOM aplicada a la solicitud. Una acción de ALLOW o DENY significa que la decisión de acceso se evalúa directamente, mientras que una acción de CUSTOM significa que la decisión de acceso se delega.

Cuando se delega la decisión de acceso, una política de autorización configurada en la regla de reenvío del balanceador de cargas apunta a una extensión de autorización de solicitudes que se ejecuta en un servicio de backend de devolución de llamada. Para cada solicitud de autorización, el balanceador de cargas reenvía los encabezados de la solicitud a la extensión de autorización con el protocolo ext_proc o ext_authz de Envoy. Según la respuesta de la extensión, el proxy del balanceador de cargas reenvía la solicitud a su servicio de backend o la rechaza.

Si no se especifica un perfil de política, la política de autorización usa el perfil de autorización de la solicitud (REQUEST_AUTHZ) de forma predeterminada.

Perfil de autorización de contenido

Las políticas de autorización que usan el perfil de política CONTENT_AUTHZ se pueden usar para realizar una inspección detallada de las cargas útiles de tu aplicación para permitir o denegar solicitudes, o bien mutar las solicitudes o respuestas, según sea necesario. Puedes delegar las decisiones de acceso a Model Armor o a tu propia extensión de saneamiento de contenido.

Una política de autorización con el perfil de política CONTENT_AUTHZ solo puede tener una acción CUSTOM aplicada a la solicitud. Esto significa que la solicitud no se puede evaluar directamente y debe delegarse.

Una política de autorización, configurada en la regla de reenvío del balanceador de cargas, apunta a una extensión de autorización de contenido. Para cada solicitud de autorización, el balanceador de cargas reenvía el contenido completo de la solicitud y la respuesta, incluidos los encabezados, el cuerpo y los tráileres, con el protocolo ext_proc de Envoy en modo de transmisión dúplex completa (FULL_DUPLEX_STREAMED) a la extensión de autorización de contenido. Según la respuesta de la extensión, el proxy del balanceador de cargas reenvía la solicitud a su destino o la rechaza. El destino, en el caso de una solicitud, es el servicio de backend del balanceador de cargas y, en el caso de una respuesta, es el cliente.

Delega decisiones de autorización

Las políticas de autorización se pueden evaluar directamente o se pueden delegar. En el caso de las decisiones de autorización complejas que no se pueden expresar con una política de autorización, puedes crear una política de autorización con una acción CUSTOM y delegar la decisión de autorización a un servicio administrado por Google o a un servicio administrado por el usuario a través de Service Extensions.

• Servicio administrado por Google
  • Model Armor
  • Identity-Aware Proxy
• Servicio administrado por el usuario
  • un Google Cloud servicio de backend
  • Un servicio accesible por un nombre de dominio completamente calificado (FQDN) que admite el protocolo ext_proc o ext_authz de Envoy

En la siguiente tabla, se resumen los diferentes servicios a los que se puede delegar una decisión de autorización a través de Service Extensions.

Política de autorización	Evaluación directa	Delegada a las extensiones del servicio (extensión de autorización)
		Servicios administrados por Google		Servicios administrados por el usuario
		Model Armor	Identity-Aware Proxy	Google Cloud servicio de backend	Servicio basado en FQDN
Perfil de REQUEST_AUTHZ
Perfil de CONTENT_AUTHZ

Extensiones del servicio

Puedes usar políticas de autorización para delegar decisiones de autorización a Service Extensions, específicamente del tipo extensión de autorización. Las extensiones de autorización admiten textos destacados para insertar lógica personalizada en los balanceadores de cargas de aplicaciones Google Cloud. Esta capacidad te permite escribir tu propio código para realizar diversas actividades en el tráfico procesado por un balanceador de cargas, como reescrituras de encabezado, seguridad incremental, registro personalizado y autenticación de usuarios personalizada.

Con los textos destacados de Service Extensions, le indicas al balanceador de cargas que reenvíe el tráfico desde la ruta de procesamiento de datos del balanceo de cargas con llamadas gRPC a un servicio de texto destacado, que puede ser administrado por el usuario o por Google. Los diferentes servicios de texto destacado se definen en la tabla anterior. Estos servicios de texto destacado ejecutan la extensión de autorización y pueden aplicar varias políticas o funciones antes de devolver el tráfico al balanceador de cargas para su procesamiento posterior. En el siguiente diagrama, se muestra este proceso.

Política de autorización que delega la decisión de autorización a través de una extensión de autorización (haz clic para ampliar).

Para delegar las decisiones de autorización a una extensión de autorización, crea una extensión de autorización (AuthzExtension) que se ejecute en un servicio de llamada. Luego, puedes crear una política de autorización con una acción CUSTOM y dirigirla a la extensión de autorización que creaste. La extensión de autorización se puede usar para realizar la autorización a nivel de la solicitud (REQUEST_AUTHZ) y la limpieza del contenido (CONTENT_AUTHZ).

Para obtener más información sobre cómo delegar la decisión de autorización a un servicio de backend administrado por el usuarioGoogle Cloud o a un servicio basado en FQDN, consulta Delega la decisión de autorización a un servicio administrado por el usuario.

Extensiones de autorización en la ruta de procesamiento de datos

Cuando delegues una decisión de autorización a las Service Extensions, específicamente del tipo extensión de autorización, ten en cuenta la siguiente terminología:

• Cuando una política de autorización personalizada con un perfil de política REQUEST_AUTHZ apunta a una extensión de autorización (AuthzExtension), la extensión de autorización se conoce como extensión de autorización de solicitud.

• Cuando una política de autorización con un perfil de política CONTENT_AUTHZ apunta a una extensión de autorización (AuthzExtension), se hace referencia a la extensión de autorización como una extensión de autorización de contenido.

En la ruta de procesamiento de solicitudes, primero se invoca una extensión de autorización de solicitudes, seguida de la evaluación de políticas de permitir y rechazar, luego la extensión de autorización de contenido y, finalmente, la extensión de tráfico. También se puede invocar una extensión de autorización de contenido en la ruta de procesamiento de respuestas. En el siguiente diagrama, se muestra la secuencia en la que se invocan las diferentes extensiones.

Nota: La extensión de autorización de solicitudes solo se invoca cuando llegan los encabezados de la solicitud. El cuerpo de la solicitud, junto con los encabezados y el cuerpo de la respuesta, no son visibles para la extensión de autorización de la solicitud.

Extensión de autorización de la solicitud invocada antes de una extensión de autorización de contenido (haz clic para ampliar).

Puedes pensar en las diferentes extensiones como hooks que se activan en ciertos puntos de la ruta de procesamiento de datos. Para obtener más información sobre las diferentes extensiones, consulta Puntos de extensibilidad en la ruta de datos del balanceo de cargas en la documentación de Service Extensions.

Model Armor

Puedes usar políticas de autorización para habilitar Model Armor y aplicar medidas de protección basadas en IA que eviten la generación de contenido dañino, la inyección de instrucciones y la filtración de datos.

Para ello, puedes crear una extensión de autorización (AuthzExtension) que se ejecute en un servicio de Model Armor. Luego, puedes crear una política de autorización con una acción CUSTOM y un perfil CONTENT_AUTHZ que apunte a la extensión de autorización que creaste.

Para obtener más información sobre cómo delegar la autorización a Model Armor, consulta Cómo delegar la decisión de autorización a Model Armor.

Identity-Aware Proxy

Puedes delegar las decisiones de autorización a Identity-Aware Proxy. IAP verifica la identidad del usuario y el contexto de la solicitud para determinar si se le debe permitir el acceso a una aplicación o un recurso.

En el caso de los balanceadores de cargas de aplicaciones externos globales y los balanceadores de cargas de aplicaciones internos entre regiones, no puedes delegar la decisión de autorización en IAP a través de una extensión de autorización.

Para los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones internos regionales, puedes configurar una política de autorización para delegar la decisión de autorización en IAP a través de una extensión de autorización.

Para obtener más información sobre el uso de IAP como servicio de autorización, consulta Delega la decisión de autorización a Identity-Aware Proxy.

Política de autorización basada en principales

Nota: La política de autorización basada en entidades no es compatible con los balanceadores de cargas de aplicaciones externos globales.

Para identificar la fuente de tráfico con un alto nivel de detalle, puedes configurar políticas de autorización basadas en identidades derivadas del certificado de un cliente. Este método requiere que se habilite la mTLS de frontend en el balanceador de cargas y usa los siguientes atributos de certificado como un selector principal para la identificación:

• SAN del URI del certificado de cliente (CLIENT_CERT_URI_SAN)
• SAN de nombres de DNS del certificado de cliente (CLIENT_CERT_DNS_NAME_SAN)
• Nombre común del certificado de cliente (CLIENT_CERT_COMMON_NAME)

Si no se especifica ningún selector de principal para la identificación, se usa CLIENT_CERT_URI_SAN como selector de principal predeterminado. Esto significa que los SAN del URI del certificado del cliente se evalúan cuando se toman decisiones de autorización.

Para que funcione la autorización basada en principales, se deben cumplir las siguientes condiciones:

• Se debe habilitar la mTLS del frontend. Si la mTLS de frontend no está habilitada, el cliente no presenta un certificado. Como resultado, ninguna regla basada en principales de la política de autorización encuentra información de certificados para evaluar. Por ejemplo, una regla que verifica CLIENT_CERT_URI_SAN ve un valor vacío.

• Debe haber un certificado de cliente válido. Incluso con mTLS habilitado, no se usa un certificado de cliente para la autorización si la conexión se estableció con un certificado faltante o no válido. Esta situación se produce cuando el modo de validación del cliente de mTLS se establece en el modo permisivo ALLOW_INVALID_OR_MISSING_CLIENT_CERT. En este caso, tampoco se encuentra información de certificados para evaluar las reglas basadas en principales de la política de autorización. Por ejemplo, una regla que verifica CLIENT_CERT_URI_SAN ve un valor vacío.

Impacto de los límites de tamaño de los atributos

Las decisiones de autorización son sensibles al tamaño de los atributos del certificado de cliente. Una solicitud se rechaza si un atributo supera su límite de tamaño y la política está configurada para validar ese atributo específico.

Se puede rechazar un cambio en las siguientes condiciones:

• La política valida con CLIENT_CERT_URI_SAN, y los SAN de URI del certificado superan el límite de tamaño.
• La política realiza la validación en función de CLIENT_CERT_DNS_NAME_SAN, y los SAN de nombre DNS del certificado superan el límite de tamaño.
• La política se valida en CLIENT_CERT_COMMON_NAME, y el asunto del certificado (que contiene el nombre común) supera el límite de tamaño.

Si el atributo de un certificado supera su límite de tamaño, pero no se valida de forma explícita con el selector principal de la política, la solicitud se sigue evaluando según las reglas principales configuradas. Por ejemplo, si una política está configurada para validar solo el CLIENT_CERT_DNS_NAME_SAN, no se rechazará una solicitud de un cliente con SAN de URI demasiado grandes por ese motivo. La política continúa evaluando la solicitud según los SAN de su nombre de DNS.

Para ver un ejemplo de una política de autorización basada en principales, consulta Política de autorización para rechazar solicitudes.

Política de autorización basada en cuentas de servicio o etiquetas seguras

Se admite una política de autorización basada en cuentas de servicio o etiquetas seguras para los siguientes balanceadores de cargas:

• Balanceadores de cargas de aplicaciones internos regionales
• Balanceadores de cargas de aplicaciones internos entre regiones

Nota: No se admite la aplicación de políticas de autorización basadas en cuentas de servicio o etiquetas para los balanceadores de cargas de aplicaciones externos.

Las políticas de autorización, basadas en cuentas de servicio y etiquetas seguras, te permiten aplicar reglas de seguridad según quién o qué envía el tráfico, en lugar de solo la dirección IP. Esto genera un cambio de las reglas basadas en IP a los controles basados en la identidad, ya que se usan cuentas de servicio y etiquetas seguras para definir tu perímetro de seguridad. Por ejemplo, puedes crear una política de autorización para hacer lo siguiente:

• Deniega el acceso a una VM de Compute Engine con una cuenta de servicio específica (my-sa-123@PROJECT_ID.iam.gserviceaccount.com) para que no llegue a la ruta de acceso /api/payments.

• permitir que las VMs de Compute Engine con una etiqueta segura (par clave-valor environment: prod) lleguen a la ruta de acceso /api/payments

Puedes aplicar políticas de autorización basadas en cuentas de servicio o etiquetas seguras adjuntas a varios Google Cloud servicios. Todo el tráfico que se origine en estos servicios de Google Cloud , que están vinculados a una cuenta de servicio específica o a una etiqueta segura, se puede permitir, rechazar o delegar para su posterior evaluación.

En la siguiente tabla, se enumeran los distintos Google Cloud servicios que admiten el uso de cuentas de servicio y etiquetas seguras.

Servicio deGoogle Cloud	Asistencia para cuentas de servicio	Compatibilidad con etiquetas seguras
Máquina virtual (VM) de Compute Engine
Nodo de Google Kubernetes Engine (GKE)
Contenedor de Google Kubernetes Engine (GKE)	^1	^1
VPC directa para Cloud Run		^1
Conector de Acceso a VPC sin servidores	^2	^2
Cloud VPN	^1	^1
Cloud Interconnect en las instalaciones	^1	^1
Balanceador de cargas de aplicaciones	^3	^3
Balanceador de cargas de red	^3	^3

¹ No es compatible con Google Cloud.

² La dirección IP de origen es única y se puede usar en su lugar.

³ Las cuentas de servicio y las etiquetas no son compatibles cuando los balanceadores de cargas de aplicaciones y los balanceadores de cargas de red actúan como fuentes de tráfico en una arquitectura en niveles.

En la siguiente tabla, se enumeran las diferentes arquitecturas de la nube privada virtual (VPC) que admiten el uso de cuentas de servicio y etiquetas.

VPC	Arquitectura de VPC	Asistencia
Dentro de la VPC	Entre proyectos (VPC compartida)
Dentro de la VPC	Entre regiones
Entre VPCs	Vínculo de intercambio de tráfico cruzado (VPC de intercambio de tráfico)
Entre VPCs	Private Service Connect cruzado
Entre VPCs	Radios de Cross Network Connectivity Center

Para obtener más información sobre cómo configurar una política de autorización basada en cuentas de servicio y etiquetas adjuntas a un recurso de Google Cloud , consulta Política de autorización basada en cuentas de servicio o etiquetas.

Cuotas

Para obtener información sobre las cuotas de las políticas de autorización, consulta Cuotas y límites de las políticas de autorización.

Precios

Para obtener información sobre los precios, consulta Precios de red: Cloud Load Balancing.

¿Qué sigue?

• Configura políticas de autorización para balanceadores de cargas de aplicaciones

• Configura una extensión de autorización