Namespace and RBAC Strategy

Before deploying Confluent Platform with Confluent for Kubernetes (CFK), plan your Kubernetes namespace strategy and role-based access control (RBAC) permissions.

Kubernetes security

With Kubernetes RBAC and namespaces, you can deploy Confluent Platform using one of the following options:

As a best practice, provide Confluent for Kubernetes with access to provision and manage Confluent Platform resources in one specific namespace.
Provide Confluent for Kubernetes with access to provision and manage Confluent Platform resources across all namespaces in the Kubernetes cluster.

Both options require a Kubernetes role bindings configuration. For details, see Configure Kubernetes RBAC and Custom Resource Definitions.

Prepare your Kubernetes cluster

Preparing your Kubernetes cluster for Confluent Platform deployment requires the following tasks.

There are sometimes up to three actors involved in the deployment process of CFK. Two are human users and one is a Service Account, as follows:

Kubernetes cluster administrator: The Kubernetes cluster administrator provisions a namespace and specific permissions for the CFK user and the CFK Service Account.
CFK user: The CFK user deploys CFK and Confluent Platform components.
CFK Service Account: The CFK Service Account allows the CFK control plane to access the Kubernetes API and create StatefulSets, Services, Secrets, and other Kubernetes resources needed to deploy Confluent Platform components and resources.

If you are trying out CFK for the first time, working in a proof-of-concept (POC) or sandbox environment, you can act as both the Kubernetes cluster administrator and the CFK user. If you are deploying to a production environment, especially in a highly regulated organization, the Kubernetes cluster administrator and CFK user are typically two separate people or teams. Regardless of your particular scenario, the first step for preparing your Kubernetes cluster is to create a namespace.

Create a namespace for CFK

Create a Kubernetes namespace to deploy the CFK control plane:
```
kubectl create namespace <confluent-namespace>
```
Set the new namespace as the current namespace.

This step is not required, but is included here to simplify the example commands in the rest of the documents. The --namespace flag in the subsequent kubectl commands is omitted because the commands assume the current namespace.
```
kubectl config set-context --current --namespace=<confluent-namespace>
```

Configure Kubernetes RBAC and Custom Resource Definitions

If you are a Kubernetes cluster administrator, you can restrict the level of access granted to the CFK user and CFK Service Account. Start by considering the following questions:

Do you want CFK to be able to create and delete Confluent Platform clusters within only one specific namespace, or within any and all namespaces?
Do you want the CFK Service Account to be able to create cluster-level resources such as Custom Resource Definitions (CRDs), or not? Allowing CFK to create such resources reduces the number of manual steps for the Kubernetes cluster administrator, but requires more permissions to be granted to the CFK Service Account.

CFK requires all Confluent CRDs to be installed even if you plan to deploy only a subset of the Confluent components. Also, the Confluent CRDs must be part of the specific version of CFK that you are deploying.
Should the CFK user manage Kubernetes RBAC permissions for the CFK Service Account, or not? The CFK Service Account RBAC permissions can be automatically bootstrapped along with the CFK installation, reducing the number of manual steps, but requires the CFK user to have permissions to not only deploy CFK but also manage some Kubernetes RBAC permissions.

You can use the following instructions to prepare Kubernetes RBAC and CRDs in three common scenarios.

Quick, easy deployment and relaxed permissions

In this scenario, CFK deploys Confluent Platform components into any and all Kubernetes namespaces, and CFK gets cluster-level permissions to automatically install CRDs to avoid manual steps. The CFK user also manages the CFK Service Account permissions to simplify the installation workflow. In this kind of scenario, often the Kubernetes cluster administrator and the CFK user are the same person.

In this scenario, no additional preparation is required, you can proceed straight to deploying CFK, see Deploy Confluent for Kubernetes. Be sure to set namespaced to false. For details, see Configure CFK to manage Confluent Platform components across all namespaces.

Strict permissions and restricted namespace access

In this scenario, CFK is restricted to deploying Confluent Platform components only into the namespace where the CFK control plane is installed. The CFK Service Account has no cluster-level permissions, so it doesn’t install CRDs automatically. You need to install these manually. The CFK user is restricted to only installing and using CFK and Confluent Platform, and doesn’t manage any permissions for the CFK Service Account. Only the Kubernetes cluster administrator manages all Kubernetes RBAC permissions.

In this scenario, the Kubernetes cluster administrator must perform the following steps to prepare the Kubernetes cluster before CFK and Confluent Platform can be deployed.

Pull the CFK Helm chart and extract its contents to get the Confluent CRDs:

mkdir -p <cfk-dir>

helm pull confluentinc/confluent-for-kubernetes \
  --untar --untardir=<cfk-dir>

Install the Confluent CRDs with the following command:
```
kubectl apply -f <cfk-dir>/crds
```
Create a Kubernetes Role and RoleBinding for the CFK Service Account. For details, see the namespaced RoleBinding example. Change any places where it says namespace: confluent by replacing confluent with your <confluent-namespace>. Save this in a file, for example cfk-permissions.yaml, and apply it:
```
kubectl apply -f cfk-permissions.yaml
```
Deploy CFK without creating the RBAC resources and without installing CRDs. For details, see Deploy CFK without creating roles and role bindings and Deploy CFK after separately installing CRDs.

Strict permissions, but deployments spanning all namespaces

This scenario is similar to the previous one. In terms of permissions for the CFK Service Account and CFK user, it is restricted. But this scenario allows for deploying Confluent Platform components across any namespace in your Kubernetes cluster.

In this scenario, the Kubernetes cluster administrator must perform the following steps to prepare the Kubernetes cluster before CFK and Confluent Platform can be deployed.

Pull the CFK Helm chart and extract its contents to get the Confluent CRDs:

mkdir -p <cfk-dir>

helm pull confluentinc/confluent-for-kubernetes \
  --untar --untardir=<cfk-dir>

Install the Confluent CRDs with the following command:
```
kubectl apply -f <cfk-dir>/crds
```
Create a Kubernetes ClusterRole and ClusterRoleBinding for the CFK Service Account. For details, see the cluster ClusterRole and ClusterRoleBinding example. Change where it says namespace: confluent by replacing confluent with your <confluent-namespace>. Save this in a file, for example cfk-permissions.yaml, and apply it:
```
kubectl apply -f cfk-permissions.yaml
```
Deploy CFK without creating the RBAC resources and without installing CRDs. For details, see Deploy CFK without creating roles and role bindings and Deploy CFK after separately installing CRDs.