Scope and management of auth tokens with ID dt0a01.<tenantUUID>

[Enrico_F]

When setting up monitoring for cloud functions (AWS Lambda, Azure, and Google) through the UI a special "AuthToken" with an ID like dt0a01.<tenantUUID> is provided in the JSON/env-vars snippets, e.g.

This token cannot be found anywhere in our environment and therefore I wonder:

1. What are its scope and permissions?
2. Who is its owner?
3. How can it be managed (deleted, updated, rotated etc.)?

The token appears to be static - at least within the context of my user session i.e. it's not generated every time I access one of the different OA install wizards.

I couldn't find any documentation about these tokens either - they just magically appear in the UI...

Would be great if anyone could shed some light here....

[RazTN7]

Hello @Enrico_F 

1. What are its scope and permissions?

     -> The permission it has is to ingest data from monitored AWS lamda, Azure, GCP functions (and similar) into an endpoint on the Dynatrace ActiveGate. This permission is not the similar type of permission which is shown in API token/Access token screen.

If you notice closely Access token prefix starts with dt0c01 and Auth token dt0a01. This token can't be view in Rest API.

     2. Who is its owner?

     -> Maybe admin or person who has access to deploy agent. Its one-time token generation.

As an admin I used to maintain this Auth token separately.

     3. How can it be managed (deleted, updated, rotated etc.)

      -> With little info I have, the rotation mechanism is heavyweight and meant primarily for emergencies like accidental leaks. Ref - https://docs.dynatrace.com/docs/shortlink/tenant-token#rotate-tenant-token

Yup its magical. No document available.

Thanks,

RN

[Enrico_F]

Hi @RazTN7 

Thanks for responding!

In the meantime I also got feedback from support:

it's an access token that authenticates OneAgent data being sent back to Dynatrace. This token is not owned by anyone, it's a single shared token across all OneAgents and ActiveGates to recognize each other as a part of this environment. This token is derived from the "tenant token", which is a different string, of which this longer token that is shown on the GCP functions deployment page is derived from.

 It's permissions are separate from the API because technically, this is NOT an API token. This is a different token used for the cluster's authentication, not for API. It can be rotated by using the tenant token API

---

The question is: Why does this AuthToken have to be any different than the tenant token itself if it is "derived" from it and seems to serve exactly the same purpose? After all, this is what got me confused initially and why I started to dig deeper...

I also wonder, what remote URL is used to ingest this data if it's not any of the well-known API ingestion endpoints such as <BaseURL>/api/v2/otlp/v1/*? Is it the regular (proprietary) /communication endpoint that is used instead?

[Enrico_F]

To answer my own question about the remote ingestion URL:

For OTL spans it appears to be <BaseURL>/odin/v1/traces as per the code of the Python package dynatrace-opentelemetry-core which is imported as a dependency of dynatrace-opentelemetry-gcf.

And the AuthToken is passed via header:

"Authorization: Dynatrace dt0a01.<tenantUUID>.****************************************************"

Here we can see that the token scheme is "Dynatrace" and not the usual "Api-Token" as used with regular API access tokens...