Una política de autorización (AuthzPolicy) aplicada a la regla de reenvío de los balanceadores de carga 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 a fondo el tráfico.
Las políticas de autorización te permiten establecer comprobaciones de control de acceso para el tráfico entrante a los balanceadores de carga de aplicaciones. Las solicitudes que superan estas comprobaciones se dirigen a los servicios de backend. Las solicitudes que no superen estas comprobaciones se cancelará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 carga de aplicaciones con un esquema de balanceo de carga EXTERNAL_MANAGED o INTERNAL_MANAGED.
Los siguientes balanceadores de carga de aplicaciones admiten políticas de autorización:
- Balanceadores de carga de aplicación externos globales
Balanceadores de carga de aplicación externos regionales
Balanceadores de carga de aplicación internos regionales
- Balanceadores de carga de aplicación internos entre regiones
En los balanceadores de carga de aplicaciones, las políticas de autorización se invocan después de evaluar las extensiones de ruta, las políticas de seguridad de red (evaluadas por Google Cloud Armor), las políticas de intercambio de recursos entre orígenes (CORS) y las políticas de Identity-Aware Proxy (IAP), pero antes de ejecutar las acciones de gestión del 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 carga.
Si quieres usar políticas de autorización para los servicios implementados con Cloud Service Mesh, consulta Configurar la seguridad de los servicios con Envoy.
Reglas de las políticas de autorización
Una política de autorización consta de una lista de reglas HTTP que se comparan 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 carga. Debe incluir 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.
Se produce una coincidencia de política 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 una política de autorización consta de los siguientes campos:
from: especifica la identidad del cliente al que permite la regla. La identidad se puede derivar de un certificado de cliente en una conexión TLS mutua o puede ser la identidad del entorno asociada a 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 las restricciones adicionales que se deben cumplir. Puedes usar expresiones del lenguaje de expresión común (CEL) para definir las restricciones.
Acciones de las políticas de autorización
Al evaluar una solicitud, una política de autorización especifica la acción (AuthzAction) que se debe 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 se envíe al backend si coincide con alguna de las reglas especificadas en una políticaALLOW. Si existen políticas deALLOW, pero no hay ninguna coincidencia, se deniega la solicitud. Es decir, la solicitud se deniega 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
ALLOW, necesitas al menos una regla HTTP.DENY: deniega la solicitud si coincide con alguna de las reglas especificadas en una políticaDENY. Si existen políticas deDENY, pero no hay ninguna coincidencia, se permite la solicitud. Es decir, 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
DENY, necesitas al menos una regla HTTP.CUSTOM: delega la decisión de autorización en un proveedor de autorización personalizado, como IAP o extensiones de servicio. Para obtener más información, consulta Usar 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 en 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 en un IAP:
Orden de evaluación de las políticas 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 a un solo recurso, primero se evalúa la política CUSTOM, luego la DENY y, por último, la ALLOW. La evaluación se determina mediante las siguientes reglas:
Si hay una política
CUSTOMque coincida con la solicitud, se evaluará la políticaCUSTOMcon los proveedores de autorización personalizados y se denegará la solicitud si el proveedor la rechaza. No se evalúan las políticasDENYniALLOW, aunque se hayan configurado.Si hay alguna política
DENYque coincida con la solicitud, esta se deniega. No se evalúan las políticasALLOW, aunque estén configuradas.Si no hay ninguna política
ALLOW, se permite la solicitud.Si alguna de las políticas de
ALLOWcoincide con la solicitud, permítela.Si existen políticas de
ALLOW, pero no hay ninguna coincidencia, la solicitud se deniega. En otras palabras, la solicitud se deniega de forma predeterminada si ninguna de lasAuthzPoliciesconfiguradas con la acciónALLOWcoincide con la solicitud.
Usar políticas de autorización para delegar decisiones de autorización
Para tomar decisiones de autorización complejas que no se puedan expresar mediante la política de autorización, delega la decisión de autorización en proveedores de autorización personalizados, como Identity-Aware Proxy (IAP), o crea tu propia extensión de autorización con Extensiones de servicio. Esto resulta útil cuando quieres usar tu motor de autorización local o proveedores de identidades de terceros a través de IAP.
IAP: configura IAP para controlar el acceso a las aplicaciones que se encuentran detrás de las reglas de reenvío de Application Load Balancer. IAP verifica la identidad y el contexto de los usuarios para determinar el acceso. También puede autenticar tokens de cuentas de servicio de Gestión de Identidades y Accesos (IAM) y evaluar políticas de IAM, lo que protege el acceso a los segmentos de backend expuestos desde el balanceador de carga de aplicaciones. Para obtener más información, consulta Delegar la autorización en IAP y en IAM.
Puedes delegar la autenticación en IAP y IAM en los siguientes casos:
- Usa IAM para gestionar los permisos.
- Implementa el acceso contextual.
- Usa la autenticación basada en navegador para las aplicaciones web que requieran autenticación interactiva.
Extensiones de servicio: delega las decisiones de autorización en tu motor de autorización personalizado que se ejecuta en instancias de Google Cloud máquina virtual o en un entorno local. Esto ofrece 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 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 granularidad, puedes configurar políticas de autorización basadas en identidades derivadas del certificado de un cliente. Este método requiere que la autenticación mutua de TLS (mTLS) del frontend esté habilitada en el balanceador de carga y usa los siguientes atributos de certificado como selector principal para la identificación:
- SANs de URI de certificado de cliente (
CLIENT_CERT_URI_SAN) - SANs de nombre DNS de 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 SANs del URI del certificado de cliente se evalúan al tomar decisiones de autorización.
Para que funcione la autorización basada en principales, se deben cumplir las siguientes condiciones:
mTLS de frontend debe estar habilitado. Si mTLS de frontend no está habilitado, el cliente no presenta ningún certificado. Por lo tanto, las reglas basadas en principales de la política de autorización no encuentran información de certificado que evaluar. Por ejemplo, una regla que comprueba
CLIENT_CERT_URI_SANve un valor vacío.Debe haber un certificado de cliente válido. Aunque mTLS esté habilitado, no se usará ningún certificado de cliente para la autorización si la conexión se ha establecido con un certificado que falta o no es válido. Este caso se da cuando el modo de validación del cliente mTLS es el permisivo
ALLOW_INVALID_OR_MISSING_CLIENT_CERT. En este caso, tampoco se encuentra información de certificado para evaluar las reglas basadas en principales de la política de autorización. Por ejemplo, una regla que compruebaCLIENT_CERT_URI_SANve un valor vacío.
Impacto de los límites de tamaño de los atributos
Las decisiones de autorización dependen del 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 contenido en las siguientes condiciones:
- La política se valida con
CLIENT_CERT_URI_SANy los SANs del URI del certificado superan el límite de tamaño. - La política se valida con
CLIENT_CERT_DNS_NAME_SANy los SANs de nombre de DNS del certificado superan el límite de tamaño. - La política se valida con
CLIENT_CERT_COMMON_NAMEy 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 explícitamente mediante el selector principal de la política, la solicitud se sigue evaluando en función de las reglas principales configuradas. Por ejemplo, si una política se configura para validar solo el CLIENT_CERT_DNS_NAME_SAN, no se rechazará una solicitud de un cliente con SANs de URI de tamaño excesivo por ese motivo. La política evalúa la solicitud en función de los SANs del nombre de DNS.
Política de autorización basada en cuentas de servicio o etiquetas
Puede usar atributos como cuentas de servicio o etiquetas para identificar la fuente del tráfico de los balanceadores de carga de aplicaciones internos.
En el caso de los balanceadores de carga de aplicaciones internos, puedes aplicar políticas de autorización basadas en cuentas de servicio o etiquetas asociadas a recursos. Google Cloud El tráfico procedente de estos recursos de Google Cloud vinculados a una cuenta de servicio o una etiqueta específicas se puede permitir, denegar o delegar en un servicio externo.
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 servidor | † | † |
| Cloud VPN | * | * |
| Cloud Interconnect en las instalaciones | * | * |
| Balanceador de carga de aplicación | ||
| Balanceador de carga 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 |
|---|---|---|
| En la VPC | Entre proyectos (VPC compartida) | |
| En la VPC | Entre regiones | |
| Entre VPCs | Enlace de emparejamiento cruzado (VPC emparejada) | |
| Entre VPCs | Private Service Connect entre organizaciones | |
| Entre VPCs | Radios de Network Connectivity Center entre redes |
Para obtener más información sobre cómo configurar una política de autorización basada en cuentas de servicio y etiquetas asociadas a un recurso de máquina virtual, consulta Política de autorización basada en cuentas de servicio o etiquetas. Google Cloud
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
Las políticas de autorización no se cobran durante el periodo de vista previa. Sin embargo, se te aplican cargos por la red cuando usas Google Cloud balanceadores de carga. Para obtener información sobre los precios, consulta la página Precios.