Advisory ID: DOPPLER-PSA-2022-002 Publication Date: 2022-10-14 Revision Date: 2022-10-14 Status: Confirmed, Fixed Document Revision: 1

Overview

Doppler has identified and resolved a low severity vulnerability in the Doppler Kubernetes Operator which allowed users to:

• Instruct the operator to fetch Doppler secrets using Kubernetes tokens secrets in namespaces that the user normally could not access
• Instruct the operator to write Doppler secrets to Kubernetes managed secrets in namespaces that the user could not normally access

Note that users cannot instruct the operator to output the contents of a Kubernetes token secret; the operator can only be instructed to use a token secret to fetch secret data from Doppler.

Impact

Before v1.2.0, the operator processed any DopplerSecret resources in any namespace in the cluster. For example,

apiVersion: secrets.doppler.com/v1alpha1
kind: DopplerSecret
metadata:
  name: dopplersecret-test
  namespace: default
spec:
  tokenSecret:
    name: doppler-token-secret
		namespace: ns1
  managedSecret:
    name: doppler-test-secret
    namespace: ns2

In this example, the user who created this resource can only create DopplerSecret resources in the default namespace. They cannot directly access Kubernetes secrets in the ns1 or ns2 namespaces.

With the YAML above, the user creates a DopplerSecret resource in the default namespace which instructs the operator to fetch a Doppler service token from the doppler-token-secret Kubernetes secret in the ns1 namespace and write the Doppler secrets into the doppler-test-secret Kubernetes secret in the ns2 namespace.

Although the user does not have permissions to access resources in ns1 or ns2, they are able to use the operator to fetch secrets from the Doppler API using a token secret in ns1 and write a managed secret in ns2. If doppler-test-secret in ns2 already exists, the operator would overwrite it.

Solution

To resolve this vulnerability, the v1.2.0 operator only processes DopplerSecret resources which have been created in the same namespace as the operator deployment (doppler-operator-system, by default).

The operator’s namespace is treated as privileged; any users with access to create DopplerSecret resources in this namespace will be able to instruct the operator to perform operations on any Kubernetes secrets in any namespaces, using the same mechanisms described above. This consideration should be taken into account when configuring RBAC in your cluster.

Upgrade steps

Note: When upgrading to v1.2.0, any DopplerSecret resources in namespaces other than the operator’s namespace will stop being processed. The managed Kubernetes secret will be left unchanged but future changes to your Doppler config will not be synced.

You can check if you have any DopplerSecret resources outside the operator namespace using this command:

kubectl get dopplersecrets -A | grep -v doppler-operator-system

If any resources appear in this list, you can manually delete them and re-create them in the doppler-operator-system namespace before you upgrade. If no resources appear in the list, all DopplerSecret resources are in the doppler-operator-system namespace and will continue to be processed by the v1.2.0 operator.