Questa pagina spiega come proteggere un'istanza di Google Kubernetes Engine (GKE) con Identity-Aware Proxy (IAP).
Panoramica
IAP è integrato tramite Ingress per GKE. Questa integrazione ti consente di controllare l'accesso a livello di risorsa per i dipendenti anziché utilizzare una VPN.
In un cluster GKE, il traffico in entrata è gestito da HTTP(S) Load Balancing, un componente di Cloud Load Balancing. Il bilanciatore del carico HTTP(S) è in genere configurato dal controller Ingress Ingress. Il controller Ingress riceve le informazioni di configurazione da un oggetto Kubernetes Ingress associato a uno o più oggetti Service. Ogni oggetto di servizio contiene le informazioni di routing utilizzate per indirizzare una richiesta in entrata a un determinato pod e porta.
A partire da Kubernetes versione 1.10.5-gke.3, puoi aggiungere la configurazione per il bilanciatore del carico associando un servizio a un oggetto BackendConfig. BackendConfig è una definizione di risorsa personalizzata (CRD) definita nel repository kubernetes/ingress-gce.
Il controller Kubernetes Ingress legge le informazioni di configurazione da BackendConfig e imposta il bilanciatore del carico di conseguenza. Un backendConfig contiene informazioni di configurazione specifiche per Cloud Load Balancing e ti consente di definire una configurazione separata per ogni servizio di backend bilanciamento del carico HTTP(S).
Prima di iniziare
Per abilitare IAP per GKE, devi avere:
- Un progetto di Google Cloud Console con la fatturazione abilitata.
- Un gruppo di una o più istanze GKE gestite da un bilanciatore del carico HTTPS. Il bilanciatore del carico deve essere creato automaticamente quando crei un oggetto Ingress in un cluster GKE.
- Scopri di più sulla creazione di una risorsa Ingress per HTTPS.
- Un nome di dominio registrato all'indirizzo del bilanciatore del carico.
- Il codice dell'app per verificare che tutte le richieste abbiano un'identità.
- Scopri come ottenere l'identità dell'utente.
Abilitazione di IAP
Configuring the OAuth consent screen
If you haven't configured your project's OAuth consent screen, you need to do so. An email address and product name are required for the OAuth consent screen.
-
Go to the OAuth consent screen.
Configure consent screen - Under Support email, select the email address you want to display as a public contact. The email address must belong to the currently logged in user account or to a Google Group of which the currently logged in user belongs.
- Enter the Application name you want to display.
- Add any optional details you'd like.
- Click Save.
To change information on the OAuth consent screen later, such as the product name or email address, repeat the preceding steps to configure the consent screen.
Creating OAuth credentials
-
Go to the Credentials page.
Go to the Credentials page - On the Create credentials drop-down list, select OAuth client ID.
- Under Application type, select Web application.
- Add a Name for your OAuth client ID.
- Click Create. Your OAuth client ID and client secret are generated and displayed on the OAuth client window.
- Click OK.
- Select the client that you created.
- Copy the client ID to the clipboard.
-
Add the universal redirect URL to the
authorized redirect URIs field in the following format:
https://iap.googleapis.com/v1/oauth/clientIds/CLIENT_ID:handleRedirect
where
CLIENT_ID
is the OAuth client ID. - Near the top of the page, click Download JSON. You'll use these credentials in a later step.
Setting up IAP access
-
Go to the
Identity-Aware Proxy page.
Go to the Identity-Aware Proxy page - Select the project you want to secure with IAP.
- Select the checkbox next to the resource you want to grant access to.
- On the right side panel, click Add principal.
-
In the Add principals dialog that appears, enter the email addresses of groups or
individuals who should have the IAP-secured Web App User role for the project.
The following kinds of principals can have this role:
- Google Account: user@gmail.com
- Google Group: admins@googlegroups.com
- Service account: server@example.gserviceaccount.com
- Google Workspace domain: example.com
Make sure to add a Google Account that you have access to.
- Select Cloud IAP > IAP-secured Web App User from the Roles drop-down list.
- Click Save.
Configuring BackendConfig
To configure BackendConfig for IAP, create a Kubernetes Secret and then
add an iap
block to the BackendConfig.
Creating a Kubernetes Secret
The BackendConfig uses a Kubernetes
Secret
to wrap the OAuth client you created earlier. Kubernetes Secrets are managed like
other Kubernetes objects by using the
kubectl
command-line interface (CLI). To create a Secret, run the following command where
client_id_key and client_secret_key are the keys from the JSON file you
downloaded when you created OAuth credentials:
kubectl create secret generic my-secret --from-literal=client_id=client_id_key \ --from-literal=client_secret=client_secret_key
The preceding command displays output to confirm when the Secret is successfully created:
secret "my-secret" created
Adding an iap
block to the BackendConfig
To configure the BackendConfig for IAP, you need to specify the
enabled
and secretName
values. To specify these values, ensure
that you have the compute.backendServices.update
permission and add the
iap
block to BackendConfig. In this block, my-secret is
the Kubernetes Secret name you created previously:
apiVersion: cloud.google.com/v1 kind: BackendConfig metadata: name: config-default namespace: my-namespace spec: iap: enabled: true oauthclientCredentials: secretName: my-secret
You also need to associate Service ports with your BackendConfig to trigger turning on IAP. One way to make this association is to make all ports for the service default to your BackendConfig, which you can do by adding the following annotation to your Service resource:
metadata: annotations: beta.cloud.google.com/backend-config: '{"default": "config-default"}'
To test the configuration, run kubectl get event
. If you see the message
"no BackendConfig for service port exists
", then you successfully
associated a service port with your BackendConfig, but the BackendConfig
resource wasn't found. This error can occur if you haven't created the BackendConfig resource,
created it in the wrong namespace, or misspelled the reference in the Service annotation.
If the secretName
you referenced doesn't exist or isn't structured
properly, one of the following error messages will display:
-
BackendConfig default/config-default is not valid: error retrieving secret "foo": secrets "foo" not found.
To resolve this error, make sure that you've created the Kubernetes Secret correctly as described in the previous section. -
BackendConfig default/config-default is not valid: secret "foo" missing client_secret data.
To resolve this error, make sure that you've created the OAuth credentials correctly. Also, make sure that you referenced the correctclient_id
andclient_secret
keys in the JSON you downloaded previously.
When the enabled
flag is set to true
and
the secretName
is correctly set, IAP is configured
for your selected resource.
Turning IAP off
To turn IAP off, you must set enabled
to
false
in the BackendConfig. If you delete the IAP
block from BackendConfig, the settings will persist. For example, if IAP is
enabled with secretName: my_secret
and you delete the block, then
IAP will still be turned on with the OAuth credentials stored in
my_secret
.
Passaggi successivi
- Scopri come configurare Cloud CDN su GKE.
- Scopri come configurare Cloud Armor per GKE.
- Scopri di più sulla risorsa BackendConfig.