Zones

A zone, in Sysdig, is a collection of scopes that represent important areas of your business. Zones filter what data, such as events and findings, users or teams can see. For example, you can create a zone for your production environment, a staging environment, or a region.

Prerequisites

Before you create a zone, connect a Data Source to scan your infrastructure for the necessary data. See Enable Inventory Resources.

If you intend to filter by team, ensure you Enable Team Zones.

Default Zones

Sysdig provides two zones by default:

You can create more Zones to suit your organization’s needs.

Create and Configure a Zone

A completed Zone includes:

  • Zone name and description
  • Zone scope (the area of business to be included)

To create a Zone:

  1. Log in to Sysdig Secure, and navigate to Inventory > Zones.

  2. Click New Zone.

  3. Enter a Name for the new zone.

  4. (Optional) Enter a Description.

  5. In the Scope section, select Add Scope.

  6. Select from the available platforms. These include AWS, GCP, Kubernetes, Git, and more.

  7. Use the All Resources toggle to determine whether the zone should include all the resources within the selected platform. It is enabled by default.

  8. To define a more granular scope, toggle All Resources off. Then, specify the resources to include as key-value pairs. To define a more specific scope using key-value pairs, do the following:

    1. Select a key/attribute:

      • Resource: These are pre-defined, and vary depending on the platform. For example, Account(AWS), Subscription (Azure),and Project (GCP). These align with cloud provider best practices and help prevent visibility gaps. For available resources, see Available Scope Rule Attributes
      • Custom Label: Scope with tags and labels. This option is less optimal than scoping with platform-native resources.

    2. Select an operator:

      • in: For exact matches.
      • is not: For excluding matches.
      • contains: For substring matches.
      • does not contain: For excluding substring matches.
      • For more details, see Use Operators and Values

    3. Enter one or more values.

    • You can define multiple scopes. They are combined using OR. Attributes within a scope are combined using AND.

  9. Click Save to save the Zone.

Your saved zone will appear in the list on the main Zones page. Data from Zones may take up to 24 hours to appear in other modules, such as Inventory > All Resources.

Use of the Region scope may result in more data being shown to users in the Posture > Identity Management pages than defined in the Zone.

Available Scope Rule Attributes

Supported scope rule attributes vary according to platform:

AWS

  • Organization
  • Account
  • Region
  • Labels

Azure

  • Organization
  • Subscription
  • Region
  • Labels

GCP

  • Organization
  • Project
  • Region
  • Labels

OCI

  • Tenancy
  • Compartment
  • Region
  • Labels

Host

  • Cluster
  • Host Name (for Docker, Linux hosts)
  • Shield Tags

Kubernetes

  • Distribution (AKS, GKE, EKS, Vanilla Kubernetes)
  • Cluster name
  • Namespace
  • Labels
  • Shield Tags

Git

  • Git integration
  • Git source(s)

Image

  • Registry
  • Repository

Use Operators and Values

After the key, you can use operators and values.

Sysdig supports the following operators:

in

  • Matches exact values. Use this to scope specific cluster names.
  • For example, defining a scope, Cluster + in + prd, will only match the cluster prd, if it exists.
  • You can match multiple values. For example, use the scope, Cluster + in + prd + demo, to include the clusters prd and demo.
  • Cluster in prd includes only the prd cluster. Supports multiple values, For example, Cluster in prd, demo.

contains

  • Matches a value inside a string. Use this to scope cluster names containing a given value.
  • Cluster contains prd matches clusters named myApp-prd, prd1, prd-sysdig.
  • For example, defining a scope, Cluster + contains + prd, will include clusters such as myApp-prd, prd1, and prd-sysdig.

is not

  • Excludes resources that exactly match the specified value(s).
  • Example: Cluster + is not + prd excludes the prd cluster from the Zone scope.

does not contain

  • Excludes resources containing the specified substring.
  • Example: Cluster + does not contain + prd excludes clusters like test-prd or prd-east, and includes all others.

Combining negative operators (is not, does not contain) with positive operators (in, contains) lets you define inclusion and exclusion rules for label-based scoping within a Zone.

To achieve finer control or more specific segmentation, use supported labels designed for Zones filtering (for example, kubernetes.namespace.name, cloud.account.id, etc.), rather than relying solely on negative operators.

After the operator, select a value. Each value field has a limitation of 2048 characters per row. For longer values, consider adding scopes. This improves readability and maintenance of your scopes.

Auto-complete values will be based on resources that were scanned and listed in the Inventory.

How Scope Conditions Combine

Within a single platform block, all conditions are combined with AND. Across separate platform blocks, they’re combined with OR.

This matters when a zone combines conditions from different levels of a resource hierarchy — such as Cluster and Namespace — in the same block. A resource only carries the metadata for its own level and the levels above it, not the levels below it.

For example, a Namespace resource carries its Cluster’s metadata, but a Cluster resource does not carry Namespace metadata, since a cluster is not part of any namespace — namespaces belong to clusters. Combining a Cluster condition and a Namespace condition with AND in one block will therefore never match a Cluster resource, regardless of which namespaces actually run in that cluster.

Example — Cluster and Namespace combined in one block:

Platform: Kubernetes
Cluster name in (prod-cluster)
Namespace name in (namespace-a, namespace-b)

This matches Namespace-level resources (they carry both Cluster and Namespace metadata). It does not match the Cluster resource itself, which has no Namespace metadata to evaluate.

To also match the Cluster resource, use a separate block:

Platform: Kubernetes
Cluster name in (prod-cluster)
OR
Platform: Kubernetes
Namespace name in (namespace-a, namespace-b)

Each resource level is now matched against attributes it actually carries.

To scope a zone across more than one level of a resource hierarchy, use one platform block per level, not one block combining all levels. This applies to resource filtering across the platform generally, not just to Zones.

Known Limitations

Zone Size Limits

There are limits to the number of platforms, keys, and values supported per zone, as well as the number of zones supported per team.

  • The maximum number of platforms that can be supported per zone is 20.
  • The maximum number of keys that can be supported per zone is 25 (for example, Region is one key).
  • The maximum number of values that can be supported per key is 50 (for example, Region in eu-central-1 is one value).
  • The maximum number of zones that can be supported per team is 20.

Attribute and Scope Behavior

  • Annotations are not supported in Zone scope conditions. Only labels and the platform-specific resource attributes listed under Available Scope Rule Attributes can be used.
  • Cloud account ID vs. alias. A Zone’s account condition can resolve against either the account ID or an account alias. If an account was not fully onboarded and only an alias is available, Zone resolution for that account is best-effort and may return zero results.
  • Key-only tags (tags with no value) are supported using an internal placeholder that represents “label exists.” You don’t need a separate operator for this — use the standard in operator with the key.
  • Zones don’t apply everywhere. Some areas of the product always show data across your entire environment, no matter which Zone you’ve selected. To control who can access those areas, use Teams and RBAC instead. This applies to:
    • Inventory: Kubernetes Live and Network Security.
    • Policies: Risk Definitions, Risk Exceptions, Runtime Policies, Vulnerability Policies.
    • Data Sources, Integrations, and Settings: Environments, cloud accounts, Sysdig Agents, third-party integrations, and Settings.

Team Zones (CA)

Team Zones are in Controlled Availability. Contact Sysdig Support to request access. This is an experimental feature and does not work for Threats.

Team Zones let you give each team a default view — the slice of your environment (accounts, regions, clusters, etc.) that the team sees first when they open Inventory, Posture, Registry, or Pipeline pages.

Team Zones do not control access. They don’t change what a team is allowed to see or do — that’s controlled by Teams and RBAC. Team Zones only change what’s shown by default, so each team can focus on the part of the estate that matters to them.

Team Zones are intended to eventually replace Team Scopes as the way teams filter their views. Unlike Team Scopes, a Zone only needs to be defined once and can then be reused across teams. Zones work for agentless cloud resources, as well as agent resources.

Enable Team Zones

Once Sysdig Support has granted you access to this feature, Admin users can enable Team Zones:

  1. Log in to Sysdig Secure as an Admin.

  2. Select Settings > User Profile.

  3. Under Sysdig Labs, enable Zones based team scoping and Zones scoping for all features.

  4. Click Save.

Zones based team scoping is now enabled.

Apply a Team Zone

To apply zones to teams:

  1. Log in to Sysdig Secure.

  2. Select Settings > Teams

  3. Select an existing team, or select Add team to create a new team.

The Team configuration page appears.

  1. Under Zones, select All Zones, or select one or more zones under Selected Zones.

If you do not select a zone, the scope will default to the configuration entered under Team Scopes.