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.

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. In R141, it cannot cross a dot (.); when used as a complete label, it matches exactly one DNS label. Starting with R142, it can cross dots and match multiple DNS labels, as in PAC glob patterns. | task-*.ecs.internal, db.*.corp |	task-*.ecs.internal, db.*.corp
?	Matches exactly one character other than a dot (.).	k8s-node?.prod.corp

A DNS label is one part of a hostname separated by dots. For example, db.us-west-2.corp contains three labels: db, us-west-2, and 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

R141 has a temporary single-label restriction for * in glob patterns. Starting with R142, * can span multiple labels, as in PAC glob patterns.

Pattern	Hostname	R141	R142 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, the * in db.*.corp matches exactly one label between db. and .corp. Starting with R142, it can match multiple labels in that position. The literal dots in the pattern still have to match, so db.corp does not match in either release.

Review existing R141 patterns before upgrading to R142. 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. Starting with R142, there is no operator that matches an arbitrary number of characters while stopping at the next dot.

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

A glob-pattern host must meet all of these requirements:

• Include at least one dot (.). Single-label patterns such as host* are rejected during validation.
• 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.
• Client-based access with glob patterns requires Netskope Client R141 or later.
• In R141, * in a glob pattern cannot cross a dot. This temporary restriction changes in R142, when * can match multiple DNS labels.
• 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 Netskope Client R141 or later, or a supported 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 R141, confirm that * in a glob pattern is not expected to cross a dot. When used as a complete label, it matches exactly one label. Starting with R142, account for * matching across multiple labels.
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