Personnaliser IAP

Ce document explique comment personnaliser les paramètres Identity-Aware Proxy (IAP). Ces paramètres vous permettent de contrôler divers comportements, y compris :

• Compatibilité avec Cloud Service Mesh et Istio sur Google Kubernetes Engine.
• le traitement des requêtes CORS préliminaires ;
• la façon dont les utilisateurs sont authentifiés.
• la page d'erreur affichée aux utilisateurs lorsque l'accès est refusé.

Gérer les paramètres

Vous pouvez afficher et modifier les paramètres IAP sur les équilibreurs de charge et les applications App Engine à l'aide de la console Google Cloud , de l'API IAP ou de la Google Cloud CLI.

Pour mettre à jour les paramètres IAP sur toutes les ressources, y compris les dossiers, les projets et les organisations, utilisez Google Cloud CLI ou l'API.

Pour gérer les paramètres dans IAP :

gcloud iap settings get --project=PROJECT-ID

gcloud iap settings get --folder=FOLDER-ID

gcloud iap settings get --organization=ORGANIZATION-ID

gcloud iap settings get --project=PROJECT-ID \
  --resource-type=RESOURCE-TYPE-NAME

gcloud iap settings set SETTING_FILE --project=PROJECT-ID \
  --resource-type=RESOURCE-TYPE-NAME

https://iap.googleapis.com/v1/projects/PROJECT-ID/iap_web/appengine-APP-ID/services/SERVICE-ID/versions/VERSION-ID:iapSettings

https://iap.googleapis.com/v1/projects/PROJECT-ID:iapSettings

https://iap.googleapis.com/v1/folders/FOLDER-ID:iapSettings

https://iap.googleapis.com/v1/organizations/ORGANIZATION-ID:iapSettings

Rôles et autorisations des paramètres IAP

Cette section décrit les rôles et les autorisations requis pour afficher et modifier les paramètres IAP.

Rôles associés aux paramètres

Vous pouvez attribuer le rôle Administrateur des paramètres IAP (roles/iap.settingsAdmin) au niveau de l'organisation, du dossier et du projet. Pour connaître les autorisations accordées par le rôle "Administrateur des paramètres IAP", consultez Autorisations liées aux paramètres.

Pour en savoir plus sur les rôles et les autorisations pour IAP, consultez Rôles et autorisations Identity-Aware Proxy.

Les rôles de base suivants fournissent ces autorisations :

• Le rôle Lecteur du projet (roles/viewer) accorde toutes les autorisations getSettings.

• Le rôle Éditeur (roles/editor) accorde toutes les autorisations décrites dans le tableau.

Autorisations des paramètres

Le tableau suivant liste les autorisations IAM requises pour lire et modifier les paramètres de chaque type de ressource. Pour une description des différents types de ressources, consultez Ressources et autorisations.

Pour en savoir plus sur l'attribution de rôles IAM, consultez Accorder, modifier et révoquer les accès.

Personnaliser les paramètres des achats via l'application

IAP fournit les paramètres de personnalisation suivants :

Vous pouvez appliquer les paramètres au niveau du projet ou à n'importe quel niveau de ressource IAP inférieur.

Vous pouvez configurer les paramètres des ressources IAP Web, mais pas les ressources accessibles à l'aide du service IAP pour le transfert TCP.

En utilisant access_settings.cors_settings.allow_http_options comme exemple, vous pouvez configurer les paramètres de personnalisation comme suit :

access_settings:
  cors_settings:
    allow_http_options: "false"

{
  "access_settings": {
    "cors_settings": {
      "allow_http_options": "false"
    }
  }
}

Les sections suivantes fournissent plus d'informations sur chaque paramètre.

Autoriser les requêtes HTTP OPTIONS (CORS préliminaire)

Les règles de même origine du Web empêche les navigateurs d'envoyer des requêtes AJAX entre des sites Web. Par défaut, le code JavaScript d'une page diffusée depuis une origine ne peut pas utiliser AJAX pour envoyer une requête à une application sécurisée avec IAP hébergée sur une origine différente.

Dans certains cas, les navigateurs essaient automatiquement d'exécuter une requête, mais ils suppriment le contenu de la réponse s'il n'inclut pas d'en-tête Access-Control-Allow-Origin. Pour autoriser ce type de requête, incluez cet en-tête dans les réponses de votre application.

Dans d'autres cas, les navigateurs envoient une requête CORS préliminaire, un type de requête HTTP OPTIONS, avant d'envoyer la requête d'origines multiples. Si votre application ne répond pas avec une réponse préliminaire appropriée (contenant les en-têtes de réponse Access-Control-* requis), le navigateur bloquera la requête avec une erreur. En outre, étant donné que les requêtes préliminaires ne sont pas envoyées avec des identifiants d'authentification (par exemple, un cookie de session IAP), IAP répond également par une erreur.

Pour autoriser ces requêtes :

1. Ajoutez du code à l'application qui répond aux requêtes OPTIONS.

2. Définissez le paramètre access_settings.cors_settings.allow_http_options sur true pour qu'IAP transmette les requêtes OPTIONS à votre application.

S'authentifier à l'aide d'un domaine Google Workspace

Si seuls les membres d'un domaine Google Workspace spécifique utilisent votre application, vous pouvez configurer IAP pour optimiser le flux d'authentification. Cela présente plusieurs avantages :

• Si un utilisateur est connecté avec plusieurs comptes, tels qu'un compte professionnel et un compte personnel, le système sélectionne automatiquement son compte professionnel au lieu d'afficher l'UI de sélection du compte.

• Si un utilisateur n'est pas connecté à son compte Google, l'interface utilisateur de connexion remplira automatiquement la partie domaine de son adresse e-mail (ce qui signifie que l'utilisateur n'aura qu'à saisir alice au lieu de alice@example.com, par exemple).

• Si votre domaine Google Workspace est configuré pour utiliser un fournisseur d'authentification unique tiers, le système affiche cette page de connexion personnalisée au lieu de celle de Google.

Pour activer ce comportement, définissez la valeur de access_settings.oauth_settings.login_hint sur le nom de domaine de votre compte Google Workspace (par exemple, example.com). La propriété du domaine doit avoir été validée : vous ne pouvez pas utiliser de domaines DNS Internet arbitraires qui vous appartiennent. (Les domaines qui ont été ajoutés en tant que domaine principal ou secondaire Google Workspace sont validés et peuvent donc être utilisés ici.)

Si vous devez authentifier des utilisateurs en dehors du domaine, vous pouvez utiliser l'authentification programmatique.

Pour plus d'informations, consultez la documentation OpenID Connect.

Définir une page d'erreur "Accès refusé" personnalisée

Vous pouvez définir une URL dans ce champ qui redirige les utilisateurs vers une page personnalisée au lieu de la page d'erreur IAP par défaut lorsque l'accès est refusé par une stratégie.

Vous pouvez également intégrer l'URL de dépannage avec cette fonctionnalité. Pour en savoir plus, consultez Activer l'URL de dépannage pour votre page d'erreur "Accès refusé" personnalisée.

Émettre des ID de maillage RCToken Cloud Service Mesh et Istio

Si vous utilisez Istio sur GKE, vous pouvez configurer IAP pour produire un jeton RCToken compatible avec Istio. Si ce champ est défini sur une chaîne non vide, IAP ajoute un en-tête HTTP Ingress-Authorization contenant un jeton RCToken. La revendication aud est définie sur la valeur du champ.

S'authentifie avec Identity Platform.

Par défaut, IAP utilise le système d'identité intégré de Google. Si ce champ est défini, IAP utilise Identity Platform à la place pour authentifier les utilisateurs.

Comprendre l'héritage des paramètres dans la hiérarchie des ressources

IAP évalue toujours les requêtes pour une version de service Web spécifique. Ce type de ressource se trouve au niveau le plus bas de la hiérarchie des ressources, qui se présente comme suit :

- Organization
  - Folder
    - Project
      - All web services
        - Web service type
          - Web service
            - Web service version

Pour déterminer les paramètres à appliquer à une version de service Web, IAP commence par un ensemble de valeurs par défaut, puis parcourt la hiérarchie de haut en bas. Les paramètres sont appliqués tels qu'ils sont trouvés. Par conséquent, les valeurs définies à un niveau inférieur remplacent celles définies à un niveau supérieur. Par exemple, si access_settings.cors_settings.allow_http_options est défini sur true au niveau du projet, mais sur false au niveau du service, la valeur effective est false.

Pour en savoir plus sur la hiérarchie des ressources IAP, consultez la section Ressources et autorisations.