Configure Operator Scope and Namespaces

Configure the namespaces that Confluent for Kubernetes manages.

Configure CFK to manage Confluent Platform components across all namespaces

By default, CFK deploys Confluent Platform in the namespaced mode, and manages Confluent Platform component clusters and resources in the same Kubernetes namespace where CFK itself is deployed.

To enable CFK to manage Confluent Platform resources across all namespaces in the cluster mode, set the namespaced configuration property to false in the install command:

helm upgrade --install confluent-operator \
  confluentinc/confluent-for-kubernetes \
  --set namespaced=false \
  --namespace <namespace>

Expected: Release "confluent-operator" has been upgraded. Happy Helming!, followed by STATUS: deployed.

You can also update the values.yaml file as described in Deploy CFK with custom values, and set the following property:

namespaced: false

Configure CFK to manage Confluent Platform components in different namespaces

In a namespaced deployment (namespaced: true), CFK, by default, only watches the same Kubernetes namespace that it is deployed in.

To enable CFK to manage Confluent Platform resources deployed in different namespaces, specify a list of namespaces for CFK to watch. The list must contain the namespaces of CFK as well as the Confluent Platform components.

You can specify the namespaces in the install command. For example:

helm upgrade --install confluent-operator \
  confluentinc/confluent-for-kubernetes \
  --set namespaceList="{confluent-namespace,cfk-namespace}" \
  --namespace cfk-namespace \
  --set namespaced=true

Expected: Release "confluent-operator" has been upgraded. Happy Helming!, followed by STATUS: deployed.

You can also update the values.yaml file as described in Deploy CFK with custom values, and set the following property:

namespaceList: [confluent-namespace,cfk-namespace]

Restrict cross-namespace REST class usage

By default, Confluent for Kubernetes (CFK) allows CFK application resources to reference KafkaRestClass and CMFRestClass custom resources (CRs) in other namespaces.

For stricter multi-tenant isolation, you can configure CFK to reject cross-namespace REST class references. When this restriction is enabled, CFK validates that any resource referencing a KafkaRestClass or CMFRestClass (such as KafkaTopic, ConfluentRolebinding, ClusterLink, FlinkEnvironment, or FlinkApplication) uses a REST class that is in the same namespace as the referencing resource.

To enable this behavior when installing CFK with Helm, set the following values:

helm upgrade --install confluent-operator \
  confluentinc/confluent-for-kubernetes \
  --set restrictCrossNamespaceKafkaRestClassUsage=true \
  --set restrictCrossNamespaceCMFRestClassUsage=true \
  --namespace <namespace>

Expected: Release "confluent-operator" has been upgraded. Happy Helming!, followed by STATUS: deployed.

You can also update the CFK values.yaml file:

# Restrict cross-namespace KafkaRestClass usage
# When enabled, resources cannot reference KafkaRestClass objects
# from other namespaces.
restrictCrossNamespaceKafkaRestClassUsage: true

# Restrict cross-namespace CMFRestClass usage
# When enabled, resources cannot reference CMFRestClass objects
# from other namespaces.
restrictCrossNamespaceCMFRestClassUsage: true

Internally, these Helm values configure the following environment variables on the CFK operator pod:

• RESTRICT_CROSS_NAMESPACE_KAFKARESTCLASS_USAGE

• RESTRICT_CROSS_NAMESPACE_CMFRESTCLASS_USAGE

Deploy CFK after separately installing CRDs

By default, when you deploy CFK using helm, the helm command also installs the Confluent Platform custom resource definitions (CRDs). If you do not have permission to install those CRDs, your helm installation fails.

Installing CRDs might be restricted to your Kubernetes cluster administrator. In this situation, your Kubernetes cluster administrator must have installed the required Confluent CRDs in advance as described in Strict permissions and restricted namespace access.

To instruct helm to skip trying to install the CRDs, add --skip-crds to the install command:

helm upgrade --install confluent-operator \
  confluentinc/confluent-for-kubernetes \
  --skip-crds \
  --namespace <namespace>

Expected: Release "confluent-operator" has been upgraded. Happy Helming!, followed by STATUS: deployed.

Deploy CFK without creating roles and role bindings

By default, when you deploy CFK using helm, the helm command also creates the Kubernetes role and role binding (or cluster role and cluster role binding) needed for CFK to function at the same time. If you do not have the ability to manage Kubernetes role-based access control (RBAC) permissions, your helm installation fails.

Managing Kubernetes RBAC permissions can be restricted to your Kubernetes cluster administrator. In this situation, your Kubernetes cluster administrator must create the requisite RBAC resources in advance as described in Prepare Kubernetes Cluster for Confluent Platform and Confluent for Kubernetes. To instruct helm to skip trying to create RBAC resources, add --set rbac=false to the install command:

helm upgrade --install confluent-operator \
  confluentinc/confluent-for-kubernetes \
  --set rbac=false \
  --namespace <namespace>

Expected: Release "confluent-operator" has been upgraded. Happy Helming!, followed by STATUS: deployed.

You can also update the values.yaml file as described in Deploy CFK with custom values, and set the following property:

rbac: false

Related content

• To deploy CFK with custom Helm values, see Deploy CFK with Custom Values.

• To tune CFK-level settings, see Configure CFK-Level Settings.

• To prepare CRDs and RBAC resources in advance, see Strict permissions and restricted namespace access and Prepare Kubernetes Cluster for Confluent Platform and Confluent for Kubernetes.