dynatrace-oss / terraform-provider-dynatrace

Apache License 2.0
71 stars 33 forks source link

Dashboard (non classic) deployment - restrict user permissions to deploy at tenant level instead of account level #436

Open ftmazzone opened 7 months ago

ftmazzone commented 7 months ago

Is your feature request related to a problem? Please describe. It is now possible to deploy documents like dashboard using dynatrace_documents but I don't know how to allow a user to deploy documents to a single tenant as the OAuth client configuration is not done at tenant level but account level.
That means that a user that can deploy documents can deploy documents in any tenants. This is an issue for the security of the production tenants.

Describe the solution you'd like Deploy dashboards with an access token or oauth client having its scope limited to a specific environment of the account.

Describe alternatives you've considered Deploying the dashboard manually instead of using Terraform

Additional context

Using this resource requires an OAuth client to be configured within your account settings. The scopes of the OAuth Client need to include Create and edit documents (document:documents:write), View documents (document:documents:read), Delete documents (document:documents:delete).

Dynatrace-Reinhard-Pilz commented 7 months ago

Hello @ftmazzone,

When creating an OAuth Client you're also required to specify a "Service User" that's connected to that Client. In other words, the OAuth Client - in addition to the account wide permissions chosen for it - is also restricted by the permissions of its Service User. And permissions for users / user groups can get restricted to specific environments.

Here is an example how you can achieve that using Terraform. It's, of course, not really necessary to use Terraform for that. The WebUI offers the same functionality.

variable "environment" {
  default = "######"
}

resource "dynatrace_iam_group" "manage-documents-group" {
  name = "manage-documents-group"

  permissions {
    permission {
      name  = "tenant-viewer"
      type  = "tenant"
      scope = var.environment
    }
  }
}

resource "dynatrace_iam_policy" "manage-documents-policy" {
  name            = "manage-documents-policy"
  environment     = var.environment
  statement_query = <<EOT
ALLOW document:documents:write;
ALLOW document:documents:read;
ALLOW document:documents:delete;
EOT
}

resource "dynatrace_iam_policy_bindings_v2" "manage-documents-bindings" {
  group       = dynatrace_iam_group.manage-documents-group.id
  environment = var.environment
  policy {
    id = dynatrace_iam_policy.manage-documents-policy.id
  }
}
ftmazzone commented 7 months ago

Hello @Dynatrace-Reinhard-Pilz

Thanks. I will try this solution.

ftmazzone commented 7 months ago

Hello @Dynatrace-Reinhard-Pilz

I've checked the solution with the oauth client but it seems that a service user has a lot of account administrator permissions. "View and manage users and groups" is required for the oauth client.

You can designate any user on your account as a service user, but we recommend that you do not use the service user for any other purpose. The service user must belong to a group that provides account user management permissions.

This would mean that this user has a lot of permissions only to deploy a dashboard or notebook.

Dynatrace-Reinhard-Pilz commented 7 months ago

Hi @ftmazzone ,

The permissions you've found behind these links are required if your OAuth Client needs to get used for managing users, groups, etc. If you're just planning to manage documents, I doubt that this will be necessary. But I understand where your concerns are coming from.

Let me spend a few cycles on testing out what I believe SHOULD work as the minimum required permissions for documents. I will get back to you still this week about that.

ftmazzone commented 6 months ago

Hello @Dynatrace-Reinhard-Pilz

For information, I opened a case by Dynatrace to understand if it was possible to use a service account without the permission View and manage users and groups.

The advice from Dynatrace support is to :

Using this workaround, terraform apply worked successfully but I was not able to see the dashboard with my user and could not find a way to share or change the owner.

Did you have the opportunity to test and find another solution to deploy a dashboard ?

Dynatrace-Reinhard-Pilz commented 4 months ago

Hello @ftmazzone ,

Apologies for not getting back to you. I didn't notice your message and had to get pinged by our support team about the negligence.

Currently the REST API doesn't allow for explicitly setting the owner of a document - including 3rd gen Dashboards. As a result, any dashboards you're deploying via service user are automatically owned by that user. There's unfortunately no way around that at the moment.

What you can do, of course, is to share such a document with other users or user groups, like in this example.

resource "dynatrace_document" "this" {
  type    = "dashboard"
  name    = "TF_TEST_DASHBOARD"
  content = file(format("%s/example-dashboard.json", path.module))
}

resource "dynatrace_direct_shares" "this" {
  document_id = dynatrace_document.this.id
  access      = "read-write"

  recipients {
    recipient {
      id   = "31b5fa0f-ccd4-4359-8f43-af1155716d40"
      type = "group"
    }
    recipient {
      id   = "31b5fa0f-ccd4-4359-8f43-af1155716d40"
      type = "user"
    }
  }
}

We also have something in our backlog, that will allow Dashboards to be declared public (#448). Once that feature is implemented in Terraform you won't have to share documents explicitly.

Let me know if that helps, Reinhard

ftmazzone commented 4 months ago

Hello @Dynatrace-Reinhard-Pilz

thanks, I will try this solution.

Regarding the permissions, will it be possible to deploy a dashboard using the environment access key of a user instead of the oauth credentials ? Some users that will create dashboards don't have access to the oauth tokens.