Use a private registry

For users seeking greater control over their image hosting environment, Dynatrace offers the option to replicate images and signatures to private registries.

We recommend using a private registry for optimal performance and no rate limiting risks in high-demand and dynamic environments. Furthermore, to meet security standards and ensure software integrity while mitigating supply chain risks, image scanning and signature verification against Dynatrace images can be applied and is recommended.

By replicating Dynatrace images to your private registry, you can seamlessly merge excellent delivery performance with the assurance of secure, signed, and immutable images. Additionally, we provide multi-arch images to ensure compatibility across various platforms supporting ARM64 (AArch64) and x86-64 CPU architectures on Linux.

This page provides instructions for using Dynatrace signed and immutable container images hosted on a private registry.

Prerequisites

Before you begin, be sure to meet the following prerequisites:

  • required Dynatrace Operator version is v0.11 or later
  • required Target CPU architectures are ARM64 (AArch64) and/or x86-64
  • required Allow egress traffic to public registry
  • required Private registry with Dynatrace images stored

For guidance on storing Dynatrace images in your private registry, see Store Dynatrace images in private registries.

Create a pull secret

When Dynatrace container images are served by a private registry requiring authentication, a pull secret is required if any of the following conditions apply:

Dynatrace Operator versions 0.14 and 0.15 include logic to ensure a proper and functional rollout of monitoring components, which makes configuration of a pull secret mandatory for all observability options (monitoring modes).

Since Dynatrace Operator version 0.14.0, customPullSecret field is mandatory when using a private registry that requires authentication.

The pull secret (the customPullSecret field in a DynaKube configuration) is generally used for authenticating against the private registry and accessing its artifacts (images). The following points describe the requirements for a pull secret in more detail:

  • When Cloud-Native Full-Stack or Application-Only monitoring with the CSI driver is configured, the CSI driver requires a pull secret to access the private registry as it attempts to directly download the Dynatrace Code Modules image from the private registry.

To create a pull secret, follow this Kubernetes documentation on how to create a Kubernetes secret based on existing credentials or by providing credentials on the command line.

Deploy Dynatrace Operator with images from private registry

This section guides you through deploying Dynatrace Operator with its container image coming from a private registry.

Dynatrace Operator consists of multiple components (operator, webhook, CSI driver), all of which use the same dynatrace-operator image with specific deployment configurations per component.

Configure DynaKube to use images from private registry

To instruct Dynatrace Operator to use container images from a private registry, just configure a pull secret via the customPullSecret field for registry authentification and respective image fields in the DynaKube custom resource. The configured images will be deployed to your Kubernetes cluster to set up monitoring components.

The following DynaKube snippet demonstrates how to configure Cloud-Native Full-Stack monitoring setup using Dynatrace container images from a private registry.

apiVersion: dynatrace.com/v1beta2
kind: DynaKube
metadata:
  name: dynakube
  namespace: dynatrace
spec:
  ...
  customPullSecret: <secretName>


  oneAgent:
    cloudNativeFullstack:
      ...
      image: <your-private-registry>/dynatrace-oneagent:<tag>
      codeModulesImage: <your-private-registry>/dynatrace-codemodules:<tag>
      # autoUpdate: true # no effect - see note below
      # version:         # no effect - see note below
      ...


  activeGate:
    ...
    image: <your-private-registry>/dynatrace-activegate:<tag>
    ...

Note that the autoUpdate and version fields have no effect when the image and/or codeModulesImage fields are set.

After configuring the required fields, the DynaKube custom resource must be applied to the Kubernetes cluster.

For additional information regarding customPullSecret field, image fields, or the DynaKube custom resource, see further examples below or go to the DynaKube parameters for Dynatrace Operator reference page.

Application and Kubernetes Observability

The following custom resource snippet describes how to configure DynaKube for Application Observability and and Kubernetes observability with container images from your private registry:

apiVersion: dynatrace.com/v1beta2
kind: DynaKube
metadata:
  name: dynakube
  namespace: dynatrace
spec:
  ...
  customPullSecret: <secretName>


  oneAgent:
    applicationMonitoring:
      ...
      codeModulesImage: <your-private-registry>/dynatrace-codemodules:<tag>
      # autoUpdate: true # has no effect
      # version:         # has no effect


      useCSIDriver: true # required; defaults to false
      ...


  activeGate:
    ...
    image: <your-private-registry>/dynatrace-activegate:<tag>
    ...

Verify image signature

All of our immutable and signed container images adhere to best practices, enhancing security and shielding against supply chain attacks. To learn how to verify signatures and guarantee software integrity, see Verify Dynatrace image signatures.

Related topics