Utiliser des conditions applicables aux noms d'hôte et aux chemins d'accès

Important :Vous ne pouvez limiter l'accès en fonction du nom d'hôte et du chemin de l'URL qu'à l'aide de gcloud CLI.

Cette page décrit les conditions Identity and Access Management (IAM) applicables aux noms d'hôte et aux chemins d'accès.

Vous pouvez sécuriser les ressources Identity-Aware Proxy (IAP) à l'aide du nom d'hôte et du chemin d'une URL de requête. Par exemple, la condition IAM request.path.startsWith peut être utilisée pour n'accorder l'accès aux employés du groupe Accès privilégié que si le chemin de l'URL commence par /admin.

Pour en savoir plus sur l'utilisation des conditions applicables aux noms d'hôte et aux chemins d'accès, consultez la section Attributs de requête.

Normalisation des chaînes

Une URL est associée à un nom d'hôte et un chemin d'accès. Par exemple, l'URL https://sheets.google.com/create?query=param est associée au nom d'hôte sheets.google.com et au chemin d'accès /create.

Les backends peuvent interpréter les noms d'hôtes et les chemins d'accès de différentes manières. Pour éliminer toute ambiguïté, IAP normalise les chaînes de noms d'hôte et de chemins d'accès lors de la vérification des stratégies.

IAP procède à deux vérifications des stratégies lorsqu'une requête est associée à un chemin d'accès non normalisé. Si la vérification des stratégies réussit pour le chemin d'accès non normalisé, IAP le normalise. Une deuxième vérification des stratégies est effectuée. L'accès est accordé si la vérification réussit pour les chemins d'accès non normalisé et normalisé.

Par exemple, si une requête est associée au chemin d'accès /internal;some_param/admin, IAP commence par effectuer une vérification des stratégies pour le chemin d'accès non normalisé (/internal). Si celle-ci réussit, IAP effectue une deuxième vérification pour le chemin d'accès normalisé (/internal/admin).

Noms d'hôte

La normalisation des noms d'hôte implique ce qui suit :

• Suppression des points finaux
• Mise en minuscules des caractères
• Conversion au format ASCII

Les noms d'hôte qui incluent des caractères non ASCII sont ensuite normalisés à l'aide de Punycode. Vous devez utiliser Punycode pour normaliser la chaîne de votre nom d'hôte afin d'obtenir une correspondance.

Pour normaliser la chaîne de votre nom d'hôte avec Punycode, utilisez un convertisseur tel que Punycoder.

Voici des exemples de noms d'hôte normalisés :

• FOO.com est normalisé en foo.com.
• café.fr est normalisé en xn--caf-dma.fr.

Chemins d'accès

La normalisation des chemins d'accès implique ce qui suit :

• Suppression des paramètres de chemin
• Conversion des chemins relatifs en leur équivalent absolu

Un paramètre de chemin inclut tous les caractères compris entre un point-virgule (;) et la barre oblique (/) suivante ou la fin du chemin.

Les requêtes contenant des sections de chemin d'accès commençant par ..; sont considérées comme non valides. Par exemple, /..;bar/ et /bar/..;/ renvoient l'erreur HTTP 400: Bad Request.

Voici des exemples de chemins d'accès normalisés :

• /internal;some_param/admin est normalisé en /internal/admin.
• /a/../b est normalisé en /b.
• /bar;param1/baz;baz;param2 est normalisé en /bar/baz.

Terminaisons des sous-domaines

Une stratégie définie avec request.host.endsWith("google.com") correspond à sub_domain.google.com et testgoogle.com. Si vous souhaitez limiter votre stratégie aux seuls sous-domaines qui se terminent par google.com, définissez-la sur request.host.endsWith(".google.com").