Una política de autorización (AuthzPolicy) aplicada en 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 invoca a 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 del 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.
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 deALLOW. Si existen políticas deALLOW, 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ónALLOWcoincide con la solicitud. En Cloud Logging, esta acción se registra comodenied_as_no_allow_policies_matched_request.Para que se aplique una acción de
ALLOW, necesitas al menos una regla HTTP.DENY: Rechaza la solicitud si coincide con alguna de las reglas especificadas en una política deDENY. Si existen políticas deDENY, 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ónDENYcoincide con la solicitud. En Cloud Logging, esta acción se registra comoallowed_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 Usa políticas de autorización para 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 el siguiente ejemplo en el que no se definen reglas de HTTP y la política de autorización delega la decisión de autorización a un IAP:
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:
Si hay una política
CUSTOMque coincide con la solicitud, la políticaCUSTOMse evalúa con los proveedores de autorización personalizados y se rechaza si el proveedor la rechaza. No se evalúan las políticasDENYniALLOW, incluso si se configuró alguna.Si hay alguna política de
DENYque coincida con la solicitud, esta se rechazará. No se evalúa ninguna política deALLOW, incluso si están configuradas.Si no existen políticas de
ALLOW, se permite la solicitud.Si alguna de las políticas
ALLOWcoincide con la solicitud, permítela.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 lasAuthzPoliciesconfiguradas con la acciónALLOWcoincide 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 deseas 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 del usuario y el contexto 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 en 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 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 principales
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 de 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 la autorización basada en principales funcione, 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_SANve 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 verificaCLIENT_CERT_URI_SANve 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 con
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.
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 del 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 basadas en cuentas de servicio o etiquetas adjuntas a los recursos de Google Cloud . Todo el tráfico que se origine en estos recursos de Google Cloud vinculados a una cuenta de servicio o etiqueta específica se puede permitir, rechazar o delegar a un servicio externo.
En las siguientes tablas, se enumeran los recursos de origen y las diferentes arquitecturas de la 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 en las instalaciones | * | * |
| 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 cruzado (VPC de intercambio de tráfico) | |
| VPC cruzada | Private Service Connect cruzado | |
| VPC cruzada | 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 conectadas a un recurso de VM 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
No se cobran las políticas de autorización durante el período de la versión preliminar. 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.