Sharing Secrets with Your Customers

1

Sharing Secrets with Your Customers

Many Helm charts require specific secrets before installation begins. Replicated eliminates the most common scenario—creating a secret so customers can access your private registry. That’s exactly what the Replicated Proxy Registry is for.

But other scenarios demand this pattern:

  • Control plane/data plane deployments where customers deploy the data plane in their environment and need pre-configured credentials to access your control plane.

  • Third-party service integrations where your application connects to external APIs or databases requiring customer-specific credentials that you control: database connection strings, OAuth client secrets that vary per customer, etc.

  • Certificate-based authentication where each customer deployment needs unique TLS certificates or signing keys for secure service-to-service communication.

Someone asked me about this recently, and I initially felt stumped. My brain got too literal too quickly: there’s no way to include customer-specific assets in a Replicated release. How could we solve this?

License Fields to the Rescue

While you can’t include customer-specific assets in a release, Replicated already provides one inherently customer-specific asset: the customer’s license. Every license is unique, included in the Embedded Cluster Download, viewable in the Enterprise Portal, and automatically injected as Helm values when customers access your chart. The license expiration date and any custom fields you add become global values available to your chart and all sub-charts.

There was my answer. Custom license fields perfectly incorporate customer-specific secrets into your release. You create the secret in your Helm chart and use those global values to populate the customer-specific details during installation and updates.

An Example

Imagine deploying a data plane on-premise that connects to your control plane through an API authenticated with an API key. Here’s how you’d configure your license:

license-field-setup
license-field-setup1351×939 63.3 KB

Then assign an API key to your customer:

assigning-an-api-key
assigning-an-api-key650×232 15.5 KB

Using the API Key in Your Helm Chart

When Replicated processes your Helm chart, it automatically injects license information as global values. Custom fields become available under .Values.global.replicated.licenseFields, appearing with both their value and metadata for straightforward template references.

apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-api-key
  labels:
    app: data-plane
type: Opaque
stringData:
{{ with .Values.global.replicated }}
{{ with .licenseFields }}
  apiKey: '{{ .api_key.value }}'
{{ end }}
{{ end }}

This template creates a Kubernetes secret containing the customer’s unique API key. The nested with statements provide clean error handling—if license fields aren’t available, the template won’t fail with undefined variable errors. The .api_key.value notation accesses the actual value assigned to that customer, matching the field name (api_key) you defined in the license configuration.

The timing makes this approach particularly elegant. The secret gets created during chart installation using the customer’s specific license data, eliminating any separate credential management steps. Customers install your application, and the necessary credentials automatically become available for your services. You can even rotate the credentials by updating the license.

Applying this Pattern in Embedded Cluster

You can apply this same pattern in Embedded Cluster installations. These installs don’t have the license fields injected into the global Helm values by default, but you can add them yourself in the HelmChart resource for your chart.

The values key in the chart resource handles not only chart-specific values but also global and sub-chart values. Add this snippet to your chart resource to provide the expected global values:

values:
  global:
    replicated:
      licenseFields:
        api_key:
          value: '{{repl LicenseFieldValue "api_key"}}'

The Admin Console processes these resources to prepare the values passed to the Helm chart. By the time your Helm chart renders, the {{repl LicenseFieldValue "api_key"}} has already been replaced with the actual API key value from the customer’s license. Your chart receives clean, resolved values that look identical to what you’d get from automatic injection in KOTS installations. This creates consistency across deployment methods. Whether customers install through KOTS in an existing cluster or use Embedded Cluster, your Helm templates reference the same .Values.global.replicated.licenseFields.api_key.value path. The difference lies only in how those values arrive—automatic injection versus explicit template function resolution.

Security Considerations

This pattern handles secrets securely throughout the deployment lifecycle. License fields never appear in logs or config maps where they might be accidentally exposed. They flow directly into Kubernetes secrets where RBAC controls access and encryption-at-rest protects the data.

The license-based approach also simplifies credential rotation. Instead of asking customers to update secrets manually or building complex credential management into your application, you update the license field value in the Replicated Platform. The next application update automatically delivers the new credentials through the same template mechanism.

Making It Work for You

License fields excel at distributing small, customer-specific configuration data that your application needs at startup. API keys, database connection strings, and certificate references all fit this pattern well. The approach works just as effectively for larger text based assets like old-school license key or configuration that are hard to template in Helm. Large binary assets are a bit harder to distribute this way, but try them out as Base-64 encoded strings.

The real power emerges when you combine license fields with your existing Helm chart patterns. You’re not changing how your application consumes secrets; you’re just changing how those secrets get populated. This makes the pattern particularly appealing for existing applications that already use Kubernetes secrets for configuration.

1 Like