Controlplane

Controlplane allows for the deployment of components which facilitate management and control of Userplane deployments. It also allows for the centralization of components which are not necessary to deploy in each userplane.

Below example shows 3 Userplane deployments configured to utilize the components in a Controlplane deployment:

Image title — Overview of potential Controlplane deployment

In this example you can see:

Userplane dnsdist instances with filtering enabled, grabbing feeds from the Command Source in the Controlplane
Userplane recursor instances capturing (parts of) traffic and sending it to the Controlplane dstoredist, to be fed into a TopN Reporter to generate reports

The following chapter explains the components currently included in the Controlplane.

Components

Currently, the Controlplane allows for the deployment of components which aid in the following areas:

Reporting: Gain insight into DNS traffic and generate reports
Security: Provide data sources for Userplane components to base their filtering decisions on

Future releases of Cloud Control will have more components included in the Controlplane.

Reporting

Reporting components included:

dstoredist: Distribution, filtering, conversion and storage of DNS traffic protobuf messages generated by dnsdist & recursor
TopN Reporter: Generation of reports based on protobuf messages received & distributed by dstoredist

Security

Security components included:

Feeds: Sources of data for Userplane components to base their filtering decisions on
- Command Source: Generation of feeds based on custom scripts

Installation

Installation of the Controlplane can be done via a single Helm Chart named controlplane. The full path to the Helm Chart is as follows:

controlplane: oci://registry.open-xchange.com/cloudcontrol/controlplane

Before using the Helm Chart, make sure your helm is authenticated against the OX registry:

helm registry login registry.open-xchange.com --username=<REGISTRY_USERNAME> --password=<REGISTRY_PASSWORD>

You can then either install directly from the OX registry:

helm install <RELEASE> --namespace=<NAMESPACE> oci://registry.open-xchange.com/cloudcontrol/controlplane --version <VERSION>

Or you can download the Helm Chart for offline usage:

helm pull oci://registry.open-xchange.com/cloudcontrol/controlplane --version <VERSION>

This should result in a file named controlplane-<VERSION>.tgz which you can use to install from:

helm install <RELEASE> --namespace=<NAMESPACE> controlplane-<VERSION>.tgz

Since Cloud Control Helm Charts are modular and highly configurable, you need to define and configure the components which you would like to deploy. The definition and configuration should be passed into the helm install command via the --values argument. To install directly from the OX registry with a YAML file named myenvironment.yaml you can use this command:

helm install <RELEASE> --namespace=<NAMESPACE> oci://registry.open-xchange.com/cloudcontrol/controlplane --version <VERSION> --values=myenvironment.yaml

Configuration Reference

Controlplane uses the same concepts as Userplane to define and configure components. To deploy a component, it must be defined by providing a key-value pair under the proper root node. For example to configure a set of instances of dstoredist and commandsource:

dstoredists:
  mydstoredist:
    < dstoredist configuration >

commandSources:
  mycmdsource:
    < commandsource configuration >

You can also use this format to define multiple sets of instances of the same component, for example:

commandSources:
  mycmdsource:
    < commandsource configuration >
  anothercmdsource:
    < commandsource configuration >

Parameters which can be used to configure Controlplane are shown in the below table.

Parameter	Type	Default	Description
`commandSources`	Map of commandSource	`{}`	Command Source instance sets
`containerSecurityContext`	`k8s:`SecurityContext		SecurityContext applied to all containers. Default: Specified on the component level. See configuration reference for the corresponding component to see the defaults.
`dstoredists`	Map of dstoredist	`{}`	dstoredist instance sets
`global`	Global		Configuration options for important global usage within the Cloud Control Helm Charts
`podAnnotations`	`k8s:`Annotations	`{}`	Annotations to be added to all pods
`podDisruptionBudget`	`k8s:`PodDisruptionBudgetSpec	`{}`	Spec of PodDisruptionBudget to be applied to all deployments
`podLabels`	`k8s:`Labels	`{}`	Labels to be added to all pods
`podSecurityContext`	`k8s:`PodSecurityContext		SecurityContext to be applied to all pods. Default: Specified on the component level. See configuration reference for the corresponding component to see the defaults.
`prometheus`	Prometheus		Configuration options for automatic Prometheus scraping if the Prometheus Operator is available
`resourceDefaults`	`boolean`	`false`	If true, apply default resource limits to each container
`serviceLabels`	`k8s:`Labels	`{}`	Labels to be added to all services
`tolerations`	List of `k8s:`Tolerations		Tolerations to be applied to all pods
`topns`	Map of topn	`{}`	TopN Reporter instance sets

Global

Global options for this Helm Chart allow for the configuration of:

Image pull secrets to configure access to the OX registry or a private cache/intermediary
Compatibility mode for supported non-standard Kubernetes platforms

Example of using global to configure a private registry where you stored copies of the Cloud Control container images:

global:
  image:
    registry: "myregistry.local:8085"
    repository: "myrepository"

Or to configure Cloud Control to use a pre-existing Secret containing your registry credentials named my-registry-credentials:

global:
  imagePullSecretsList:
    - my-registry-credentials

Parameters which can be used:

Parameter	Type	Default	Description
`image`	ImageOverrides	`{}`	Overrides to configure where container images are pulled from. Default: The OX registry
`imagePullSecrets`	Map of ImagePullSecret	`{}`	Image pull secrets for which Secrets should be created and then used by the service accounts to pull container images from the registry. Recommendation: pre-provision the actual Secrets in your namespace and reference them using `imagePullSecretsList`
`imagePullSecretsList`	List of `string`	`[]`	List of names of Secrets which should be used by service accounts to pull container images from the registry
`openshift`	OpenShift	`{}`	Configuration of OpenSHift compatibility mode. Default: disabled

Image Overrides

You can configure the Helm Chart to ensure Kubernetes pulls container images from a different location than the OX registry. For example:

global:
  image:
    registry: "myregistry.local:8085"
    repository: "myrepository"

Parameters which can be used:

Parameter	Type	Default	Description
`registry`	`string`	`registry.open-xchange.com`	Override the base hostname of the URI from where container images are pulled
`repository`	`string`		Override the repository from which the container images are pulled. Default: Varies based on the type of component
`pullPolicy`	`string`	`"IfNotPresent"`	Force an image pull policy for all containers

Image Pull Secret

You can configure the Helm Chart to create Secrets for one or more sets of credentials to use to authenticate against a registry. Each entry should be a key-value pair, with:

key: Name of the secret
value: Dictionary holding the configuration of the secret

For example, to have an image pull secret with the name myIPSSecret to authenticate against the OX registry:

global:
  imagePullSecrets:
    myIPSSecret:
      registry: registry.open-xchange.com
      username: <USERNAME>
      password: <PASSWORD>
      email: admin@example.com

Parameters which can be used:

Parameter	Type	Required	Description
`registry`	`string`	`yes`	Base URI of the registry
`username`	`string`	`yes`	Username to authenticate with
`password`	`string`	`yes`	Password for authentication
`email`	`string`	`yes`	Email address to satisfy Kubernetes requirements for an image pull secrets in the desired format. Can contain dummy data as long as it satisfies the standard format of an email address

OpenShift

OpenShift requires some specific default settings in Cloud Control to be adjusted to satisfy the platform's requirements. You can configure this Helm Chart to deploy in OpenShift compatibility mode using the following example:

global:
  openshift:
    enabled: true

Parameters which can be used:

Parameter	Type	Default	Description
`openshift`	`boolean`	`false`	If true, enable OpenShift compatibility mode

Prometheus

If you have the Prometheus Operator installed (either yourself or via the Monitoring Helm Chart), you can enable Cloud Control to automatically deploy the necessary PodMonitor objects to automate metric scraping. You can configure this Helm Chart to deploy the PodMonitor objects using the following example:

prometheus:
  operator:
    available: true