Skip to content

Docs: service_account_application_key scopes example uses permission IDs #3819

Description

@lot-koichi

Datadog Terraform Provider Version

Latest documentation / provider v4.10.0.

I originally observed the apply failure with provider v3.91.0, and checked that the relevant implementation is still the same in v4.10.0.

Terraform Version

N/A for the documentation issue.

The observed apply failure was with Terraform v1.12.2.

What resources or data sources are affected?

  • datadog_service_account_application_key
  • datadog_permissions documentation as referenced from the resource example

Terraform Configuration Files

The current datadog_service_account_application_key documentation shows this example:

data "datadog_permissions" "dd_perms" {}

resource "datadog_service_account_application_key" "monitor_management_key" {
  service_account_id = "00000000-0000-1234-0000-000000000000"
  name               = "Monitor Management Service Account Key"
  scopes = [
    data.datadog_permissions.dd_perms.permissions.monitors_read,
    data.datadog_permissions.dd_perms.permissions.monitors_write
  ]
}

The datadog_permissions data source documentation says it returns permission IDs:

Map of permissions names to their corresponding ID.

When those permission IDs are passed as application key scopes, Datadog rejects the request with Invalid scopes.

Relevant debug or panic output

No panic. The Datadog API returns a validation error like:

400 Bad Request: {"errors":["Invalid scopes"]}

Expected Behavior

The datadog_service_account_application_key example should use scope names, not permission IDs, for example:

resource "datadog_service_account_application_key" "monitor_management_key" {
  service_account_id = "00000000-0000-1234-0000-000000000000"
  name               = "Monitor Management Service Account Key"
  scopes = [
    "monitors_read",
    "monitors_write",
  ]
}

Alternatively, if permission IDs are intended to be supported for this resource, the provider would need to translate permission IDs to authorization scope names before calling the Datadog API.

Actual Behavior

The documentation suggests using values from data.datadog_permissions, which are permission IDs intended for datadog_role.permission.id.

However, the provider implementation appears to pass scopes directly to the Datadog API:

  • datadog_service_account_application_key calls attributes.SetScopes(getScopesFromStateAttribute(state.Scopes)).
  • getScopesFromStateAttribute just returns the configured string values as []string; it does not translate permission IDs to scope names.

This matches the Datadog API documentation, where service account application key scopes are examples like "dashboards_read", "dashboards_write", and "dashboards_public_share".

The provider acceptance test also uses scope names:

scopes := []string{"dashboards_read", "dashboards_write"}

Steps to Reproduce

  1. Configure datadog_service_account_application_key.scopes using values returned by data.datadog_permissions, as shown in the current resource documentation.
  2. Run terraform apply.
  3. Datadog API rejects the application key create/update request with Invalid scopes.

Important Factoids

This appears to be a documentation issue rather than a provider runtime bug. The provider behavior is consistent with the Datadog API accepting authorization scope names.

References

Metadata

Metadata

Assignees

No one assigned

    Type

    Fields

    No fields configured for Bug.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions