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

Una política de autorización (AuthzPolicy) aplicada a la regla de reenvío de los balanceadores de cargas de aplicaciones define reglas que especifican la fuente del tráfico entrante y las operaciones permitidas o restringidas para esa fuente. Además, la política de autorización describe las condiciones en las que se aplica una regla y especifica una acción para permitir, denegar o evaluar más el tráfico.

Las políticas de autorización te permiten establecer verificaciones de control de acceso para el tráfico entrante a los balanceadores de cargas de aplicaciones. Las solicitudes que pasan estas verificaciones se enrutan a los servicios de backend. Las solicitudes que no superen estas verificaciones finalizarán con una respuesta no autorizada.

Las políticas de autorización se pueden configurar 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

En los balanceadores de cargas de aplicaciones, se invocan las políticas de autorización después de evaluar las extensiones de ruta, las políticas de seguridad de red (que evalúa Google Cloud Armor), las políticas de uso compartido de recursos entre dominios (CORS) y las políticas de Identity-Aware Proxy (IAP), pero antes de ejecutar acciones de administración de tráfico.

Para obtener más información sobre cuándo se invocan las políticas de autorización en la ruta de procesamiento de solicitudes, consulta Puntos de extensibilidad en la ruta de datos de balanceo de cargas.

Si quieres usar políticas de autorización para los servicios implementados con Cloud Service Mesh, consulta Configura la seguridad del servicio con Envoy.

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.

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

Para 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 al 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 la política de autorización consta de los siguientes campos:

  • from: Especifica la identidad del cliente que permite la regla. La identidad se puede obtener de un certificado de cliente en una conexión de TLS mutua o puede ser la identidad ambiental asociada con la instancia de máquina virtual (VM) del cliente, como 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 las 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 ALLOW. Si existen políticas 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 esta coincide con alguna de las reglas especificadas en una política 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 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 Usa políticas de autorización para delegar decisiones de autorización.

    Si hay reglas HTTP configuradas para una política CUSTOM, la solicitud debe coincidir con las reglas HTTP para invocar al proveedor personalizado. Sin embargo, si no se definen reglas HTTP, la política de autorización siempre delega la decisión de autorización a un proveedor de autorización personalizado. Para obtener más información, consulta el siguiente ejemplo en el que no se definen reglas HTTP y la política de autorización delega la decisión de autorización a un IAP:

    Crea la política de autorización y habilita la IAP

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

Una política de autorización admite políticas CUSTOM, DENY y ALLOW para el control de acceso. Cuando se asocian varias políticas de autorización con 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 los proveedores de autorización personalizados y se rechaza si el proveedor la rechaza. No se evalúan las políticas DENY ni ALLOW, incluso si se configuran.

  2. Si hay alguna política DENY que coincida con la solicitud, esta se rechazará. No se evalúan las políticas 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, se permite la solicitud.

  5. Si existen políticas 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.

Usa políticas de autorización para delegar decisiones de autorización

En el caso de las decisiones de autorización complejas que no se pueden expresar con la política de autorización, delega la decisión de autorización a proveedores de autorización personalizados, como Identity-Aware Proxy (IAP), o crea tu propia extensión de autorización compilada con Extensiones de servicio. Esto es útil cuando quieres usar tu motor de autorización local o proveedores de identidad externos a través de IAP.

  • IAP: Configura IAP para controlar el acceso a las aplicaciones detrás de las reglas de reenvío del balanceador de cargas de aplicaciones. IAP verifica la identidad y el contexto del usuario para determinar el acceso. También puede autenticar tokens de cuenta de servicio de Identity and Access Management (IAM) y evaluar las políticas de IAM, lo que protege el acceso a los buckets de backend expuestos desde el balanceador de cargas de aplicaciones. Para obtener más información, consulta Delega la autorización a IAP y IAM.

    Puedes optar por delegar la autenticación a IAP y IAM en las siguientes situaciones:

    • Usar IAM para la administración de permisos.
    • Implementar el acceso adaptado al contexto.
    • Usar la autenticación basada en el navegador para las aplicaciones web que requieren autenticación interactiva.

  • Extensiones de servicio: Delega las decisiones de autorización a tu motor de autorización personalizado que se ejecuta en instancias de VM de Google Cloud Google Cloud o de forma local. Esto proporciona flexibilidad para las políticas de autorización complejas que no están cubiertas por las políticas integradas. Para obtener más información, consulta Cómo configurar una extensión de autorización.

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

Puedes usar atributos como cuentas de servicio o etiquetas para identificar la fuente de tráfico de los balanceadores de cargas de aplicaciones internos.

En el caso de los balanceadores de cargas de aplicaciones internos, puedes aplicar políticas de autorización según las cuentas de servicio o las etiquetas adjuntas a los recursos de Google Cloud . Se puede permitir, denegar o delegar a un servicio externo cualquier tráfico que provenga de estos recursos Google Cloud vinculados a una cuenta de servicio o etiqueta específicas.

En las siguientes tablas, se enumeran los recursos de origen y las diferentes arquitecturas de nube privada virtual (VPC) que admiten el uso de cuentas de servicio y etiquetas.

Origen Compatibilidad con cuentas de servicio Compatibilidad con etiquetas
VM
Nodo de GKE
Contenedor de GKE * *
VPC directa para Cloud Run *
Conector de Acceso a VPC sin servidores † †
Cloud VPN * *
Cloud Interconnect local * *
Balanceador de cargas de aplicaciones
Balanceador de cargas de red

* No es compatible con Google Cloud.

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

VPC Arquitectura de VPC Asistencia
Dentro de la VPC Entre proyectos (VPC compartida)
Dentro de la VPC Entre regiones
VPC cruzada Vínculo de intercambio de tráfico entre VPCs
VPC cruzada Private Service Connect cruzado
VPC cruzada Conexión entre radios de 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 VM 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

No se cobran políticas de autorización durante el período de la vista previa. Sin embargo, generas cargos por las herramientas de redes cuando usas Google Cloud balanceadores de cargas. Para obtener información sobre los precios, consulta Precios.

¿Qué sigue?