Account configuration for Monaco account management

To define the accounts for which Monaco will configure the account management resources, you need to create an accounts section in a manifest file.

In the following example, we define a single account object containing account-related information. The name property specifies the account name (in this example, my-account) that can be referenced using the Monaco CLI commands --account flag.

accounts:
  - name: my-account
    accountUUID: 12345678-1234-5678-1234-123456789012
    oAuth:
      clientId:
        name: OAUTH_CLIENT_ID
      clientSecret:
        name: OAUTH_CLIENT_SECRET

Other than the accounts section, a manifest.yaml defined for account resources is the same as for environment configurations, requiring projects of account resource configuration files.

Account resources

Using Monaco, you can define users, groups, and policies as dedicated types in YAML configuration files.

Unlike the usual environment-level configurations, no JSON template files are needed. Monaco builds the required API data directly from your YAML configuration.

Example account management resources representation

This example shows how Monaco represents account management resources locally, with examples defining users, groups, and policies.

The following sections will describe each configuration in detail.

users:
- email: monaco@dynatrace.com
  groups:
  - Log viewer
  - type: reference
    id: my-group

groups:
- name: My Group
  id: my-group
  description: This is my group
  account:
    permissions:
    - account-viewer
    policies:
    - Environment role - Access environment

  environment:
  - name: vkb66581
    permissions:
    - tenant-viewer
    policies:
    - Environment role - Replay session data without masking
    - type: reference
      id: my-policy

  managementZone:
  - environment: wbm16058
    managementZone: Management Zone 2000
    permissions:
    - tenant-viewer

policies:
- name: My Policy
  id: my-policy
  level:
    type: account
  description: abcde
  policy: |-
    ALLOW automation:workflows:read;

While this sample shows users, policies, and groups defined in a single file, you can define them in individual files and structure your account resource projects and files as needed.

Users

users:
- email: monaco@dynatrace.com
  groups:
  - Log viewer
  - type: reference
    id: my-group

In this example, we define these objects.

users define one or more users bound to different groups.
- email address
- groups specifies the groups to which the user belongs. In the example, the user belongs to the default Log viewer group.
  - type
  - id specifies a custom group, for example, my-group. This id must match a group defined under the groups field.

Groups

groups:
- name: My Group
  id: my-group
  description: This is my group
  account:
    permissions:
    - account-viewer
    policies:
    - Environment role - Access environment

  environment:
  - name: vkb66581
    permissions:
    - tenant-viewer
    policies:
    - Environment role - Replay session data without masking
    - type: reference
      id: my-policy

  managementZone:
  - environment: wbm16058
    managementZone: Management Zone 2000
    permissions:
    - tenant-viewer

In this example, we define these objects.

groups defines one or more groups that are bound to different policies or permissions.
- name
- id
- description
- account specifies permissions and policies to which the group is bound on the account level.
environment specifies the permissions and policies to which the group is bound on the environment/tenant level.
- name
- permissions
- policies can be referenced by their name if a default policy is available.
  - id references a custom policy. The id must match a policy defined in the policies.
managementZone
- environment
- managementZone contains, for example, permissions on the Management Zone 2000 level.
- permissions

Policies

policies:
- name: My Policy
  id: my-policy
  level:
    type: account
  description: abcde
  policy: |-
    ALLOW automation:workflows:read;

In this example, we define these objects.

policies defines one or more policies.
- name
- id
- level
  - type
- description
- policy contains any policy rules of this particular policy.

Commands

Because account-level configuration is usually distinct from environment-level configuration and changes less frequently, existing commands like monaco deploy ignore any account configuration that may be defined in a manifest file.

Dedicated commands exist for account resources: Dynatrace Monaco CLI command reference