Nesta página, você aprenderá como proteger seu app com cabeçalhos assinados pelo IAP. Quando configurado, o Identity-Aware Proxy (IAP) usa JSON Web Tokens (JWT) para garantir que qualquer solicitação direcionada ao app seja autorizada. Isso protege o app dos seguintes riscos:
- IAP acidentalmente desativado
- Firewalls mal configurados
- Acesso não autorizado de dentro do projeto
Para ajudar a proteger seu app, você precisa usar cabeçalhos assinados para todos os tipos de apps.
Como alternativa, se você tiver um aplicativo no ambiente padrão do App Engine, use a API Users.
As verificações de integridade do Compute Engine e do GKE não incluem cabeçalhos JWT, e o IAP não processa verificações de integridade. Se a verificação de integridade retornar erros de acesso, confira se ela está configurada corretamente no console do Google Cloud e se a validação do cabeçalho JWT permite o caminho da verificação de integridade. Para mais informações, consulte Criar uma exceção de verificação de integridade.
Antes de começar
Para proteger o aplicativo com cabeçalhos assinados, você precisará do seguinte:
- Um aplicativo para que os usuários se conectem
- Uma biblioteca de JWT de terceiros para sua linguagem (em inglês) que seja compatível com o algoritmo
ES256
Como proteger seu app com cabeçalhos do IAP
Para proteger seu app com o JWT do IAP, verifique o cabeçalho, o payload e a assinatura do JWT. O JWT está no cabeçalho de solicitação HTTP x-goog-iap-jwt-assertion. Se um invasor burlar o IAP, ele poderá forjar os cabeçalhos de identidade x-goog-authenticated-user-{email,id} não assinados pelo IAP. O JWT do IAP é uma alternativa mais segura.
Os cabeçalhos assinados proporcionam uma camada secundária de segurança caso alguém desvie do IAP. Quando o IAP está ativado, ele
remove os cabeçalhos x-goog-* fornecidos pelo cliente quando a solicitação passa
pela infraestrutura de disponibilização do IAP.
Como verificar o cabeçalho do JWT
Verifique se o cabeçalho do JWT está em conformidade com as seguintes restrições:
| Declarações do cabeçalho JWT | ||
|---|---|---|
alg |
Algoritmo | ES256 |
kid |
ID da chave | Precisa corresponder a uma das chaves públicas listadas no arquivo de chave do IAP, disponível em dois formatos diferentes: https://www.gstatic.com/iap/verify/public_key e https://www.gstatic.com/iap/verify/public_key-jwk. |
Verifique se o JWT foi assinado pela chave privada que corresponde à declaração kid do token. Primeiro, recupere a chave pública de um destes dois locais:
https://www.gstatic.com/iap/verify/public_key: este URL contém um dicionário JSON que mapeia as declaraçõeskidpara os valores de chave pública.https://www.gstatic.com/iap/verify/public_key-jwk: este URL contém as chaves públicas do IAP no formato JWK (em inglês).
Depois de conseguir a chave pública, use uma biblioteca de JWT para verificar a assinatura.
O IAP alterna periodicamente as chaves públicas. Para garantir que você sempre possa verificar os JWTs, consulte Automatizar o armazenamento em cache de chaves públicas.
Como verificar o payload do JWT
Verifique se o payload do JWT está em conformidade com as seguintes restrições:
| Declarações de payload do JWT | ||
|---|---|---|
exp |
Tempo de expiração | Precisa estar no futuro. O tempo é medido em segundos desde a era UNIX. Defina 30 segundos para a defasagem. A vida útil máxima de um token é de 10 minutos + 2 * distorção. |
iat |
Hora de emissão | Precisa estar no passado. O tempo é medido em segundos desde a era UNIX. Defina 30 segundos para a defasagem. |
aud |
Público-alvo | Precisa ser uma string com os seguintes valores:
|
iss |
Emissor | Precisa ser https://cloud.google.com/iap. |
hd |
Domínio da conta | Se uma conta pertencer a um domínio hospedado, a declaração hd será fornecida para diferenciar o domínio a que a conta está associada. |
google |
Declaração do Google |
Se um ou mais níveis de acesso se aplicarem à solicitação, os nomes deles serão armazenados no objeto JSON da declaração google, na chave access_levels, como uma matriz de strings.
Quando você especifica uma política de dispositivo e a organização tem acesso aos dados do dispositivo, o |
Para conseguir os valores da string aud mencionada acima, acesse o consoleGoogle Cloud ou use a ferramenta de linha de comando gcloud.
Para conseguir os valores da string aud no console do Google Cloud , acesse as
configurações do Identity-Aware Proxy
do seu projeto, clique em Mais ao lado do recurso de balanceador de carga e selecione
Público-alvo do JWT com cabeçalho assinado. A caixa de diálogo JWT com cabeçalho assinado exibida mostra a declaração aud do recurso selecionado.
Se você quiser usar a ferramenta de linha de comando gcloud na CLI gcloud para conseguir os valores da string aud, precisará saber o ID do projeto. No card Informações do projeto do Google Cloud console, encontre esse ID do projeto e execute os comandos especificados para cada valor.
Número do projeto
Para conseguir o número do projeto usando a ferramenta de linha de comando gcloud, execute o seguinte comando:
gcloud projects describe PROJECT_ID
O comando retorna uma saída semelhante a esta:
createTime: '2016-10-13T16:44:28.170Z' lifecycleState: ACTIVE name: project_name parent: id: '433637338589' type: organization projectId: PROJECT_ID projectNumber: 'PROJECT_NUMBER'
ID do serviço
Para conseguir o código do serviço usando a ferramenta de linha de comando gcloud, execute o seguinte comando:
gcloud compute backend-services describe SERVICE_NAME --project=PROJECT_ID --global
O comando retorna uma saída semelhante a esta:
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
Como recuperar a identidade do usuário
Se todas as verificações anteriores forem bem-sucedidas, recupere a identidade do usuário. O payload do token de código contém as seguintes informações de usuário:
| Identidade do usuário de payload do token de código | ||
|---|---|---|
sub |
Assunto |
O identificador exclusivo e estável do usuário. Use esse valor em vez do cabeçalho x-goog-authenticated-user-id.
|
email |
E-mail do usuário | O endereço de e-mail do usuário.
|
Confira um exemplo de código para proteger um app com cabeçalhos assinados pelo IAP:
C#
Go
Java
Node.js
PHP
Python
Ruby
Como testar seu código de validação
Se você visitar seu app usando os
parâmetros de consulta secure_token_test,
o IAP incluirá um JWT inválido. Use-o para garantir que a lógica de validação do JWT processe todos os diversos casos de falha e para ver como seu app se comporta ao receber um JWT inválido.
Como criar uma exceção de verificação de integridade
Como mencionado anteriormente, as verificações de integridade do Compute Engine e do GKE não usam cabeçalhos JWT. Além disso, o IAP não processa verificações de integridade. Você precisará configurar a verificação de integridade, bem como o app para permitir o acesso nessa situação.
Como configurar a verificação de integridade
Se você ainda não definiu um caminho para a verificação de integridade, use o consoleGoogle Cloud para especificar um caminho não sensível para ela. Esse caminho não pode ser compartilhado com nenhum outro recurso.
- Acesse a página Verificações de integridade no Google Cloud console.
Acessar a página "Verificações de integridade" - Clique na verificação de integridade que você está usando no app e depois clique em Editar.
- Em Caminho da solicitação, insira um nome de caminho não confidencial. Isso especifica o caminho do URL que Google Cloud usa ao enviar solicitações de verificação de integridade.
Se omitido, a solicitação de verificação de integridade será enviada para
/. - Clique em Salvar.
Como configurar a validação do JWT
No código que chama a rotina de validação do JWT, inclua uma condição para exibir um status HTTP 200 ao caminho de solicitação da verificação de integridade. Exemplo:
if HttpRequest.path_info = '/HEALTH_CHECK_REQUEST_PATH' return HttpResponse(status=200) else VALIDATION_FUNCTION
Automatizar o cache de chaves públicas
O IAP alterna as chaves públicas periodicamente. Para garantir que você sempre possa verificar o JWT de IAP, recomendamos que você armazene em cache as chaves para evitar buscá-las no URL público em cada solicitação e que automatize o processo de atualização da chave armazenada em cache. Essa abordagem é especialmente útil para aplicativos executados em um ambiente com restrições de rede, como um perímetro do VPC Service Controls.
Um perímetro do VPC Service Controls pode impedir o acesso direto ao URL público das chaves. Ao armazenar as chaves em cache em um bucket do Cloud Storage, seus aplicativos podem buscá-las em um local dentro do perímetro da VPC-SC.
A configuração do Terraform a seguir implanta uma função no Cloud Run que busca as chaves públicas mais recentes da IAP em https://www.gstatic.com/iap/verify/public_key-jwk e as armazena em um bucket do Cloud Storage. Um job do Cloud Scheduler aciona essa função a cada 12 horas para manter as chaves atualizadas.
Essa configuração inclui o seguinte:
- APIs necessárias Google Cloud ativadas para usar o Cloud Run e armazenar e chaves de cache.
- Um bucket do Cloud Storage para armazenar as chaves públicas da IAP buscadas
- Um bucket do Cloud Storage para armazenar o código-fonte das funções do Cloud Run
- Contas de serviço para funções do Cloud Run e Cloud Scheduler com as permissões adequadas do IAM
- Uma função Python para buscar e armazenar chaves
- Um job do Cloud Scheduler para acionar a função a cada 12 horas
Estrutura do diretório
├── 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
Substitua:
-
BUCKET_NAME: o nome do bucket do Cloud Storage -
OBJECT_NAME: o nome do objeto para armazenar suas chaves
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" }
Substitua:
-
PROJECT_ID: o ID do projeto do Google Cloud -
REGION: a região em que os recursos serão implantados, por exemplo,us-central1 -
BUCKET_NAME: o nome do bucket do Cloud Storage que armazena chaves de IAP -
BUCKET_NAME_FUNCTION: o nome do bucket do Cloud Storage que armazena o código-fonte das funções do 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
Crie um arquivo terraform.tfvars para especificar o ID do projeto e personalizar os nomes dos buckets, se necessário:
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"
Faça a implantação com o Terraform
- Salve os arquivos na estrutura de diretórios descrita anteriormente.
- Navegue até o diretório no terminal e inicialize o Terraform:
terraform init - Planeje as mudanças:
terraform plan - Aplique as alterações:
terraform apply
Isso implanta a infraestrutura. O job do Cloud Scheduler aciona a função a cada 12 horas, buscando as chaves da IAP e armazenando-as em gs://BUCKET_NAME/iap_public_keys.jwk por padrão. Seus aplicativos agora podem buscar as chaves desse bucket.
Limpar recursos
Para remover os recursos criados pelo Terraform, execute os seguintes comandos:
gsutil rm -a gs://BUCKET_NAME/** terraform destroy -auto-approve
Substitua BUCKET_NAME pelo bucket do Cloud Storage das suas chaves.
JWTs para identidades externas
Se você estiver usando o IAP com identidades externas, ele ainda emitirá um JWT assinado em todas as solicitações autenticadas, assim como faz com as identidades do Google. No entanto, existem algumas diferenças.
Informações do provedor
Ao usar identidades externas, o payload do JWT incluirá uma declaração chamada gcip. Essa declaração contém informações do usuário, como e-mail, URL da foto e outros atributos específicos do provedor.
Veja abaixo um exemplo de um JWT de um usuário que fez login com o 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"
}',
Campos email e sub
Se um usuário foi autenticado pelo Identity Platform, os campos email e sub do JWT terão como prefixo o emissor do token do Identity Platform e o ID do locatário usado (se houver). Por exemplo:
"email": "securetoken.google.com/PROJECT-ID/TENANT-ID:demo_user@gmail.com", "sub": "securetoken.google.com/PROJECT-ID/TENANT-ID:gZG0yELPypZElTmAT9I55prjHg63"
Como controlar o acesso com sign_in_attributes
O IAM não é compatível com identidades externas, mas é possível usar declarações incorporadas no campo sign_in_attributes para controlar o acesso. Por exemplo, imagine que um usuário fez login usando um provedor 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"
}
É possível adicionar lógica ao aplicativo de maneira semelhante ao código abaixo para restringir o acesso a usuários com um papel válido:
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.
}
Para acessar outros atributos de usuário dos provedores SAML e OIDC do Identity Platform, use a declaração aninhada gcipClaims.gcip.firebase.sign_in_attributes.
Limitações de tamanho das declarações do IdP
Depois que um usuário faz login com o Identity Platform, os atributos adicionais são propagados para o payload do token de ID sem estado do Identity Platform, que é transmitido com segurança para o IAP. Em seguida, o IAP vai emitir um cookie opaco sem estado próprio, que também contém as mesmas declarações. O IAP vai gerar o cabeçalho JWT assinado com base no conteúdo do cookie.
Como resultado, se uma sessão for iniciada com muitas declarações, ela poderá exceder o tamanho máximo permitido do cookie, que geralmente é de cerca de 4 KB na maioria dos navegadores. Isso vai causar uma falha na operação de login.
Verifique se apenas as declarações necessárias são propagadas nos atributos SAML ou OIDC do IdP. Outra opção é usar funções de bloqueio para filtrar as declarações que não são necessárias para a verificação de autorização.
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,
};
}
});