We know that a *lot* of you are all in on Kubernetes as your source of declarative configuration. You have CI/CD pipelines set up already to review and approve your Kubernetes manifests.

Not only that, but you’re using everything the Kubernetes ecosystem has to offer when it comes to managing resources. You’re inspecting the `Status` field of resources to understand the reconciliation status. You’re using Kubernetes RBAC to add some governance to your configuration. You’re using `ReferenceGrant` to allow teams to conditionally allow access to their systems. 

Kubernetes is a strategic tool for you, which makes it a strategic tool for Kong. That’s why we’ve invested in making sure that you can configure Konnect using CRDs.

The initial release is focused on managing Konnect Gateway control planes and all associated entities, but we’ll continue to ship new entities in every release of the operator until you can manage every part (yes, that means API Products, Portal, Teams, Roles, and a whole lot more) of Konnect with CRDs.

## Announcing konnect.konghq.com/v1alpha1

We’re working hard on Kong Gateway Operator 1.4 (which will be released in November), which includes a new Konnect controller and a set of CRDs in the [konnect.konghq.com/v1alpha1](http://konnect.konghq.com/v1alpha1)konnect.konghq.com/v1alpha1 apiVersion. As indicated by the version, this is an early access preview that we’re continuously adding new capabilities to.

Today, you can create a Kong Gateway control plane in Konnect and manage all of the Gateway entities within that control plane. Each entity is a separate CRD, including `KongService` and `KongRoute`. We intend to support `Ingress` and `HTTPRoute` in the future, but for now, we’re focused on providing the fine-grained building blocks so that people can meet all of their use cases as quickly as possible.

## How does it work?

You can get started with Konnect CRDs in just four quick steps:

1. - Install Kong Gateway Operator
2. - Configure your authentication credentials
3. - Create a `KonnectGatewayControlPlane`
4. - Create a `KongService`

### Install Kong Gateway Operator

You’ll need to ensure that you’re running version 1.4 of the Kong Gateway Operator before trying out the new Konnect CRDs functionality. That means that you won’t be able to test this out yourself until early October when KGO 1.4 is released.

However, if you’re reading this in November, the good news is that you can get started today!

helm repo add kong https://charts.konghq.com
helm repo update kong
helm upgrade --install kgo kong/gateway-operator -n kong-system --create-namespace --set image.tag=1.4

### Configure authentication credentials

The operator needs to know which Konnect region you’re using, and what API token to use to authenticate. The token can either be a personal access token or a system access token with the correct permissions.

To configure credentials, create a `KonnectAPIAuthConfiguration` entity:

kind: KonnectAPIAuthConfiguration
apiVersion: konnect.konghq.com/v1alpha1
metadata:
  name: konnect-api-auth-us-prod
  namespace: default
spec:
  type: token
  token: kpat_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  serverURL: us.api.konghq.com

### Create a KonnectGatewayControlPlane

The first Konnect entity we’re going to create is a new Gateway control plane. It defaults to a hybrid mode control plane, but you can set the `cluster_type` under the `spec` field to create a KIC in Konnect or Control Plane Group control plane.

The `spec.konnect.authRef` is what tells the operator which API credentials to use when syncing this configuration.

kind: KonnectGatewayControlPlane
apiVersion: konnect.konghq.com/v1alpha1
metadata:
  name: production
  namespace: default
spec:
  name: Production
  labels:
    owner: myuser
  konnect:
    authRef:
      name: konnect-api-auth-us-prod

### Create a KongService

Finally, you can create a `KongService` that lives inside the control plane that was just created.

You might spot that there's a `controlPlaneRef` in the manifest. This references the control plane that was created in the last step by name, allowing the operator to figure out which control plane this `KongService` should be published to.

kind: KongService
apiVersion: configuration.konghq.com/v1alpha1
metadata:
  name: example-service
  namespace: default
spec:
  name: example-service
  host: example.com

  controlPlaneRef:
    type: konnectNamespacedRef
    konnectNamespacedRef:
      name: production

At this point, you should be able to log in to Konnect and see your new control plane and service created. You can try deleting the service and waiting a few seconds. The operator will notice that the service no longer exists in Konnect and recreate it automatically.

## Try it out

Once KGO 1.4 is available, we’d love for you to try it out and provide feedback by posting on our GitHub discussion forum. We’re looking for feedback on bugs of course, but we also want to hear about your use cases and how the current CRD design feels to use.

If you have any questions or feedback for us (even before the release), our product and engineering team are monitoring [GitHub discussions](https://github.com/Kong/gateway-operator/discussions)GitHub discussions for the operator daily.