En esta página se describe cómo proteger tu aplicación con encabezados de IAP firmados. Cuando se configura, Identity-Aware Proxy (IAP) usa JSON Web Tokens (JWT) para garantizar que se autoricen las solicitudes a tu aplicación. Esto protege tu app de los siguientes riesgos:
- Inhabilitaciones accidentales de IAP
- Firewalls mal configurados
- Acceso no autorizado desde el proyecto
Para proteger tu app, debes usar encabezados firmados para todos los tipos de apps.
También puedes usar la API de Users si tienes una app del entorno estándar de App Engine.
Las verificaciones de estado de Compute Engine y GKE no incluyen encabezados JWT, y IAP no procesa las verificaciones de estado. Si tu verificación de estado muestra errores de acceso, asegúrate de que esté configurada correctamente en la consola de Google Cloud y de que la validación del encabezado JWT permita la ruta de verificación de estado. Para obtener más información, consulta cómo crear una excepción de verificación de estado.
Antes de comenzar
Para poder proteger tu aplicación con encabezados firmados, necesitarás los siguientes elementos:
- Una aplicación a la que quieras que se conecten los usuarios
- Una biblioteca de JWT de terceros para tu lenguaje que sea compatible con el algoritmo
ES256
Protege tu aplicación con encabezados de IAP
Para proteger tu aplicación con JWT de IAP, verifica el encabezado, la carga útil y la firma del JWT. El JWT se encuentra en el encabezado de la solicitud HTTP x-goog-iap-jwt-assertion. Si un atacante omite IAP, puede falsificar los encabezados de identidad sin firmar de IAP, x-goog-authenticated-user-{email,id}. JWT de IAP proporciona una alternativa más segura.
Los encabezados firmados proporcionan seguridad adicional en caso de que una persona omita IAP. Cuando IAP está habilitado, este quita los encabezados x-goog-* proporcionados por el cliente cuando la solicitud se procesa en su infraestructura de entrega.
Verifica el encabezado JWT
Comprueba que el encabezado JWT cumpla con las siguientes restricciones:
| Reclamaciones del encabezado JWT | ||
|---|---|---|
alg |
Algoritmo | ES256 |
kid |
ID de la clave | Debe corresponder a una de las claves públicas que aparecen en el archivo de claves de IAP, disponible en dos formatos diferentes: https://www.gstatic.com/iap/verify/public_key y https://www.gstatic.com/iap/verify/public_key-jwk |
Asegúrate de que el JWT esté firmado por la clave privada que corresponda a la reclamación kid del token. Primero, recupera la clave pública de uno de estos dos lugares:
https://www.gstatic.com/iap/verify/public_key: Esta URL contiene un diccionario JSON que asigna las reclamacioneskida los valores de clave públicahttps://www.gstatic.com/iap/verify/public_key-jwk: Esta URL contiene las claves públicas de IAP en formato JWK
Una vez que tengas la clave pública, utiliza una biblioteca de JWT para verificar la firma.
IAP rota sus claves públicas de forma periódica. Para asegurarte de que siempre puedas verificar los JWT, consulta Cómo automatizar el almacenamiento en caché de claves públicas.
Verifica la carga útil de JWT
Comprueba que la carga útil de JWT cumpla con las siguientes restricciones:
| Reclamaciones de la carga útil de JWT | ||
|---|---|---|
exp |
Hora de vencimiento | Debe ser en el futuro. El tiempo se mide en segundos transcurridos desde la época UNIX, con una tolerancia de 30 segundos debida al sesgo. El ciclo de vida máximo de un token es de 10 minutos + 2 × el sesgo |
iat |
Hora de emisión | Debe ser en el pasado. El tiempo se mide en segundos transcurridos desde la época UNIX, con una tolerancia de 30 segundos debida al sesgo |
aud |
Público | Debe ser una string con los siguientes valores:
|
iss |
Emisor | Debe ser https://cloud.google.com/iap |
hd |
Dominio de cuenta | Si una cuenta pertenece a un dominio alojado, se proporciona la reclamación hd para distinguir el dominio al cual se asocia la cuenta |
google |
Reclamación de Google |
Si uno o más niveles de acceso se aplican a la solicitud, sus nombres se almacenan en el objeto JSON de la reclamación google bajo la clave access_levels como un array de cadenas.
Cuando especificas una política de dispositivos y la organización tiene acceso a los datos del dispositivo, el |
Puedes obtener los valores de la cadena aud mencionada anteriormente si accedes a la consola deGoogle Cloud , o puedes usar la herramienta de línea de comandos de gcloud.
Para obtener los valores de cadena aud de la consola de Google Cloud , ve a la
configuración de Identity-Aware Proxy
de tu proyecto, haz clic en Más junto al recurso del balanceador de cargas y, luego,
selecciona Público de JWT del encabezado firmado. El cuadro de diálogo JWT del encabezado firmado que aparece muestra la reclamación aud del recurso seleccionado.
Si quieres usar la herramienta de línea de comandos de gcloud de la CLI de gcloud para obtener los valores de la cadena aud, deberás conocer el ID del proyecto. Puedes encontrar el ID del proyecto en la tarjeta Información del proyecto de la Google Cloud consola y, luego, ejecutar los comandos especificados para cada valor.
Número de proyecto
Para ver el número del proyecto con la herramienta de línea de comandos de gcloud, ejecuta el siguiente comando:
gcloud projects describe PROJECT_ID
El comando muestra resultados como el siguiente:
createTime: '2016-10-13T16:44:28.170Z' lifecycleState: ACTIVE name: project_name parent: id: '433637338589' type: organization projectId: PROJECT_ID projectNumber: 'PROJECT_NUMBER'
ID de servicio
Para ver el ID del servicio con la herramienta de línea de comandos de gcloud, ejecuta el siguiente comando:
gcloud compute backend-services describe SERVICE_NAME --project=PROJECT_ID --global
El comando muestra resultados como el siguiente:
affinityCookieTtlSec: 0 backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/project_name/regions/us-central1/instanceGroups/my-group connectionDraining: drainingTimeoutSec: 0 creationTimestamp: '2017-04-03T14:01:35.687-07:00' description: '' enableCDN: false fingerprint: zaOnO4k56Cw= healthChecks: - https://www.googleapis.com/compute/v1/projects/project_name/global/httpsHealthChecks/my-hc id: 'SERVICE_ID' kind: compute#backendService loadBalancingScheme: EXTERNAL name: my-service port: 8443 portName: https protocol: HTTPS selfLink: https://www.googleapis.com/compute/v1/projects/project_name/global/backendServices/my-service sessionAffinity: NONE timeoutSec: 3610
Recupera la identidad del usuario
Si todas las verificaciones anteriores se realizaron correctamente, recupera la identidad del usuario. La carga útil del token de ID contiene la siguiente información sobre el usuario:
| Identidad del usuario de la carga útil del token de ID | ||
|---|---|---|
sub |
Asunto |
El identificador estable y único del usuario; usa este valor en lugar del encabezado x-goog-authenticated-user-id
|
email |
Correo electrónico del usuario | Dirección de correo electrónico del usuario
|
A continuación, se muestra un ejemplo de código para proteger una app con encabezados de IAP firmados:
C#
Go
Java
Node.js
PHP
Python
Ruby
Prueba tu código de validación
Si visitas tu app con los parámetros de consulta secure_token_test, IAP incluirá un JWT no válido. Usa esto para asegurarte de que la lógica de validación de JWT controle todos los casos de falla y para ver cómo se comporta tu aplicación cuando recibe un JWT no válido.
Crea una excepción de verificación de estado
Como se mencionó anteriormente, las verificaciones de estado de Compute Engine y GKE no usan encabezados JWT. Además, IAP no controla las verificaciones de estado. Por tanto, deberás configurar la verificación de estado y la aplicación para que permitan el acceso de las verificaciones de estado.
Configura la verificación de estado
Si aún no estableciste una ruta para tu verificación de estado, usa la consola deGoogle Cloud para establecer una ruta no confidencial para la verificación de estado. Asegúrate de que esta ruta de acceso no se comparta con ningún otro recurso.
- Ve a la página Verificaciones de estado de la consola de Google Cloud .
Ir a la página Verificaciones de estado - Haz clic en la verificación de estado que estés usando para tu aplicación, y, a continuación, haz clic en Editar.
- En Solicitar ruta de acceso, agrega el nombre de una ruta no confidencial. Esto especifica la ruta de URL que usa Google Cloud cuando envía solicitudes de verificación de estado.
Si se omite este paso, la solicitud de verificación de estado se envía a
/. - Haz clic en Guardar.
Configura la validación de JWT
En el código que llama a la rutina de validación de JWT, agrega una condición que devuelve un estado HTTP 200 para la ruta de acceso de tu solicitud de verificación de estado. Por ejemplo:
if HttpRequest.path_info = '/HEALTH_CHECK_REQUEST_PATH' return HttpResponse(status=200) else VALIDATION_FUNCTION
Automatiza el almacenamiento en caché de claves públicas
IAP rota sus claves públicas de forma periódica. Para asegurarte de que siempre puedas verificar el JWT de IAP, te recomendamos que almacenes en caché las claves para evitar recuperarlas de la URL pública para cada solicitud y que automatices el proceso de actualización de la clave almacenada en caché. Este enfoque es particularmente útil para las aplicaciones que se ejecutan en un entorno con restricciones de red, como un perímetro de Controles del servicio de VPC.
Un perímetro de Controles del servicio de VPC puede impedir el acceso directo a la URL pública de las claves. Al almacenar en caché las claves en un bucket de Cloud Storage, tus aplicaciones pueden recuperarlas desde una ubicación dentro de tu perímetro de VPC-SC.
La siguiente configuración de Terraform implementa una función en Cloud Run que recupera las claves públicas más recientes de la IAP desde https://www.gstatic.com/iap/verify/public_key-jwk y las almacena en un bucket de Cloud Storage. Un trabajo de Cloud Scheduler activa esta función cada 12 horas para mantener las claves actualizadas.
En esta configuración, se incluye lo siguiente:
- APIs Google Cloud necesarias habilitadas para usar Cloud Run y almacenar y almacenar en caché claves
- Un bucket de Cloud Storage para almacenar las claves públicas de las IAP recuperadas
- Un bucket de Cloud Storage para organizar el código fuente de Cloud Run Functions
- Cuentas de servicio para Cloud Run Functions y Cloud Scheduler con los permisos de IAM adecuados
- Una función de Python para recuperar y almacenar claves
- Un trabajo de Cloud Scheduler para activar la función cada 12 horas
Estructura del directorio
├── function_source/ │ ├── main.py │ └── requirements.txt ├── main.tf ├── outputs.tf ├── variables.tf └── terraform.tfvars
function_source/main.py
import functions_framework import requests from google.cloud import storage import os # Environment variables to be set in the function configuration BUCKET_NAME = os.environ.get("BUCKET_NAME") OBJECT_NAME = os.environ.get("OBJECT_NAME", "iap_public_keys.jwk") IAP_KEYS_URL = "https://www.gstatic.com/iap/verify/public_key-jwk" @functions_framework.http def update_iap_keys(request): """Fetches IAP public keys from the public URL and stores them in a Cloud Storage bucket.""" if not BUCKET_NAME: print("Error: BUCKET_NAME environment variable not set.") return "BUCKET_NAME environment variable not set.", 500 try: # Fetch the keys response = requests.get(IAP_KEYS_URL) response.raise_for_status() # Raise an exception for bad status codes keys_content = response.text print(f"Successfully fetched keys from {IAP_KEYS_URL}") # Store in Cloud Storage storage_client = storage.Client() bucket = storage_client.bucket(BUCKET_NAME) blob = bucket.blob(OBJECT_NAME) blob.upload_from_string(keys_content, content_type='application/json') print(f"Successfully wrote IAP keys to gs://{BUCKET_NAME}/{OBJECT_NAME}") return f"Successfully updated {OBJECT_NAME} in bucket {BUCKET_NAME}", 200 except requests.exceptions.RequestException as e: print(f"Error fetching keys from {IAP_KEYS_URL}: {e}") return f"Error fetching keys: {e}", 500 except Exception as e: print(f"Error interacting with Cloud Storage: {e}") return f"Error interacting with Cloud Storage: {e}", 500
Reemplaza lo siguiente:
-
BUCKET_NAME: Es el nombre de tu bucket de Cloud Storage. -
OBJECT_NAME: El nombre del objeto en el que se almacenarán tus claves
function_source/requirements.txt
functions-framework==3.* requests google-cloud-storage
variables.tf
variable "project_id" { description = "The Google Cloud project ID." type = string default = PROJECT_ID } variable "region" { description = "The Google Cloud region." type = string default = "REGION" } variable "iap_keys_bucket_name" { description = "The name of the Cloud Storage bucket to store IAP keys." type = string default = BUCKET_NAME" } variable "function_source_bucket_name" { description = "The name of the Cloud Storage bucket to store the function source code." type = string default = "BUCKET_NAME_FUNCTION" }
Reemplaza lo siguiente:
-
PROJECT_ID: El ID de tu proyecto de Google Cloud -
REGION: Es la región en la que se implementarán los recursos, por ejemplo,us-central1. -
BUCKET_NAME: Es el nombre del bucket de Cloud Storage que almacena las claves de las IAP. -
BUCKET_NAME_FUNCTION: Es el nombre del bucket de Cloud Storage que almacena el código fuente de las funciones de Cloud Run.
main.tf
terraform { required_providers { google = { source = "hashicorp/google" version = ">= 4.50.0" } google-beta = { source = "hashicorp/google-beta" version = ">= 4.50.0" } } } provider "google" { project = var.project_id region = var.region } provider "google-beta" { project = var.project_id region = var.region } # Enable necessary APIs resource "google_project_service" "services" { for_each = toset([ "storage.googleapis.com", "cloudfunctions.googleapis.com", "run.googleapis.com", # Cloud Functions v2 uses Cloud Run "cloudscheduler.googleapis.com", "iamcredentials.googleapis.com", "cloudbuild.googleapis.com" # Needed for Cloud Functions deployment ]) service = each.key disable_on_destroy = false } # Cloud Storage Bucket to store the IAP public keys resource "google_storage_bucket" "iap_keys_bucket" { name = var.iap_keys_bucket_name location = var.region uniform_bucket_level_access = true versioning { enabled = true } lifecycle { prevent_destroy = false # Set to true in production to prevent accidental deletion } } # Cloud Storage Bucket to store the Cloud Function source code resource "google_storage_bucket" "function_source_bucket" { name = var.function_source_bucket_name location = var.region uniform_bucket_level_access = true } # Archive the function source code data "archive_file" "function_source_zip" { type = "zip" source_dir = "${path.module}/function_source" output_path = "${path.module}/function_source.zip" } # Upload the zipped source code to the source bucket resource "google_storage_bucket_object" "function_source_object" { name = "function_source.zip" bucket = google_storage_bucket.function_source_bucket.name source = data.archive_file.function_source_zip.output_path } # Service Account for the Cloud Function resource "google_service_account" "iap_key_updater_sa" { account_id = "iap-key-updater" display_name = "IAP Key Updater Function SA" } # Grant the function's SA permission to write to the IAP keys bucket resource "google_storage_bucket_iam_member" "keys_bucket_writer" { bucket = google_storage_bucket.iap_keys_bucket.name role = "roles/storage.objectAdmin" member = "serviceAccount:${google_service_account.iap_key_updater_sa.email}" } # Cloud Function (v2) resource "google_cloudfunctions2_function" "update_iap_keys_func" { provider = google-beta # CFv2 often has newer features in google-beta name = "update-iap-keys-function" location = var.region build_config { runtime = "python312" entry_point = "update_iap_keys" source { storage_source { bucket = google_storage_bucket.function_source_bucket.name object = google_storage_bucket_object.function_source_object.name } } } service_config { max_instance_count = 1 available_memory = "256M" timeout_seconds = 60 ingress_settings = "ALLOW_ALL" service_account_email = google_service_account.iap_key_updater_sa.email environment_variables = { BUCKET_NAME = google_storage_bucket.iap_keys_bucket.name OBJECT_NAME = "iap_public_keys.jwk" } } depends_on = [ google_project_service.services, google_storage_bucket_iam_member.keys_bucket_writer ] } # Service Account for the Cloud Scheduler job resource "google_service_account" "iap_key_scheduler_sa" { account_id = "iap-key-scheduler" display_name = "IAP Key Update Scheduler SA" } # Grant the Scheduler SA permission to invoke the Cloud Function resource "google_cloudfunctions2_function_iam_member" "invoker" { provider = google-beta project = google_cloudfunctions2_function.update_iap_keys_func.project location = google_cloudfunctions2_function.update_iap_keys_func.location cloud_function = google_cloudfunctions2_function.update_iap_keys_func.name role = "roles/cloudfunctions.invoker" member = "serviceAccount:${google_service_account.iap_key_scheduler_sa.email}" } # Cloud Scheduler Job resource "google_cloud_scheduler_job" "iap_key_update_schedule" { name = "iap-key-update-schedule" description = "Fetches IAP public keys and stores them in Cloud Storage every 12 hours" schedule = "0 */12 * * *" # Every 12 hours time_zone = "Etc/UTC" region = var.region http_target { uri = google_cloudfunctions2_function.update_iap_keys_func.service_config[0].uri http_method = "POST" oidc_token { service_account_email = google_service_account.iap_key_scheduler_sa.email } } depends_on = [ google_cloudfunctions2_function_iam_member.invoker, google_project_service.services ] }
outputs.tf
output "iap_keys_bucket_url" { description = "The Cloud Storage bucket URL where IAP public keys are stored." value = "gs://${google_storage_bucket.iap_keys_bucket.name}" } output "cloud_function_url" { description = "The URL of the Cloud Function endpoint that triggers key updates." value = google_cloudfunctions2_function.update_iap_keys_func.service_config[0].uri }
terraform.tfvars
Crea un archivo terraform.tfvars para especificar el ID de tu proyecto y personalizar los nombres de bucket si es necesario:
project_id = "your-gcp-project-id" # Optional: Customize bucket names # iap_keys_bucket_name = "custom-iap-keys-bucket" # function_source_bucket_name = "custom-func-src-bucket"
Lleve a cabo la implementación con Terraform
- Guarda los archivos en la estructura de directorios que se describió anteriormente.
- Navega al directorio en tu terminal y, luego, inicializa Terraform:
terraform init - Planifica los cambios:
terraform plan - Aplica los cambios:
terraform apply
Esto implementa la infraestructura. El trabajo de Cloud Scheduler activa la función cada 12 horas, recupera las claves de IAP y las almacena en gs://BUCKET_NAME/iap_public_keys.jwk de forma predeterminada. Tus aplicaciones ahora pueden recuperar las claves de este bucket.
Limpia los recursos
Para quitar los recursos creados por Terraform, ejecuta los siguientes comandos:
gsutil rm -a gs://BUCKET_NAME/** terraform destroy -auto-approve
Reemplaza BUCKET_NAME por el bucket de Cloud Storage para tus claves.
JWT para identidades externas
Si usas IAP con identidades externas, IAP emitirá un JWT firmado en cada solicitud autenticada, tal como lo hace con las identidades de Google. Sin embargo, existen algunas diferencias.
Información del proveedor
Cuando usas identidades externas, la carga útil de JWT contendrá una reclamación llamada gcip, Este reclamo contiene información del usuario, como su correo electrónico, la URL de su foto y cualquier atributo adicional específico del proveedor.
El siguiente es un ejemplo de un JWT para un usuario que accedió con Facebook:
"gcip": '{
"auth_time": 1553219869,
"email": "facebook_user@gmail.com",
"email_verified": false,
"firebase": {
"identities": {
"email": [
"facebook_user@gmail.com"
],
"facebook.com": [
"1234567890"
]
},
"sign_in_provider": "facebook.com",
},
"name": "Facebook User",
"picture: "https://graph.facebook.com/1234567890/picture",
"sub": "gZG0yELPypZElTmAT9I55prjHg63"
}',
Los campos email y sub
Si Identity Platform autenticó a un usuario, los campos email y sub del JWT tendrán como prefijo al emisor del token de Identity Platform y el ID de instancia utilizado (si existiera). Por ejemplo:
"email": "securetoken.google.com/PROJECT-ID/TENANT-ID:demo_user@gmail.com", "sub": "securetoken.google.com/PROJECT-ID/TENANT-ID:gZG0yELPypZElTmAT9I55prjHg63"
Controla el acceso con sign_in_attributes
IAM no admite identidades externas, pero puedes usar reclamaciones incorporadas en el campo sign_in_attributes para controlar el acceso. Por ejemplo, considera que un usuario accedió con un proveedor de SAML:
{
"aud": "/projects/project_number/apps/my_project_id",
"gcip": '{
"auth_time": 1553219869,
"email": "demo_user@gmail.com",
"email_verified": true,
"firebase": {
"identities": {
"email": [
"demo_user@gmail.com"
],
"saml.myProvider": [
"demo_user@gmail.com"
]
},
"sign_in_attributes": {
"firstname": "John",
"group": "test group",
"role": "admin",
"lastname": "Doe"
},
"sign_in_provider": "saml.myProvider",
"tenant": "my_tenant_id"
},
"sub": "gZG0yELPypZElTmAT9I55prjHg63"
}',
"email": "securetoken.google.com/my_project_id/my_tenant_id:demo_user@gmail.com",
"exp": 1553220470,
"iat": 1553219870,
"iss": "https://cloud.google.com/iap",
"sub": "securetoken.google.com/my_project_id/my_tenant_id:gZG0yELPypZElTmAT9I55prjHg63"
}
Podrías agregar a tu aplicación lógica similar al código que se encuentra a continuación para restringir el acceso a los usuarios con una función válida:
const gcipClaims = JSON.parse(decodedIapJwtClaims.gcip);
if (gcipClaims &&
gcipClaims.firebase &&
gcipClaims.firebase.sign_in_attributes &&
gcipClaims.firebase.sign_in_attribute.role === 'admin') {
// Allow access to admin restricted resource.
} else {
// Block access.
}
Puedes acceder a atributos de usuario adicionales desde los proveedores de OIDC y SAML de Identity Platform con la reclamación anidada gcipClaims.gcip.firebase.sign_in_attributes.
Limitaciones de tamaño de las reclamaciones del IdP
Después de que un usuario accede con Identity Platform, los atributos de usuario adicionales se propagarán a la carga útil del token de ID de Identity Platform sin estado, que se pasará de forma segura a IAP. Luego, IAP emitirá su propia cookie opaca sin estado, que también contiene los mismos reclamos. IAP generará el encabezado del JWT firmado según el contenido de la cookie.
Como resultado, si se inicia una sesión con muchos reclamos, es posible que se exceda el tamaño máximo permitido de la cookie, que suele ser de alrededor de 4 KB en la mayoría de los navegadores. Esto provocará que falle la operación de acceso.
Asegúrate de que solo se propaguen los reclamos necesarios en los atributos de OIDC o SAML del IdP. Otra opción es usar funciones de bloqueo para filtrar los reclamos que no se requieren para la verificación de autorización.
const gcipCloudFunctions = require('gcip-cloud-functions');
const authFunctions = new gcipCloudFunctions.Auth().functions();
// This function runs before any sign-in operation.
exports.beforeSignIn = authFunctions.beforeSignInHandler((user, context) => {
if (context.credential &&
context.credential.providerId === 'saml.my-provider') {
// Get the original claims.
const claims = context.credential.claims;
// Define this function to filter out the unnecessary claims.
claims.groups = keepNeededClaims(claims.groups);
// Return only the needed claims. The claims will be propagated to the token
// payload.
return {
sessionClaims: claims,
};
}
});