cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

API Tokens for integrations

Julius_Loman
DynaMight Legend
DynaMight Legend

Hi all,

Dynatrace API requires API tokens for access and it is always bound to specific Dynatrace user. Users may leave the organization and API tokens should be revoked

I wonder how others are managing technical accounts? I mean API tokens for connecting 3rd party systems that require API token. So that integrations won't break after someone leaves the organization and his/her account is deleted including tokens.

I can think of creating the API tokens as cluster admin user (Managed only) or create a "technical user account" that will be used solely for the purpose of token management. It is possible to create tokens using API, however, the token for API token management must be bound to a user and so will the newly created tokens.

Just wanted to know your practices to avoid any future pitfalls.

Certified Dynatrace Master | Alanata a.s., Slovakia, Dynatrace Master Partner
8 REPLIES 8

Radoslaw_Szulgo
Dynatrace Guru
Dynatrace Guru

Julius, we are working on automatic revoking tokens for users no longer existing in Dynatrace - this would work when using Internal user repository or LDAP (as cluster can query LDAP if user exists). When using SSO it's not that easy.

Anyway, there's REST API for managing users - if you automate that, when a user leaves a company, then you call a REST to cluster, then cluster itself automatically revokes tokens.

What do you think?

Senior Product Manager,
Dynatrace Managed expert

This can be automated already and it's not really what I'm trying to solve. But automatic token revocation will be appreciated.

I'm asking how others are managing the API tokens for integrations. Integration should not bound to a user account or person. Just an example: API token for pushing external events or annotations from a 3rd party system. At the moment you have to create an API token and it will be bound to the user account who created this token of course. If the user gets disabled and with proper security revoking all his/her tokens, the integration will stop working without someone even noticing.

Traditionally this is solved by "technical user accounts" that are solely used for such purpose.

I'm just asking how others are solving this situation and what is their practice. The only solution I can think of would be to create such technical user account in Dynatrace and create all integration tokens with this account.

Certified Dynatrace Master | Alanata a.s., Slovakia, Dynatrace Master Partner

In Managed - we are using embedded "admin" account.

Senior Product Manager,
Dynatrace Managed expert

Yes, exactly this was in my first post. Any ideas for SaaS?

A "dedicated" user account (not person related) will be always a solution. Just trying to find out if someone did not come with something more sophisticated.

Certified Dynatrace Master | Alanata a.s., Slovakia, Dynatrace Master Partner

We (Dynatrace Admins) are creating API tokens for other teams to use, usually for reading metrics are sending in custom metrics.

The problem is the API tokens are always owned by the person that created the token, not the team that is using it. Therefore, deleting the token when a Dynatrace Admin leaves does not make sense.

We cannot sign on with local admin to create tokens because we have integrated with SSO.

An option in the API to update the owner is needed. (Note, this will almost never be the actual user of the token, but rather the person that created it.) It looks like you can only update the token name in the API. Any admin to view and update any token, this is a big limitation in the UI.

So the situation we are in now is that one of our admins is no longer with the team and all of the tokens he created cannot be updated at all.

jshuff
Newcomer

Internally we typically handle such needs using special "Service Accounts" which are never tied directly to an individual.  We integrate DT with the SCIM -to- Azure AD solution but since these "Service Accounts" are not real people we can't sync them.

 

With SaaS it's best practice to create an account that is NOT in your domain so that if SSO fails you can still backdoor into the SaaS tenant.   We have a special Gmail account created for this that is owned by the department and not really any one individual.   Our Production APIs are generated using this account.

 

This way when I leave the company the APIs aren't all locked to my SSO account.  And if DT is thinking of auto-locking when a person leaves (which is a good thing and I promote it) then it's even better that these APIs are not under by SSO account, rather connected to this shared gmail account.

ct_27
DynaMight Pro
DynaMight Pro

Internally we typically handle such needs using special "Service Accounts" which are never tied directly to an individual.  We integrate DT with the SCIM -to- Azure AD solution but since these "Service Accounts" are not real people we can't sync them.

 

With SaaS it's best practice to create an account that is NOT in your domain so that if SSO fails you can still backdoor into the SaaS tenant.   We have a special Gmail account created for this that is owned by the department and not really any one individual.   Our Production APIs are generated using this account.

 

This way when I leave the company the APIs aren't all locked to my SSO account.  And if DT is thinking of auto-locking when a person leaves (which is a good thing and I promote it) then it's even better that these APIs are not under by SSO account, rather connected to this shared gmail account.

HigherEd

ct_27
DynaMight Pro
DynaMight Pro

I'm reviving this. @Julius_Loman replied to another post of mine (https://community.dynatrace.com/t5/Dynatrace-API/Change-Access-Token-Owner/m-p/211947 ) in which I'm having similar issues, nearly 3 years later.

I'm going through the process to create a token for a "technical account" so that when I and/or the person this account is for leaves the company there is no impact.  Long ago, nearly lost to history, my DSP1 would create Tokens for me and if i recall correctly they could assign it to my account.  DT ignored this when they replaced the technology and sure enough 3 years later I think we all forgot what we used to have.

Well, I'm back. And I need a way to create a Token for a "Technical Account" that should actually have absolutely no access to the Dynatrace UI (SaaS or Managed). I will grant it an API token with the ability to ingest logs and metrics but that's it.

Doesn't look I can do this still. 

Workaround #1: Turn on Personal Access Tokens, login to DT as this account that should really never be able to login to DT, have it create a Personal Access Token with the correct API roles, then I as an Admin login to DT and change the accounts permissions as necessary.   Problem, the account must still have Monitoring Viewer access to tenant which means it can still login if compromised.

 

Workaround #2: I keep Personal Access Tokens off, I then create an API token for the the Technical Account that lets it create an API Token, it creates its own API Toke,  I go back in as an Admin and destroy the API token that let the Technical Account create an API Token.  Should i ever have to maintain or modify I'll have to re-do the process.

 

This is an administrative nightmare.

HigherEd

Featured Posts