Identity-Aware Proxy (IAP) ti consente di gestire l'accesso alle app basate su HTTP esterne aGoogle Cloud. Sono incluse le app on-premise nei data center della tua azienda.
Per scoprire come proteggere le app on-premise con gli acquisti in-app, consulta Configurare gli acquisti in-app per le app on-premise.
Introduzione
IAP ha come target le app on-premise con il connettore IAP on-prem. Il connettore on-prem utilizza un modello Cloud Deployment Manager per creare le risorse necessarie per ospitare ed eseguire il deployment del connettore on-prem IAP in un progettoGoogle Cloud abilitato per IAP, inoltrando le richieste autenticate e autorizzate alle app on-premise.
Il connettore on-prem crea le seguenti risorse:
- Un deployment di Cloud Service Mesh che funge da proxy per l'app on-premise.
- Un bilanciatore del carico delle applicazioni esterno che funge da controller Ingress per le richieste.
- Regole di routing.
Un deployment può avere più servizi di backend Cloud Service Mesh che vengono eseguiti dietro un bilanciatore del carico delle applicazioni esterno. Ogni servizio di backend viene mappato a una singola app on-premise.
Quando il connettore IAP on-prem viene disegnato e IAP è attivato per il servizio di backend del connettore on-prem appena creato, IAP protegge la tua app con criteri di accesso IAM (Identity and Access Management) basati su identità e contesto. Poiché un criterio di accesso IAM è configurato a livello di risorsa del servizio di backend, puoi avere elenchi di controllo dell'accesso diversi per ciascuna delle tue app on-premise. Ciò significa che è necessario un solo Google Cloud progetto per gestire l'accesso a più app on-premise.
Come funziona IAP per le app on-premise
Quando viene inviata una richiesta a un'app ospitata su Google Cloud, IAP autentica e autorizza le richieste degli utenti. Poi concede all'utente l'accesso all' Google Cloud app.
Quando una richiesta viene inviata a un'app on-premise, IAP autentica e autorizza la richiesta dell'utente. Quindi inoltra la richiesta al connettore on-prem IAP. Il connettore IAP on-prem forwarda la richiesta tramite un gruppo di endpoint di rete con connettività ibrida da Google Cloud alla rete on-premise.
Il seguente diagramma mostra il flusso di traffico di alto livello di una richiesta web per un'Google Cloud app (app1) e un'app on-premise (app2).
Regole di routing
Quando configuri il deployment di un connettore IAP, configuri le regole di routing. Queste regole indirizzano le richieste web autenticate e autorizzate che arrivano al punto di ingresso del nome host DNS al nome host DNS di destinazione.
Di seguito è riportato un esempio di parametri routing
definiti per un modello di Deployment Manager del connettore IAP.
routing: - name: hr mapping: - name: host source: www.hr-domain.com destination: hr-internal.domain.com - name: sub source: sheets.hr-domain.com destination: sheets.hr-internal.domain.com - name: finance mapping: - name: host source: www.finance-domain.com destination: finance-internal.domain.com
- Ogni nome
routing
corrisponde a una nuova risorsa di servizio di backend Compute Engine creata dall'ambassador. - Il parametro
mapping
specifica un elenco di regole di routing di Ambassador per un servizio di backend. - Il
source
di una regola di routing è mappato a undestination
, dovesource
è l'URL delle richieste in arrivo aGoogle Cloudedestination
è l'URL dell'app on-premise a cui l'IAP instrada il traffico dopo che un utente è stato autorizzato e autenticato.
La seguente tabella mostra esempi di regole per instradare le richieste in arrivo da
www.hr-domain.com
a hr-internal.domain.com
:
Servizio di backend di Compute Engine | Nome regola di routing | Origine | Destinazione |
---|---|---|---|
h | hr-host | www.hr-domain.com | hr-internal.domain.com |
hr-sub | sheets.hr-domain.com | sheets.hr-internal.domain.com | |
finanza | finance-host | www.finance-domain.com | finance-internal.domain.com |
Passaggi successivi
- Scopri come proteggere le app on-premise con IAP.
- Scopri di più su come funziona IAP.