Skip to content

Cloud Control Operator

Cloud Control Operator is a default component part of any Userplane & Controlplane deployment. The operator is responsible for ongoing management activities for which Kubernetes itself has no functionality. Currently the operator contains the following modules:

Feature Description
Readiness Based Primary Responsible for selection of a primary Pod to be used in Service objects which are configured to be sticky towards a single Pod
Secrets Manager Responsible for serverside generation of Secrets for which no static or preprovisioned value is present
STEK Manager Responsible for generation & rotation of STEK keys used by dnsdist DoH & DoT listeners

Readiness Based Primary

The Readiness Based Primary (RBP) module constantly monitors the Pods which belong to Deployments & Statefulsets with a label cloudcontrol.powerdns.com/rbp-primary: true and applies an algorithm which ensures that for each of these Deployments & Statefulsets there is always 1 Pod which has a label cloudcontrol.powerdns.com/rbp-service: true present. This same label is added as a selector to the corresponding Service object (for example, the Auth API Service) to achieve stickiness towards that single Pod.

The algorithm used to determine the Pod which should receive the traffic is based on the following rules:

  • The Pod must be in Ready state
  • The Pod is preferred to be from the most recent iteration of the Deployment or Statefulset during rolling upgrades
  • If the currently selected Pod is still eligible based on above rules, it remains the selected Pod (ie: No swapping when there is no reason for it)

The components currently utilizing the RBP functionality are as follows:

Each of these has a toggle disableSticky which can be set to true to disable the RBP functionality. Disabling RBP means the traffic distribution will be controlled by the default Service behaviour on the Kubernetes cluster, likely round-robin.

Warning

The current set of Services which utilize the RBP functionality has been carefully curated. It is strongly recommended to avoid setting the disableSticky parameter to true unless there is a good reason to do so.

Secrets Manager

The Secrets Manager is a module which is responsible for generating Secrets for which no specific value has been configured via static value or preprovisioned Secret. Examples of such Secret values which may need to be generated are the API key for Authoritative Server instances (which can be overridden by users) or the Secret which Cloud Control agents use to authenticate themselves on the internal NATS mesh.

This mechanism exists for 2 reasons:

  • It allows Cloud Control to be in line with the serverside approach which GitOps tooling like Argo CD require and Helm is moving towards in the future
  • It improves security by preventing Helm from having to generate a value on a client outside of the Kubernetes cluster and then having to communicate that value to the cluster to be injected into a Secret object

To implement this feature, Helm & Secrets Manager work together as follows:

Helm is responsible for creating a ConfigMap which contains a definition of the Secrets which the Secrets Manager will be responsible for. These ConfigMaps have the same naming convention as the Deployments / Statefulsets which utilize them, with a suffix of -ccsm, for example the auth-testauth deployment will be accompanied by a ConfigMap named auth-testauth-ccsm. Inside this ConfigMap, a secretdef items contains the definitions needed by the Secrets Manager.

The auth-testauth-ccsm example (an Authoritative Server instance set named testauth) would have the following contents if no API key is specified during deployment:

auth-testauth-ccsm:
  entries:
    - key: api_key
      generator: alphanumeric
      length: 32
      legacy:
        secret: auth-testauth
        key: api_key

Each of these ConfigMaps containing definitions of Secrets (identified using a specific label) are constantly monitored by the Secrets Manager. The Secrets Manager ensures a Secret is present with the name of the root node (auth-testauth-ccsm in the above example) and key value pairs based on the definitions under the entries node.

As suggested by the above example definition, there are several ways the contents of a Secret key can be decided upon by the Secrets Manager:

  • Generated: If there is no existing generated value and there are no prioritized sources of obtaining the value, a new one is generated using the generator specified under generator with length length.
  • Legacy: To facilitate upgrades from Cloud Control releases without Secrets Manager support, the Legacy mechanism is used to ensure any values previously generated client side by Helm are copied into the new Secrets Manager controlled Secret. This exists to ensure these upgrades do not experience unexpected changes to generated Secret values.
  • Static: In some cases a static value may accompany a Generated/Legacy value. For example: A static username could accompany a generated password.

STEK Manager

STEK keys are used by dnsdist DoH and DoT listeners to attempt to mitigate the overhead incurred while negotiating new TLS sessions by enabling the resumption of previously negotiated sessions. A detailed description of this mechanism can be found in the dnsdist documentation.

To simplify the usage of STEK keys in a Cloud Control deployment, the STEK Manager assumes responsibility for generating a single set of STEK keys for each dnsdist instance set and rotating them when necessary. Since all dnsdist Pods belonging to the same instance set apply the same set of STEK keys, session resumption is enabled across all dnsdist Pods within that instance set.

If you wish to override this behaviour by providing your own set of STEK keys, both DoH and DoT listeners have a stekSecret parameter which can be used to specify your own Secret to grab STEK keys from (changes to this Secret are monitored at runtime and STEK keys are updated in dnsdist accordingly if modifications are detected).