<a id="co-license-key"></a>

# Manage Confluent Platform License in Confluent for Kubernetes

You can use Confluent Platform for a 30-day trial period without a license key. After 30 days,
Confluent components require license keys. For information about
Confluent licenses, including types of licenses, see [Confluent Platform
Licenses](https://docs.confluent.io/platform/current/installation/license.html).

In Confluent for Kubernetes (CFK), the following methods are supported to configure or update the license for Confluent Platform components:

* Use Confluent Control Center or Confluent Control Center (Legacy).

  All Confluent Platform components that use the same Apache Kafka® cluster as the Control Center get the updated license without needing a rolling restart.

  The components not using the same Kafka cluster as the Control Center do not get the updated license.

  For using Control Center, see [Apply a license in Confluent Control Center](https://docs.confluent.io/control-center/current/installation/license.html).

  For using Confluent Control Center (Legacy), see [Apply a license in Confluent Control Center (Legacy)](https://docs.confluent.io/platform/7.9/control-center/installation/c3-license.html#applycplicensec3ui).
* Use the CFK API.

  This method requires the rolling restart of Kafka and other affected components.
  When you declaratively configure Confluent Platform licenses with CFK API, you have two
  options to configure the license for Confluent Platform components:
  * [Configure at the global level](#co-licence-global-level)
  * [Configure at the component level](#co-license-component-level)

#### NOTE
For Connect, [Centralized Connect License](https://docs.confluent.io/platform/current/connect/license.html#centralized-license-in-the-kconnect-long-worker)
does not work with the Docker image `confluentinc/cp-kafka-connect`.
Use the `confluentinc/cp-server-connect` Docker image to leverage the
Centralized License.

<a id="co-licence-global-level"></a>

## Update CFK global license

CFK configures the global license key for Confluent components.

When using the global license, CFK creates the `confluent-operator-licensing`
and `internal-confluent-operator-licensing` secrets. The secrets are used by
Confluent Platform components and should not be deleted.

Confluent Platform components use the `internal-confluent-operator-licensing` secret when you configure them
to use the global license. For example, set `spec.license.globalLicense: true` in a component custom resource (CR).
The operator does not create this secret when you configure the Confluent for Kubernetes (CFK) global license alone. The operator
creates it only after you deploy at least one component that uses the global license. You do not need to create or
manage this secret manually, but do not delete it while components are using the global license.

1. Add or update the global license key for CFK operator.
   1. To find the version image tag you wish to update the license for, see
      [CFK Image Tags](co-supported-environments.md#co-operator-image-tags). For example, to update the
      license for CFK 3.3.0, use the image tag, `0.1718.10`.

      If a tag is not specified (that is, if `--set image.tag=XXXX` is omitted
      in the next `helm upgrade` command), the latest version of CFK updates.
   2. Run the `helm upgrade` command from the `helm` sub-directory under
      the directory that has the downloaded CFK bundle.
      ```bash
      helm upgrade --install confluent-operator \
        confluentinc/confluent-for-kubernetes \
        --namespace <namespace> \
        --set image.tag=XXXX \
        --set licenseKey=<CFK license key>
      ```

      When the above command runs, the `confluent-operator-licensing` secret is
      created or updated with the `license.txt` and `publicKey.pem` files.
      * `license.txt` contains the `<CFK license key>` you specified in the
        command.
      * `publicKey.pem` contains the public key used to validate the signed
        license. This key is only used by CFK and is not used by Confluent Platform
        components.

      At this point, only the license key secret for the CFK operator is
      updated.
2. If this is the first time you are setting the license, the CFK operator
   restarts automatically.

   If you are replacing an existing license, you must restart the CFK operator
   manually.

   The Confluent Platform components are still using the old license until the components
   are restarted as described in the next steps.
3. For Confluent Platform components to use the global license set in CFK, repeat the
   following steps for each component that you want to apply the license to:
   1. Set the following in the component CR:
      ```yaml
      spec:
        license:
          globalLicense: true
      ```
   2. Apply the component CR change.

      If you have multiple component CRs defined in a single file, you only
      need to run the command once after setting `spec.license.globalLicense`
      properties in all the component CRs.
      ```bash
      kubectl apply -f <component CR> --namespace <namespace>
      ```
   3. Restart the updated components to use the global license.
      1. Find the name of the StatefulSet corresponding to the Confluent Platform cluster you
         want to restart:
         ```bash
         kubectl get statefulset --namespace <namespace>
         ```
      2. Replace `<name-of-statefulset>` with the StatefulSet name from
         the previous step, then roll the cluster:
         ```bash
         kubectl rollout restart statefulset/<name-of-statefulset> \
           --namespace <namespace>
         ```

<a id="co-license-component-level"></a>

## Update component-level licenses

You can configure the license structure at the component level, which takes
precedence over the license configured by CFK.

The component-level license can be provided using one of the following methods:

* [A Kubernetes secret](#co-license-key-in-secret)
* [An external secret provider, such as Vault](#co-license-key-in-vault)

The `license.txt` file is required to be present either in the `secretRef`
or `directoryPathInContainer` path.

If both `secretRef` or `directoryPathInContainer` is configured,
`directoryPathInContainer` takes precedence.

<a id="co-license-key-in-secret"></a>

### Component-level license configuration with Kubernetes secrets

To provide a component license key using a Kubernetes secret:

1. Create the `license.txt` file with `license=<your license key>`:
   ```bash
   echo -n "license=<your license key>" > license.txt
   ```
2. Create a Kubernetes secret for the `license.txt` file.
   `--from-file=license.txt=` should be included in the command:

   For example, with the `license.txt` file in the current directory:
   ```bash
   kubectl create secret generic confluent-license \
     --from-file=license.txt=./license.txt \
     --namespace <namespace>
   ```
3. Set the secret name in the component CR. Using the previous example:
   ```yaml
   spec:
     license:
       secretRef: confluent-license
   ```
4. Apply the component CR change:
   ```bash
   kubectl apply -f <component CR> --namespace <namespace>
   ```
5. Roll the component cluster to apply the license change.
   1. Find the name of the StatefulSet corresponding to the Confluent Platform cluster you
      want to restart:
      ```bash
      kubectl get statefulset --namespace <namespace>
      ```
   2. Replace `<name-of-statefulset>` with the StatefulSet name from the
      previous step, then roll the cluster:
      ```bash
      kubectl rollout restart statefulset/<name-of-statefulset> \
        --namespace <namespace>
      ```

<a id="co-license-key-in-vault"></a>

### Component-level license configuration with an external secret provider

To provide a component license key using an external secret provider, such as HashiCorp Vault:

1. Install and configure Vault.
2. Create the `license.txt` file with `license=<your license key>`:
   ```bash
   echo -n "license=<your license key>" > license.txt
   ```
3. Write `license.txt` to Vault. For example:
   ```bash
   cat ./license.txt | \
     vault kv put /secrets/license.txt license=-
   ```
4. Set the secret name in the component CR. Using the previous example:
   ```yaml
   spec:
     license:
       directoryPathInContainer: /vault/secrets
   ```
5. Apply the component CR change:
   ```bash
   kubectl apply -f <component CR> --namespace <namespace>
   ```
6. Roll the component cluster to apply the license change.
   1. Find the name of the StatefulSet corresponding to the Confluent Platform cluster you
      want to restart:
      ```bash
      kubectl get statefulset --namespace <namespace>
      ```
   2. Replace `<name-of-statefulset>` with the StatefulSet name from the
      previous step, then roll the cluster:
      ```bash
      kubectl rollout restart statefulset/<name-of-statefulset> \
        --namespace <namespace>
      ```

<a id="co-license-key-view"></a>

## View Confluent Platform License in CFK

To check the status or content of your Confluent license, install the
[Confluent kubectl plugin](co-install-plugin.md#co-install-plugin), and use the `kubectl
confluent cluster license` option as below:

```bash
kubectl confluent cluster license \
  --secret-name confluent-operator-licensing \
  --namespace <namespace>
```

`confluent-operator-licensing` is the default secret generated when you add
the license in CFK.

To check the component-level license with a custom secret name, run:

```bash
kubectl confluent cluster license \
  --secret-name <custom secret name> \
  --namespace <namespace>
```

For information about Confluent licenses, including types of licenses, see
[Confluent Platform Licenses](https://docs.confluent.io/platform/current/installation/license.html).

## Troubleshooting license-related issue

A Confluent Enterprise license is available for the customer-managed Confluent Platform for Confluent Cloud subscription. This license allows you to use self-managed Confluent Platform components exclusively with Confluent Cloud services.

If you encounter the following error when provisioning a new license, upgrade to
CFK version 2.9.7, 2.10.3, 2.11.3, 3.0.1, 3.1.0, or later.

```text
secretRef confluent-license: missing subject or contains invalid subject
```