Skip to content

Team-Based Deployment Solutions

This page contains reference solutions for the exercises in the Team-Based Deployment Guide. Try to complete the exercises on your own first, then refer here if you get stuck.

Add a New Team

Add a "security" team with their own clusters and access.

1. Create cluster labels

Create a new file team-based-labels-security-prod.yaml:

YAML
1
2
3
4
5
discovery:
  labels:
    team: "security"
    environment: "production"
    role: "recursor"

2. Add security team dashboard

Add to your dashboard configuration:

YAML
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
security-overview:
  title: "Security Team Overview"
  url: /team/security
  icon: pi-shield
  requires:
    - "dashboard_security_overview"
  graphs:
    - widget: "cc-state-tree-table"
      args:
        filter: 'team = "security"'

3. Add navigation menu

Add to your navigation configuration:

YAML
1
2
3
4
5
6
7
8
9
menus:
  - name: "Security Team"
    icon: pi-shield
    sections:
      - name: "Dashboards"
        items:
          - name: "Team Overview"
            url: "/team/security"
            description: "All Security team clusters"

4. Add REGO policies

Add to pdns_global_flags.rego:

Rego
1
2
dashboard_security_overview if "security" in input.user.roles
dashboard_security_overview if "admin" in input.user.roles

5. Add security team user

Add to static users configuration:

YAML
1
2
3
4
5
6
7
8
9
policy:
  staticUsers:
    - username: "security-lead"
      password: "security123"
      roles:
        - "security"
        - "production"
        - "operator"
        - "observer"

Change Dashboard Filters

Examples of different filter expressions:

Show only recursors across all teams

YAML
1
filter: 'role = "recursor"'

Show production clusters from multiple teams

YAML
1
filter: 'environment = "production" and team in ("devops", "platform")'

Exclude development environments

YAML
1
filter: 'team = "devops" and environment != "development"'

Add a Cross-Team Dashboard

Create a dashboard visible to multiple teams for shared infrastructure.

Dashboard configuration

YAML
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
shared-dns-infrastructure:
  title: "Shared DNS Infrastructure"
  url: /shared/dns
  icon: pi-globe
  requires:
    - "dashboard_shared_infrastructure"
  graphs:
    - widget: "cc-state-tree-table"
      args:
        filter: 'role = "authoritative"'
        title: "All Authoritative Servers"

REGO policy for cross-team access

Rego
1
2
dashboard_shared_infrastructure if "devops" in input.user.roles
dashboard_shared_infrastructure if "platform" in input.user.roles

Restrict Operator Access by Environment

Modify REGO policy to only allow operator actions in non-production.

Updated can_manage_instances rules

Rego
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# Non-production: standard operator role is sufficient
can_manage_instances if {
  can_see_cluster
  operator
  input.cluster.labels.environment != "production"
}

# Production: requires additional "production-operator" role
can_manage_instances if {
  can_see_cluster
  operator
  input.cluster.labels.environment == "production"
  "production-operator" in input.user.roles
}

This ensures that users must have both operator AND production-operator roles to perform operations like restarting instances in production environments.

Add a New User Role

Create a "read-only admin" that can see all clusters but cannot perform operations.

Static user configuration

YAML
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# Add to staticUsers
- username: "readonly-admin"
  password: "readonly123"
  roles:
    - "devops"
    - "platform"
    - "production"
    - "staging"
    - "development"
    - "observer"
    # Note: no "operator" role - can only observe

This user can:

  • View all team dashboards (has both devops and platform roles)
  • Read logs from any cluster (has observer role)
  • Access all environments (has production, staging, development roles)

But cannot:

  • Restart instances (no operator role)
  • Clear cache (no content-manager role)
  • Delete pods (no operator role)