helm upgrade --install kong-operator kong/kong-operator -n kong-system \
--create-namespace \
--set image.tag=2.3 \
--set env.ENABLE_CONTROLLER_KONNECT=true
kubectl -n kong-system wait --for=condition=Available=true --timeout=300s deployment/kong-operator-kong-operator-controller-managerReference Konnect authentication across multiple namespaces with Kong Operator
Uses:
Kong Operator
Incompatible with
on-prem
Related Documentation
Related Resources
Minimum Version
Kong Operator - 2.1
TL;DR
Use a KongReferenceGrant in the same namespace as the KonnectAPIAuthConfiguration to authorize references from the source namespace.
Prerequisites
Kong Konnect
If you don’t have a Konnect account, you can get started quickly with our onboarding wizard.
- The following Konnect items are required to complete this tutorial:
- Personal access token (PAT): Create a new personal access token by opening the Konnect PAT page and selecting Generate Token.
-
Set the personal access token as an environment variable:
export KONNECT_TOKEN='YOUR KONNECT TOKEN'
Kong Operator running
If you want cert-manager to issue and rotate the admission and conversion webhook certificates, install cert-manager to your cluster and enable cert-manager integration by passing the following argument while installing, in the next step:
--set global.webhooks.options.certManager.enabled=trueIf you do not enable this, the chart will generate and inject self-signed certificates automatically. We recommend enabling cert-manager to manage the lifecycle of these certificates.
Kong Operator needs a certificate authority to sign the certificate for mTLS communication between the control plane and the data plane.
This is handled automatically by the Helm chart. If you need to provide a custom CA certificate, refer to the certificateAuthority section
in the values.yaml of the Helm chart to learn how to create and reference your own CA certificate.
By default, Kong Operator restricts references to resources within the same namespace for security. To enable cross-namespace references, you must use one of the following resources in the target namespace:
ReferenceGrant: A standard Kubernetes Gateway API resource used for authorizing references from Gateway API resources to other resources.KongReferenceGrant: A Kong-specific resource used for authorizing references from Kong resources to other resources.
This example shows how to allow a Gateway in the kong namespace to use Konnect authentication credentials stored in the auth namespace using KongReferenceGrant. For an example using ReferenceGrant, see Reference Secrets across multiple namespaces.
Create the KonnectAPIAuthConfiguration
Run the following command to create an auth namespace and a KonnectAPIAuthConfiguration in that namespace:
echo '
apiVersion: v1
kind: Namespace
metadata:
name: auth
---
kind: KonnectAPIAuthConfiguration
apiVersion: konnect.konghq.com/v1alpha1
metadata:
name: konnect-api-auth
namespace: auth
spec:
type: token
token: '"$KONNECT_TOKEN"'
serverURL: us.api.konghq.com' | kubectl apply -f -Create the KongReferenceGrant
Create a KongReferenceGrant in the auth namespace to allow a KonnectGatewayControlPlane in the kong namespace to access the credentials:
echo '
kind: KongReferenceGrant
apiVersion: configuration.konghq.com/v1alpha1
metadata:
name: allow-kong-cp-to-auth
namespace: auth
spec:
from:
- group: konnect.konghq.com
kind: KonnectGatewayControlPlane
namespace: kong
to:
- group: konnect.konghq.com
kind: KonnectAPIAuthConfiguration' | kubectl apply -f -Create the GatewayConfiguration
Create a kong namespace and configure a GatewayConfiguration to reference the credential in the auth namespace.
echo '
apiVersion: v1
kind: Namespace
metadata:
name: kong
---
kind: GatewayConfiguration
apiVersion: gateway-operator.konghq.com/v2beta1
metadata:
name: gateway-configuration
namespace: kong
spec:
konnect:
authRef:
name: konnect-api-auth
namespace: auth
dataPlaneOptions:
deployment:
podTemplateSpec:
spec:
containers:
- name: proxy
image: kong/kong-gateway:3.16' | kubectl apply -f -Create the Gateway
Create a GatewayClass resource that references the GatewayConfiguration, and a Gateway resource that references the GatewayClass.
echo '
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: gateway-class
spec:
controllerName: konghq.com/gateway-operator
parametersRef:
group: gateway-operator.konghq.com
kind: GatewayConfiguration
name: gateway-configuration
namespace: kong
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: kong
namespace: kong
spec:
gatewayClassName: gateway-class
listeners:
- name: http
port: 80
protocol: HTTP' | kubectl apply -f -Validate
To validate, check that the operator created a KonnectGatewayControlPlane in the kong namespace and that it’s
Programmed:
kubectl get konnectgatewaycontrolplane -n kong
kubectl wait --for=condition=Programmed --all -n kong konnectgatewaycontrolplane --timeout=5mBy default, the generated
KonnectGatewayControlPlanereceives a dynamic name. Add thegateway-operator.konghq.com/static-naming: "true"annotation to yourGatewayto give it the Gateway’s name instead, and, in Kong Operator 2.3.2 and later, to name the control plane in Konnect<namespace>_<gateway-name>. Kong Operator sets these names when it creates the resources and doesn’t change them afterwards.
Cleanup
Delete the resources created in this guide
Deleting the Gateway also deletes the KonnectGatewayControlPlane that Kong Operator
created for it, which removes the control plane from Konnect:
kubectl delete -n kong --ignore-not-found gateway/kong gatewayconfiguration/gateway-configuration
kubectl delete -n kong --ignore-not-found konnectgatewaycontrolplane --all
kubectl delete --ignore-not-found gatewayclass/gateway-class
kubectl delete -n auth --ignore-not-found \
kongreferencegrant/allow-kong-cp-to-auth \
konnectapiauthconfiguration/konnect-api-auth
kubectl delete namespace --ignore-not-found kong auth