Use Glob Patterns in Private App Definitions

Use glob patterns to define Private Apps whose hostnames follow a predictable naming convention but contain changing values. Glob patterns are useful for dynamic environments in which workloads are created, renamed, or replaced frequently, such as AWS ECS, Kubernetes, and multi-region cloud services.

For example, instead of adding every ECS task hostname separately, define the host as task-*.ecs.internal.

Glob patterns provide more precise matching than a broad leading wildcard such as *.internal. This can reduce administrative work and prevent unrelated hosts from being steered through Netskope Private Access.

Starting with R141, an interior * can perform a multi-level match. Review Behavior by release before using a pattern in production.

Supported access methods

Access method	Glob patterns
Netskope Client-based access	Supported with an eligible client build
Netskope Enterprise Browser	Supported with an eligible Enterprise Browser build
NPA Browser Access (clientless)	Not supported
User Portal applications	Not supported

Glob patterns apply to DNS hostnames. They do not apply to IP addresses or CIDR definitions.

Glob syntax

Glob patterns support these metacharacters:

Character	Meaning	Example
*	Matches a variable sequence of characters. Starting with R141, an interior * used as a complete label can span one or more DNS labels.	task-*.ecs.internal, db.*.corp
?	Matches exactly one character other than a dot (.).	k8s-node?.prod.corp

All other supported hostname characters are matched literally. Matching is case-insensitive.

The final, rightmost label must be literal. Do not place * or ? in the final label. For example, task-*.internal is valid, but task.internal* is not.

Existing leading wildcards

A host in the existing *.domain format remains a leading wildcard, not a glob pattern. Its behavior does not change. A leading wildcard continues to match subdomains at any depth.

For example, *.example.internal matches both:

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

Use a glob pattern when variable characters appear in another position or when ? is required.

Behavior by release

Pattern	Hostname	R140 beta	R141 and later
db.*.corp	db.us-west-2.corp	Matches	Matches
db.*.corp	db.us-west-2.rds.corp	Does not match	Matches
db.*.corp	db.corp	Does not match	Does not match

In R141 and later, db.*.corp can consume multiple labels between db. and .corp. Review existing R140 patterns before upgrading. A pattern that previously matched one label can match additional, deeper hostnames after the upgrade.

If that broader match is not intended, replace the variable portion with more literal text or use ? when the changing portion has a known character length. R141 does not provide an operator that means “any arbitrary characters, but stop at the next dot.”

R140 beta limitation: The R140 UI and validation API can accept a dot-less glob pattern such as host*, even though the Netskope Client cannot intercept a single-label DNS name. Such a definition does not steer matching traffic. Do not use dot-less patterns in R140. Starting with R141, NPA rejects them during validation.

Before you begin

• Ask your Netskope representative to enable the controlled-beta feature for the tenant.
• Confirm that endpoints use a Netskope Client or Enterprise Browser build that supports glob patterns.
• Identify the fixed and variable parts of the application hostnames.
• Test the pattern against hostnames that must match and hostnames that must not match.
• Avoid public or shared DNS suffixes when a dedicated private namespace is available.

Create a Private App with a glob pattern

1. Go to Settings > Security Cloud Platform > App Definition.
2. Select Private App Segments.
3. Select New Application Segment, or edit an existing application segment.
4. Enter an application name.
5. In Host, enter the glob pattern, such as task-*.ecs.internal.
6. Add the required TCP or UDP ports.
7. Select one or more Publishers.
8. Configure the remaining application settings.
9. Select Save.
10. Review the confirmation window, and then select Confirm.

Allow the normal policy distribution interval for the updated definition to reach endpoints.

Validation rules

Starting with R141, a glob-pattern host must meet all of these requirements. Follow the same rules when creating R140 beta definitions, even though R140 does not enforce the dot requirement correctly.

• Include at least one dot (.).
• Include at least one literal letter, number, or hyphen.
• Use no more than three * characters.
• Use no more than ten ? characters.
• Use a literal final label; * and ? are not allowed in the rightmost label.
• Do not use adjacent asterisks (**).
• Do not use glob characters in an IP-address-like value, such as 10.*.1.50.
• Use only supported DNS hostname characters.

Examples:

Input	Result	Reason
task-*.ecs.internal	Accepted	Valid glob pattern
k8s-node?.prod.corp	Accepted	? represents one character
host*	Rejected in R141 and later	The pattern does not contain a dot
*.*	Rejected	The pattern contains no literal character
a*b*c*d*.internal	Rejected	More than three * characters
*.int?rnal	Rejected	A metacharacter appears in the final label
abc**.internal	Rejected	Adjacent asterisks are not supported
10.*.1.50	Rejected	Glob patterns do not apply to IP addresses

Tenant-level restrictions for top-level domains and public DNS suffixes continue to apply.

Matching priority

When more than one Private App definition can match the same destination, NPA evaluates hostname definitions in this order:

1. Exact FQDN
2. Glob pattern
3. Existing leading wildcard
4. Default rule

For example, if app.prod.internal is configured as an exact FQDN and also matches app.*.internal, the exact FQDN definition takes priority.

NPA can display a non-blocking warning when a new pattern overlaps an existing glob pattern or wildcard. Resolve overlaps whenever possible. If overlapping patterns are retained, traffic might be associated with a different Private App than intended.

Limitations

• Glob patterns are not supported for NPA Browser Access or User Portal applications.
• Glob patterns do not apply to IPv4 addresses, IPv6 addresses, or CIDR ranges.
• The final hostname label must be literal.
• Full regular expressions and character classes such as [a-z] are not supported.
• Adjacent asterisks (**) are not supported.
• Older Netskope Clients do not interpret glob patterns. They safely treat a pattern as a literal hostname, so dynamic hosts do not match.
• If the controlled-beta feature is disabled after patterns are created, those patterns no longer perform glob matching.

Troubleshoot glob-pattern access

If a hostname does not match or traffic is not steered:

1. Confirm that the feature is enabled for the tenant.
2. Confirm that the endpoint uses a supported Netskope Client or Enterprise Browser build.
3. Confirm that the application uses Client-based access or Enterprise Browser, not Browser Access.
4. Compare the hostname with the complete pattern, including all literal characters and dots.
5. Confirm that each ? corresponds to exactly one non-dot character.
6. For R140, confirm that an interior * is not expected to cross a dot.
7. Review overlapping-pattern warnings and check for a higher-priority exact FQDN definition.
8. Confirm that the Publisher can resolve the hostname using the private DNS environment.
9. Allow the normal policy distribution interval after changing the application definition.

Common use cases

Dynamic AWS ECS tasks

Use one definition for task hostnames with changing task identifiers:

task-*.ecs.internal

Examples that match:

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

Example that does not match:

• database.ecs.internal

Kubernetes nodes or versioned services

Use ? when exactly one character varies:

k8s-node?.prod.corp

Examples that match:

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

Example that does not match:

• k8s-node12.prod.corp

Multi-region services

Use a multi-level pattern when the hierarchy between a fixed prefix and suffix can vary:

db.*.corp

Starting with R141, examples that match include:

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

Examples that do not match:

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

Hosts with multiple changing values

Use more than one metacharacter when different parts of a hostname vary:

*-worker-*.svc.internal

Example that matches:

• payments-worker-4f92.svc.internal

Example that does not match:

• payments-server-4f92.svc.internal

Predictable desktop or server names

Use a position-specific pattern for hosts that follow an organizational naming convention:

rdp-finance-??.corp.internal

Examples that match:

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

Example that does not match:

• rdp-finance-001.corp.internal