Management Zones → Segments

Management Zones → Segments

Management zones were Gen2's way to partition data by team, application, or environment. Gen3 replaces them with Segments — more flexible, DQL-powered, and integrated with the new IAM model.

Key Differences

GEN2 Management Zones                   GEN3 Segments
──────────────────────────────────────  ──────────────────────────────────────
Entity-based rules                      DQL filter expressions
Applied to dashboards, alerts, etc.     Applied as filter in any DQL query
Limited to entity types                 Can filter on any field
One zone per entity (primary)           Multiple segments can overlap
Configured in Settings                  Configured via Segments app or API
Used in IAM for data access             ABAC policies replace MZ-based access

Migration Example

// GEN2: Management Zone "Production"
// Rule: Host tag = "env:production"
// Rule: Service tag = "env:production"

// GEN3: Segment "Production"
// Filter: matchesValue(dt.tags, "env:production")

Classic IAM → Account IAM + ABAC

Gen2 IAM was environment-level: users got roles per environment, scoped by management zones. Gen3 moves IAM to the account level with ABAC (Attribute-Based Access Control).

GEN2 IAM                                GEN3 IAM
──────────────────────────────────────  ──────────────────────────────────────
Environment-level users                 Account-level users
Roles: Viewer, Operator, Admin          Policies: fine-grained permissions
Management zone scoping                 ABAC with dt.security_context
API tokens (per environment)            OAuth clients (account-level)
No cross-environment access control     Unified access across environments

ABAC Policy Example

// Allow read access to logs where cost center matches user's team
ALLOW storage:logs:read
WHERE storage:dt.security_context == "team-payments"

OAuth vs API Tokens

GEN2 API Tokens                         GEN3 OAuth Clients
──────────────────────────────────────  ──────────────────────────────────────
Created per environment                 Created at account level
Never expire (unless configured)        Tokens expire in 300 seconds
Scope: fixed list of permissions        Scope: fine-grained, space-separated
Used for all API calls                  Used for platform APIs
Format: dt0c01.XXXXXXXX                 Format: dt0s02.XXXXXXXX (client ID)
                                        + client secret
                                        + resource: urn:dtaccount:UUID

Gen3 still supports API tokens for backward compatibility, but OAuth is the recommended approach for all new integrations.