Management of synthetic monitors using the credential vault is now easier than ever

The credential vault is a central place to securely store and manage vulnerable data that you use with Dynatrace Synthetic Monitoring. We've made it easier to manage credentials and the monitors that use them, and introduced token credentials and more granular API access to the vault.

The credential vault is an invaluable enhancement to Dynatrace Synthetic Monitoring, especially as more and more websites, applications, and API endpoints are protected with authentication/authorization solutions. In the case where authentication/authorization needs to be provided to access your web services to monitor their performance and availability with Dynatrace Synthetic Monitoring, the credential vault keeps vulnerable data completely secure. Moreover, with the centralization of credential storage and the ability to reference credentials from various synthetic monitors, you can easily maintain and reuse your saved credentials.

We recommend using dedicated test credentials for synthetic monitoring (ideally, with a minimal set of privileges required for executing synthetic monitors), instead of running synthetic monitors with credentials that are also used by real users.

We’ve heard your feedback, and we’re taking action

We’ve heard your feedback during the last few months. The limitations regarding who could modify synthetic monitors using “private” credentials (marked Owner access only) were too strict. Dynatrace administrators needed access to all synthetic monitors, including monitors that utilize private credentials, to maintain monitoring continuity. Administrators could accept certain limitations, but needed the ability to change parameters that weren’t directly related to credentials or secured URLs.

So we decided to make it easier for administrators to manage monitors and credentials in several ways—read on below.

Easier administration of synthetic monitors

Your “owner access” credentials are available only to you

The latest improvements to the credential vault ease restrictions in many ways while following the original security principles. No one but the credential owner is allowed to create new monitors utilizing Owner access only credentials. And a credential designated as Owner access only can be used only to request those URLs and in those clickpath actions defined when the credential owner created or later edited a monitor. That means that no one but the credential owner can edit the request URLs and HTTP methods in an existing HTTP monitor secured by a private credential. Likewise, access to pre-execution scripts is also blocked. This is in effect whether a user without access to such credentials uses the Dynatrace web UI or the Dynatrace API.

Administrators have greater, but still limited, access to monitors secured with private credentials

Administrators can now make many modifications to monitors associated with owner-access credentials. Changes not related directly to requested URLs or actions performed on the website are allowed, as such changes don’t pose a security risk to the credentials. Dynatrace administrators can now change the following aspects of synthetic monitors (among others):

• Monitor name
• Execution frequency
• Locations from which a monitor is executed
• Parameters controlling response codes or response-body validation
• Performance thresholds

Overwrite and take ownership of a credential (with an important limitation)

Imagine the owner of a private credential is unavailable and the monitors they created require some complex changes. Assuming that other team members have the required access levels, you might create a new entry in the credential vault and use that to replace the credential set in the monitors (or recreate the monitors). This is a reasonable option that works fine for, say, up to five monitors. But what if there are dozens of monitors using a private credential? You can now use the option to overwrite credentials in the vault and thereby update all the monitors that reference those credentials.

Every entry in the credential vault, including credentials that are Owner access only, may be overwritten. There’s an important limitation however: in order to overwrite a credential, you must provide the full set of authentication details. This means that, depending on the credential type, you can only overwrite a credential (and take ownership) by providing a new username and password set, a new certificate, or a new token.

Note that stored credentials are only available to the synthetic monitors that reference them. You can’t view the usernames and passwords that are stored in a credential set, even ones that you’ve created. This is also true when using the GET method in the Credential vault API to retrieve all details necessary to use a credential in your monitor.

Other improvements to the credential vault

Besides the expanded ability of Dynatrace administrators to edit some aspects of monitors with private credentials, we’ve introduced several improvements to credentials in synthetic monitors recently.

Synthetic browser monitors now support the credential vault

Credentials stored in the vault can now be used in HTTP monitors as well as browser monitors. This means that you can use credential vault entries to run synthetic browser monitors against your own websites that have been protected with credentials.

New credential type—tokens

The credential vault now supports authorization with tokens in addition to username/password- and certificate-based authentication.

Adjust HTTP requests to your needs by using credential vault entries

In addition to values from the credential vault being usable for authentication purposes, they can also be included as parameters in the URL, HTTP header, or Request body fields of HTTP monitors.

Better granularity and more control over access to the credential vault

We now have more granular and separate privileges for adding and maintaining synthetic monitors and credentials vault entries via the Dynatrace API. When creating a new Dynatrace API token, you can now separate read and write access to the credential vault. The new API token scopes limit access to the credential vault, so you don’t need to grant permission to other areas of environment configuration.

What’s next

We hope that you find these changes to be useful and a valuable solution to the synthetic monitoring challenges that you’ve shared with us.

Beyond the credential vault, here are upcoming Synthetic Monitoring improvements:

• Executing HTTP monitors from all available public locations
• Support for Synthetic-enabled ActiveGates on new OS versions
• Better support for NTLM, Digest, and Negotiate authentication for browser monitors

As always, we want to hear about your questions and needs. So please reach out to us at Dynatrace Community.