Utiliser des modèles Glob dans les définitions d'applications privées

Utilisez des modèles glob pour définir des applications privées dont les noms d’hôte suivent une convention de nommage prévisible mais contiennent des valeurs changeantes. Les modèles glob sont utiles pour les environnements dynamiques dans lesquels les charges de travail sont créées, renommées ou remplacées fréquemment, tels qu’AWS ECS, Kubernetes et les services cloud multirégionaux.

Par exemple, au lieu d'ajouter chaque nom d'hôte de tâche ECS séparément, définissez l'hôte comme task-*.ecs.internal.

Les modèles glob offrent une correspondance plus précise qu'un caractère générique de début large tel que *.internal. Cela peut réduire le travail administratif et empêcher les hôtes non liés d'être dirigés via Netskope Private Access.

À partir de la version R141, un * intérieur peut effectuer une correspondance à plusieurs niveaux. Examinez Behavior by release avant d'utiliser un motif en production.

Méthodes d'accès prises en charge

Les motifs glob s'appliquent aux noms d'hôtes DNS. Ils ne s'appliquent pas aux adresses IP ou aux définitions CIDR.

Glob syntax

Les modèles Glob prennent en charge ces métacaractères :

Tous les autres caractères de nom d'hôte pris en charge sont mis en correspondance littéralement. La correspondance ne tient pas compte de la casse.

L’étiquette finale, située le plus à droite, doit être littérale. Ne placez pas * ou ? dans l’étiquette finale. Par exemple, task-*.internal est valide, mais task.internal* ne l’est pas.

Caractères génériques de début existants

Un hôte au format *.domain existant reste un caractère générique de début, et non un modèle glob. Son comportement ne change pas. Un caractère générique de début continue de correspondre aux sous-domaines à n'importe quelle profondeur.

Par exemple, *.example.internal correspond aux deux :

• app.example.internal
• app.eu.example.internal

Utilisez un modèle glob lorsque des caractères variables apparaissent dans une autre position ou lorsque ? est requis.

Comportement par version

Dans la version R141 et ultérieures, db.*.corp peut consommer plusieurs labels entre db. et .corp. Examinez les modèles R140 existants avant la mise à niveau. Un modèle qui correspondait précédemment à un label peut correspondre à des noms d'hôtes supplémentaires et plus profonds après la mise à niveau.

Si cette correspondance plus large n'est pas souhaitée, remplacez la partie variable par un texte plus littéral ou utilisez ? lorsque la partie changeante a une longueur de caractère connue. R141 ne fournit pas d'opérateur signifiant « n'importe quels caractères arbitraires, mais s'arrêter au point suivant ».

R140 beta limitation: L'interface utilisateur et l'API de validation de R140 peuvent accepter un modèle glob sans point tel que host*, même si le Netskope Client ne peut pas intercepter un nom DNS à étiquette unique. Une telle définition ne dirige pas le trafic correspondant. N'utilisez pas de modèles sans point dans R140. À partir de R141, NPA les rejette lors de la validation.

Avant de commencer

• Demandez à votre représentant Netskope d'activer la fonctionnalité en version bêta contrôlée pour votre locataire.
• Confirmez que les terminaux utilisent une version de Netskope Client ou d'Enterprise Browser qui prend en charge les modèles glob.
• Identifiez les parties fixes et variables des noms d'hôte de l'application.
• Testez le motif par rapport aux noms d'hôtes qui doivent correspondre et aux noms d'hôtes qui ne doivent pas correspondre.
• Évitez les suffixes DNS publics ou partagés lorsqu’un espace de noms privé dédié est disponible.

Créer une application privée avec un modèle glob

1. Allez sur Settings > Security Cloud Platform > App Definition.
2. Select Private App Segments.
3. Select New Application Segment ou modifiez un segment d'application existant.
4. Saisissez un nom d'application.
5. Dans Host, saisissez le modèle glob, tel que task-*.ecs.internal.
6. Ajoutez les ports TCP ou UDP requis.
7. Select un ou plusieurs éditeurs.
8. Configurez les paramètres d'application restants.
9. Select Save.
10. Examinez la fenêtre de confirmation, puis sélectionnez Confirm.

Laissez le temps à l'intervalle de distribution de politique normal pour que la définition mise à jour atteigne les terminaux.

Règles de validation

À partir de la version R141, un hôte de type glob-pattern doit répondre à toutes ces exigences. Suivez les mêmes règles lors de la création des définitions bêta R140, même si la version R140 n'applique pas correctement l'exigence relative au point.

• Incluez au moins un point (.).
• Incluez au moins une lettre, un chiffre ou un trait d'union littéral.
• N'utilisez pas plus de trois caractères *.
• N’utilisez pas plus de dix caractères ?.
• Utilisez une étiquette finale littérale ; * et ? ne sont pas autorisés dans l'étiquette la plus à droite.
• N'utilisez pas d'astérisques adjacents (**).
• N'utilisez pas de caractères glob dans une valeur de type adresse IP, telle que 10.*.1.50.
• Utilisez uniquement les caractères de nom d'hôte DNS pris en charge.

Exemples :

Les restrictions au niveau du locataire pour les domaines de premier niveau et les suffixes DNS publics continuent de s'appliquer.

Priorité de correspondance

Lorsqu'une même destination peut correspondre à plusieurs définitions d'applications privées, NPA évalue les définitions de noms d'hôte dans l'ordre suivant :

1. FQDN exact
2. Modèle glob
3. Caractère générique de début existant
4. Règle par défaut

Par exemple, si app.prod.internal est configuré comme un FQDN exact et correspond également à app.*.internal, la définition du FQDN exact est prioritaire.

NPA peut afficher un avertissement non bloquant lorsqu'un nouveau modèle chevauche un modèle glob ou un caractère générique existant. Résolvez les chevauchements dans la mesure du possible. Si des modèles qui se chevauchent sont conservés, le trafic pourrait être associé à une application privée différente de celle prévue.

Limites

• Les modèles glob ne sont pas pris en charge pour les applications NPA Browser Access ou User Portal.
• Les modèles glob ne s'appliquent pas aux adresses IPv4, aux adresses IPv6 ou aux plages CIDR.
• L'étiquette finale du nom d'hôte doit être littérale.
• Les expressions régulières complètes et les classes de caractères telles que [a-z] ne sont pas prises en charge.
• Les astérisques adjacents (**) ne sont pas pris en charge.
• Les anciennes versions de Netskope Client n'interprètent pas les motifs glob. Ils traitent en toute sécurité un motif comme un nom d'hôte littéral, de sorte que les hôtes dynamiques ne correspondent pas.
• Si la fonctionnalité en version bêta contrôlée est désactivée après la création de motifs, ces motifs n'effectuent plus de correspondance glob.

Dépanner l'accès par modèle glob

Si un nom d’hôte ne correspond pas ou si le trafic n’est pas piloté :

1. Confirmez que la fonctionnalité est activée pour le locataire.
2. Confirmez que le point de terminaison utilise une version prise en charge de Netskope Client ou d'Enterprise Browser.
3. Confirmez que l'application utilise l'accès basé sur le client ou Enterprise Browser, et non l'accès par navigateur (Browser Access).
4. Comparez le nom d'hôte avec le motif complet, y compris tous les caractères littéraux et les points.
5. Confirmez que chaque ? correspond exactement à un caractère autre qu'un point.
6. Pour R140, confirmez qu'un * intérieur n'est pas censé traverser un point.
7. Examinez les avertissements de chevauchement de motifs et vérifiez s'il existe une définition FQDN exacte de priorité supérieure.
8. Confirmez que l'éditeur peut résoudre le nom d'hôte en utilisant l'environnement DNS privé.
9. Laissez s'écouler l'intervalle normal de distribution des politiques après avoir modifié la définition de l'application.

Cas d'utilisation courants

Tâches AWS ECS dynamiques

Utilisez une définition pour les noms d'hôtes de tâche avec des identifiants de tâche changeants :

task-*.ecs.internal

Exemples correspondants :

• task-a17f3.ecs.internal
• task-worker-1e2cdc5.ecs.internal

Exemple qui ne correspond pas :

• database.ecs.internal

Nœuds Kubernetes ou services versionnés

Utilisez ? lorsqu'exactement un caractère varie :

k8s-node?.prod.corp

Exemples correspondants :

• k8s-node1.prod.corp
• k8s-nodeA.prod.corp

Exemple qui ne correspond pas :

• k8s-node12.prod.corp

Services multi-régions

Utilisez un modèle multi-niveaux lorsque la hiérarchie entre un préfixe et un suffixe fixes peut varier :

db.*.corp

À partir de la version R141, les exemples correspondants incluent :

• db.us-west-2.corp
• db.us-west-2.rds.corp
• db.eu-central-1.database.production.corp

Exemples ne correspondant pas :

• db.corp
• web.us-west-2.rds.corp

Hôtes avec plusieurs valeurs changeantes

Utilisez plus d'un métacaractère lorsque différentes parties d'un nom d'hôte varient :

*-worker-*.svc.internal

Exemple de correspondance :

• payments-worker-4f92.svc.internal

Exemple qui ne correspond pas :

• payments-server-4f92.svc.internal

Noms de bureau ou de serveur prévisibles

Utilisez un modèle spécifique à la position pour les hôtes qui suivent une convention de nommage organisationnelle :

rdp-finance-??.corp.internal

Exemples correspondants :

• rdp-finance-01.corp.internal
• rdp-finance-eu.corp.internal

Exemple qui ne correspond pas :

• rdp-finance-001.corp.internal