Skip to main content

Secrets management

How to handle secrets within the Dynatrace platform​

Whenever Dynatrace Apps or functions need to access services outside the Dynatrace platform, secrets are likely required to authenticate these service interactions. Many services require the usage of API tokens, OAuth clients, or secrets within webhook URLs to authenticate their users.

Your app is never to contain these secrets, and there are several reasons for that:

  • Everybody with access to the app bundle or a function, for example, within Notebooks, can see the secret in clear text and misuse them.
  • Your app bundles that have secrets can't be easily updated. You must update the whole app if you want to exchange a secret.

To assist users with keeping secrets secure and easy to handle, Dynatrace offers the Credential Vault service and a corresponding SDK, which serves as storage for secrets, credentials, certificates, etc.

With the help of the SDK, you can easily retrieve your credentials in your app code like this:

import { credentialVaultClient } from '@dynatrace-sdk/client-classic-environment-v2';

const tokenCredentials = await credentialVaultClient.getCredentialsDetails({
  id: 'CREDENTIALS_VAULT-xxxxxxxxxxxxxxxx',
});
Tip

This operation requires the scope environment-api:credentials:read. Read more about scopes in this guide.

Tip

Currently, storing secrets isn't yet possible via the SDK. Open the Credential Vault app on your environment and add your credentials via the UI.

Ensure to use the AppEngine scope for your credentials.

Best practices to handle secrets​

Storage of secrets in the credential vault​

Storing secrets outside places specifically designed for that purpose is discouraged. For the Dynatrace platform, use the Credential Vault and don't hard-code credentials within apps, Dashboards, Notebooks, or similar.

Apply the principle of least privilege​

Each user, token, and OAuth client should only be assigned the minimum level of access required to perform their duties. As a result, your secrets' permissions will only be accessible when used in conjunction with the corresponding task they're to perform. By following this principle, you can reduce the potential impact if secrets ever leak.

Do not reuse secrets​

It would be best if you don't reuse secrets. We recommended creating a set of secrets for a single action, for example, in a single workflow, where you can change secrets easily. Without dependencies on multiple services, that might break by revoking a single certificate.

Rotate secrets​

Try to rotate any secret periodically. By doing this, you can ensure that people who had access to secrets in the past can't access the system after they change roles or leave the company.

Review and share secrets​

Try to review secrets and their sharing status periodically. Is a secret still in use, or can it be removed? Secrets that aren't stored anywhere can't be compromised. Ask yourself if all persons who can access a secret still require access. From a security point of view, less is more when it comes to sharing secrets.

Still have questions?
Find answers in the Dynatrace Community