<a id="co-manage-rest-api"></a>

# Manage Confluent Admin REST Class for Confluent Platform Using Confluent for Kubernetes

This topic describes how to configure and manage Confluent Admin REST class
endpoints in Confluent for Kubernetes (CFK).

When managing Kafka topics using the KafkaTopic custom resource (CR),  managing
Confluent RBAC role bindings using the ConfluentRolebinding custom resource
(CR), or using the automatic cluster shrinking feature, you need to first set up
an Admin REST Class custom resource (CR) to specify which REST endpoint to use.

If you have one Kafka cluster that you are managing, it’s recommended to create a
default KafkaRestClass CR in the same namespace, with the name `default`. This
is then picked up as the default option by any ConfluentRolebinding CR that
you create.

You can configure multiple KafkaRestClass CRs to manage topics and role bindings
across different Kafka clusters.

#### IMPORTANT
KafkaTopic CRs do not fall back to a `default` KafkaRestClass CR when
`kafkaRestClassRef` is omitted. For details on how to
configure this on an RBAC-enabled cluster, see [Manage Kafka Topics for Confluent Platform Using Confluent for Kubernetes](co-manage-topics.md#co-manage-topics).

Regardless of how a KafkaRestClass CR is referenced, the following namespace
restrictions apply:

#### NOTE
By default, CFK allows `KafkaTopic`, `ConfluentRolebinding`, `ClusterLink` and
other CFK resources to reference a `KafkaRestClass` that is defined in a
different namespace.

If the CFK operator is deployed with cross-namespace REST class
restrictions enabled, these resources must reference a `KafkaRestClass` in the
same namespace as the resource itself. Cross-namespace `KafkaRestClass`
references are then rejected by CFK validation. For more information on how to enable this
restriction on the CFK operator, see [Restrict cross-namespace REST class usage](co-operator-scope.md#co-deployment-restrict-cross-namespace).

## Create an Admin REST Class CR

Create a KafkaRestClass CR to configure the Admin REST Class:

```yaml
kind: KafkaRestClass
metadata:
  name:                          --- [1]
  namespace:                     --- [2]
spec:
  kafkaClusterRef:               --- [3]
    name:
    namespace:
  kafkaRest:                     --- [4]
    endpoint:                    --- [5]
    authentication:
      type:                      --- [6]
      basic:
      bearer:
      oauth:
    tls:                         --- [7]
      secretRef:                 --- [8]
      directoryPathInContainer:  --- [9]
    kafkaClusterID:              --- [10]
```

* [1] Name of the KafkaRestClass CR. `default` is recommended.
* [2] Namespace of the KafkaRestClass CR.
* [3] [5] Provide either `kafkaClusterRef` or `kafkaRest.endpoint` to
  explicitly specify the Kafka cluster.

  If both are omitted, the Kafka cluster in the same namespace is used. If there
  are more than one Kafka cluster in the same namespace, the CR creation will
  error out.
* [3] Name of the Kafka cluster.

  If authentication is required, configure the `spec.kafkaRest.authentication`
  section in the CR. For example:
  ```yaml
  spec:
    kafkaClusterRef:
      name: kafka
      namespace: operator-test
    kafkaRest:
      authentication:
        type: basic
        basic:
          secretRef: mds-admin-client
  ```
* [4] Admin REST Class configuration.

  If you need to specify a Kafka cluster REST endpoint that is not in the same
  Kubernetes cluster, you need to specify the `kafkaRest` configuration.
* [5] Admin REST Class endpoint. If not specified, CFK tries to discover the
  Kafka cluster in the same Kubernetes cluster.
* [6] Authentication type. `basic`, `bearer`, `mtls`, and `oauth` are
  supported.

  See [Basic authentication](co-authenticate-cp.md#co-authenticate-cp-basic), [Bearer authentication](co-authenticate-kafka.md#co-authenticate-mds-bearer),
  [mTLS authentication](co-authenticate-cp.md#co-authenticate-cp-mtls), and [OAuth/OIDC authentication](co-authenticate-cp.md#co-authenticate-cp-oauth) for
  details.

  The TLS configuration [7] is required when you set the authentication type to
  `mtls`.
* [7] TLS client configuration. Required when the MDS is running in the HTTPS
  mode. Specify either `secretRef` or `directoryPathInContainer`.
* [8] The name of the secret that contains the TLS certificates.

  See [Provide TLS keys and certificates in PEM format](co-network-encryption.md#co-certs-pem) for the expected keys in the TLS secret. Only the PEM
  format is supported for Admin REST. An upcoming release adds support for
  Java KeyStore and PKCS12 formats, which CFK decodes internally to PEM.
* [9] The directory path in the container where the required certificates are
  injected by Vault.

  See [Provide TLS keys and certificates in PEM format](co-network-encryption.md#co-certs-pem) for the expected keys. Only the PEM format is
  supported for Admin REST. An upcoming release adds support for Java
  KeyStore and PKCS12 formats, which CFK decodes internally to PEM.
* [10] The id of the Kafka cluster.