Teams allows you to create unique rules for parts of an application that share a root path. Imagine an example application is deployed at
dashboard.com/eng that anyone on the engineering team should be able to access. However, a tool deployed at
dashboard.com/eng/exec should only be accessed by the executive team.
When multiple rules are set for a common root path, its subdomains do not inherit rules. For example, when setting rules for
dashboard.com/eng/exec does not inherit the rule set for
dashboard.com/eng. Instead, the more specific rule takes precedence.
Using wildcards in subdomains and paths
When you create an application for a specific subdomain or path, you can use asterisks (
*) as wildcards. Wildcards allow you to extend the application you're creating to all the subdomains or paths of a given apex domain.
This is how to use wildcards effectively:
Protect all subdomains of an apex domain
Using a wildcard in the subdomain field does not cover the apex domain.
Protect all paths of an apex domain
If you want to protect an apex domain and all of the paths under it, leave the path field empty.
To protect all the paths under an apex domain, but not the apex domain itself, use a wildcard in the path field.
Protect multi-level subdomains
Using a wildcard in the subdomain field to protect multi-level subdomains does not cover that subdomain's top subdomain nor the apex domain.
Protect multi-level paths
Using a wildcard in the path field to protect multi-level paths does not cover that subpath's parent path nor the apex domain.