Extension security

Dynatrace applies secure development controls in its Security Development Lifecycle (SDL).

The Extensions 2.0 framework is secure, but the security of your extensions also depends on how you develop them and manage them in your Dynatrace environment.

Follow these good practices to make your extensions as secure as possible.

Certificate management

The Extensions 2.0 framework uses an extension signing mechanism to ensure the integrity of extensions distributed in your environment. By uploading the root certificate to the host running extension, you verify your write access to the host. However, it's also your responsibility to keep certificates secure.

Use varied certificates

Group your extensions into categories and use different signing certificates for different extension types. For example:

  • For maximum security, each extension can be signed using a dedicated certificate.
  • Sign extensions monitoring sensitive data with dedicated certificates.
  • Root and developer certificates should be managed by different entities.

Replace leaked certificates

If your certificates leak

  1. Delete extensions signed with a leaked certificate.
  2. Delete the leaked certificate from the Dynatrce credential vault.
  3. Delete the leaked certificate from all hosts.
  4. Issue a new certificate and sign your extensions again.

Extension code

Code added to your extension YAML file (for example, SQL queries) carries a risk of system compromise if an attacker gains access to the Dynatrace environment. The following good practices can help you keep the extension code secure.

Ensure code integrity

Dynatrace Extensions 2.0 data sources are secure, but it's your responsibility to make sure the code you add to the extension YAML file is also secure.

You're responsible for the integrity and authenticity of the unsigned extension code you receive or download from the internet. When you sign code received from a third party, review the code for potentially malicious behavior or vulnerabilities.

Limit user permissions

Create dedicated users for your extensions (for example, database users) and give them limited permissions. An extension user should be able to access only the data required for your extension. Avoid using admin or super-privileged users to access data sources for your extensions.

Access control

Users with write access might be able to obtain a secret that is present in the extension configuration, even if it is masked in the web UI or REST API, by modifying certain parts of the monitoring configuration.

To secure secrets from unauthorized access, implement least privilege access control policies for extension configurations:

  • Make your users rely on personal tokens when managing the extension lifecycle using the API, rather than tenant tokens with global extension write permissions.
  • Create security policies with extension configuration write permissions and bind them to groups with a limited number of trusted users.
  • The Extensions IAM service provides you with conditions that can limit configuration write access to selected scopes, such as an extension, management zones, or host and ActiveGate groups. Use them to create fine-grained security policies.

For more information, see Access control.

Sensitive data sources

Some data sources make the extension perform actions that may be considered sensitive (for example, executing SQL queries). This may expose sensitive data from a monitored system. Review your extension to make sure it doesn't retrieve any sensitive information.