Migrate Env IAM → Account IAM + ABAC
IAM & ABAC: Account-Level Access Control
Gen2 managed users at the environment level. Gen3 moves everything to the Account Management Portal with Attribute-Based Access Control (ABAC).
What Changed
Gen2 (Environment-level) Gen3 (Account-level)
────────────────────────────────────── ──────────────────────────────────────
Users managed per environment Users managed at account level
Role-based (Admin, User, Viewer) Policy-based (ABAC)
Management zones for data filtering Policies with conditions for data access
API tokens per environment OAuth clients at account level
ABAC: Attribute-Based Access Control
ABAC policies can filter data based on attributes — much more powerful than role-based access:
// Example: Team can only see their own data
ALLOW storage:logs:read
WHERE storage:dt.security_context MATCH ("team-payments")
// Example: Restrict to a specific bucket
ALLOW storage:logs:read
WHERE storage:bucket == "prod_logs"
🛠 Try it: Open Account Management → Policies → Create policy → paste: ALLOW storage:logs:read WHERE storage:dt.security_context = "team-payments"; — this creates a policy that only lets the team see their own logs. Bind it to a group to see ABAC in action.
Account Management Portal
URL: myaccount.dynatrace.com (separate from your environment)
- Users & Groups — manage who has access
- Policies — define what they can do (with ABAC conditions)
- OAuth Clients — create API credentials
- Environments — provision and manage environments
Grail-Specific Permissions
Permission What It Grants
────────────────────────────────── ──────────────────────────────
storage:logs:read Query log records
storage:metrics:read Query metric data
storage:events:read Query events and problems
storage:spans:read Query distributed traces
storage:entities:read Query entity data
storage:bizevents:read Query business events
storage:buckets:read List and query buckets
storage:smartscape:read Read Smartscape topology
storage:security.events:read Query security events
💡 In Gen3, data access is permission-based, not zone-based. A user with storage:logs:read can see ALL logs unless you add ABAC conditions to restrict by attribute.
Migration: Gen2 Roles → Gen3 Policies
Gen2 Role Gen3 Policy
────────────────────────────────────── ──────────────────────────────────────
Admin (full access) ALLOW all storage:*:read/write
User (read + some write) ALLOW storage:*:read + specific writes
Viewer (read only) ALLOW storage:*:read
MZ-restricted user ALLOW storage:*:read
WHERE storage:dt.security_context MATCH ("team-x")
Policy Boundaries (Multi-Team Isolation)
Boundaries limit what a policy CAN grant — even if the policy says ALLOW, the boundary restricts it:
// Boundary: team can only see their own data
ALLOW storage:logs:read, storage:metrics:read, storage:events:read
WHERE storage:dt.security_context MATCH ("team-payments")
💡 Use boundaries for hard isolation between teams. Policies grant access, boundaries cap it. A team admin can create any policy they want, but the boundary ensures they can never see another team's data.
Migration Steps
Step Action Validates
──── ────────────────────────────────────── ──────────────────────────
1 Inventory Gen2 users, roles, MZs Who has access to what?
2 Design group structure 1 group per team per env
3 Create policies (ALLOW statements) Map Gen2 roles to scopes
4 Create boundaries (WHERE clauses) Map Gen2 MZs to ABAC conditions
5 Bind policies to groups with boundaries Use dynatrace_iam_policy_bindings_v2
6 Test with a pilot team Verify data isolation works
7 Migrate remaining teams Roll out group by group
⚠️ Always use dynatrace_iam_policy_bindings_v2 in Terraform — v1 has NO boundary support. And dynatrace_iam_user with groups does a PUT that replaces ALL groups.
Default Policies (Latest Dynatrace)
Dynatrace provides pre-built policies that auto-update with platform changes:
Access Tier What It Grants
─────────────── ──────────────────────────────────────────────────
Admin User Administrative access across all Platform Services
Pro User Build, deploy, run Apps + Workflows + key services
Standard User Access environment + run Dynatrace Apps
Data policies (bind with boundaries for scoped access):
Read Logs, Read Metrics, Read Spans, Read Events, Read Entities,
Read BizEvents, Read Security Events, Read Sensitive Data,
All Grail data read access, Data Processing and Storage
Best practice: use default policies + boundaries instead of custom policies where possible.
Platform Tokens
Long-lived tokens for programmatic API access — simpler alternative to OAuth:
- Created per-user or per-service-user
- Scoped to the creating user's permissions
- Can expire after set period or never expire
- Use:
Authorization: Bearer <platformtoken> - Manage via: Settings → Access tokens → Platform tokens