Identity-Aware Proxy (IAP) consente di gestire l'accesso alle app basate su HTTP al di fuori di Google Cloud. Sono incluse le app on-premise nei data center della tua azienda.
Per scoprire come proteggere le app on-premise con IAP, consulta Configurazione di IAP 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 IAP On-Prem in un progetto Google Cloud abilitato per IAP, inoltrando richieste autenticate e autorizzate alle app on-premise.
Il connettore on-prem crea le risorse seguenti:
- Un deployment di Traffic Director che funge da proxy per l'app on-premise.
- Un Application Load Balancer esterno che funge da controller in entrata per le richieste.
- Regole di routing.
Un deployment può avere più servizi di backend Traffic Director eseguiti con un bilanciatore del carico delle applicazioni esterno. Ogni servizio di backend è mappato a una singola app on-premise.
Quando viene eseguito il deployment del connettore on-prem IAP e IAP è abilitato 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 sul contesto e su identità. 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 progetto Google Cloud 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. Concede quindi all'utente l'accesso all'app Google Cloud.
Quando una richiesta viene inviata a un'app on-premise, IAP autentica e autorizza la richiesta dell'utente. Quindi instrada la richiesta al connettore on-prem IAP. Il connettore on-prem IAP inoltra la richiesta tramite un gruppo di endpoint di rete a 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'app Google Cloud (app1) e un'app on-premise (app2).
Regole di routing
Quando configuri il deployment di un connettore IAP, si configurano le regole di routing. Queste regole instradano le richieste web autenticate e autorizzate provenienti dal punto in entrata del nome host DNS verso il nome host DNS che è la 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 del servizio di backend Compute Engine, creata dall'Ambassador. - Il parametro
mapping
specifica un elenco di regole di routing dell'Ambassador per un servizio di backend. source
di una regola di routing è mappato adestination
, dovesource
è l'URL delle richieste in arrivo a Google Cloud edestination
è l'URL dell'app on-premise a cui IAP instrada il traffico dopo che un utente è stato autorizzato e autenticato.
La seguente tabella mostra le regole di esempio per instradare le richieste in entrata da www.hr-domain.com
a hr-internal.domain.com
:
Servizio di backend 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 | |
finance | host finanziario | 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.