Dynatrace API tokens, when granted excessive permissions, become a significant security liability, allowing attackers to read sensitive environment data or even manipulate configurations.
Let’s see this in action. Imagine you need to fetch metrics for a specific service, my-cool-app, within your production environment. Without a properly scoped token, a compromised token could reveal metrics for all services across all your environments.
Here’s how you’d typically interact with the Dynatrace API to get metrics for my-cool-app using curl, assuming you have a token.
curl -X GET "https://{your-environment-id}.live.dynatrace.com/api/v2/metrics/data?metricSelector=builtin:service.requestCount.server&from=$(date -d '1 hour ago' +%s%3)000&to=$(date +%s%3)000&entitySelector=environmentId('YOUR_ENV_ID'),serviceId('my-cool-app')" \
-H "Authorization: Api-Token {your-api-token}" \
-H "Content-Type: application/json"
Notice the {your-api-token}. If this token has broad permissions, like "Read environment" or "Write configuration," it’s a ticking time bomb.
The core problem Dynatrace API tokens solve is enabling programmatic access to your Dynatrace data and functionality without exposing your primary user credentials. This is crucial for automation, integration with other tools (CI/CD pipelines, incident management systems), and custom reporting.
Internally, Dynatrace uses these tokens to authenticate and authorize requests. Each token is associated with a specific set of permissions, defining what actions the token holder can perform and on which resources. The default, and most dangerous, is a token with full administrative rights.
The key levers you control are:
- Token Scopes: These are the granular permissions you assign. You can grant read-only access to specific entities, write access to certain configurations, or even permissions to manage other API tokens.
- Token Expiration: You can set an expiration date for tokens, forcing regular rotation and limiting the window of exposure if a token is compromised.
- Token Name and Description: Use these to clearly identify the purpose of the token and the system or user that owns it, aiding in auditing and revocation.
When creating or managing API tokens in the Dynatrace UI (Settings -> API tokens), you’ll see a list of available scopes. Instead of blindly checking Read environment or Write configuration, you need to be specific.
For our my-cool-app metric retrieval example, the minimal scope would be metrics.get. If you need to filter by specific entities, you might also need entities.get. So, a token for this specific task would only have metrics.get and potentially entities.get. It would not have settings.write, topology.read, or any other broad permissions.
The most surprising part about Dynatrace API token scopes is that the UI often defaults to a very permissive set, and it’s easy to just click through and create a token that has far more power than necessary for its intended use. The system is designed to be flexible, but this flexibility requires careful management on the user’s part. You’re not just granting access; you’re defining a tiny, autonomous agent operating within your Dynatrace tenant, and its permissions dictate its potential impact.
The next logical step after securing your API tokens is understanding how to use them within a CI/CD pipeline for automated deployments and testing.