Identity-Aware Proxy (IAP) ti 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 Configurare gli acquisti 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 e implementare il connettore on-prem IAP in un progetto Google 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 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. Poi concede 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 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'app Google Cloud (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 che rappresenta 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 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 su 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 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 | |
finance | 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.