How Kubernetes operators work, how they differ from Ansible and Terraform, and why Nauthera registers OAuth clients with one, for teams that already ship with Helm or GitOps.
The idea
Kubernetes runs on control loops: you declare what you want, controllers keep making it so. A Deployment controller keeps three replicas running however often a node dies.
An operator is the same idea for something Kubernetes doesn't know about. It adds a new kind of resource (a CRD, here OIDCClient) and a controller that keeps the real thing, a client in your identity provider, matching it.
Declarative
You say what should exist, not the steps to create it.
Continuous
It keeps checking; it doesn't wait to be run.
Native
RBAC, namespaces, kubectl, events and status all just work.
Self-describing
Every resource carries its own state for anyone to read.
How it works
Pick a stage to see what the Nauthera operator does with one OIDCClient.
01 / 04
The operator watches OIDCClient resources through the Kubernetes API. A new manifest, an edit or a deletion wakes it up; so does a regular resync, so nothing depends on catching every event.
$ kubectl apply -f oidcclient.yaml
oidcclient.nauthera.io/example-webapp createdThree ways to automate
All three are declarative-ish and idempotent. The difference is when they act and where they keep what they know.
Push, when you run it
A playbook connects to targets and runs tasks in order. Nothing happens between runs.
Plan, then apply
It compares configuration with a state file and the provider's API, shows a plan, and changes things when you apply it.
A loop that never stops
A controller in the cluster watches resources and keeps the outside world in line with them, continuously.
Pick a situation. Ansible and Terraform in general; the operator as Nauthera's does it.
Ansible
At the next runNothing notices until the playbook runs again. If a task manages that field, the run sets it back and reports the task as changed; --check --diff shows the drift without touching it.
Terraform
At the next planThe change shows up as drift in the next plan; apply writes the configuration back over it.
Nauthera operator
At the next reconcileThe operator sees a revision it didn't write and reports the resource as Drifted. It writes nothing over the change until the manifest changes or you annotate it nauthera.io/restore: a person decides.
Ansible
An extra taskYou capture the secret in a variable and add tasks to store it somewhere the app can read, often a vault, then template it in.
Terraform
In state, or write-onlyA secret the provider generates is an attribute of the resource, so it is stored in the state file: protect the state backend, then pass the value on to the workload. Since Terraform 1.11, a write-only argument keeps a secret you supply out of state and plan files; the Keycloak provider's client_secret_wo, from its 5.3.0, is one. You then generate the secret and deliver it to the workload yourself.
Sources: Terraform: sensitive data, keycloak_openid_client, provider changelog
Nauthera operator
Straight into a SecretThe server mints it once and keeps only a hash; the operator writes it into a Secret in the app's namespace for the Deployment to mount. It is never in Git, CI logs or a state file.
Ansible
The run failsThe play fails at that task. You run it again once the server is back.
Terraform
Plan or apply failsRefreshing or applying fails; state stays as of the last successful apply. You retry by hand or from CI.
Nauthera operator
Waits it outResources go to Pending (Unreachable) and keep their client ID and Secret. Nothing is removed. One probe backs off from 15 s to 2 min; once the server answers, waiting resources catch up within about a minute.
Ansible
If you wrote itRemoval is a separate play with state: absent. Delete the app without it and the client lives on.
Terraform
On the next applyRemove it from the configuration (or destroy) and apply deletes the client.
Nauthera operator
Your policy decidesdeletionPolicy: Retain (the default) keeps the client registered and releases its Secret, so deleting a namespace can't take a live credential with it. Delete removes both.
Ansible
At run timeThe API call fails at run time, or the module accepts it and the server refuses it later.
Terraform
Plan or applyValidation in the provider catches what it knows about at plan time; the rest fails at apply.
Nauthera operator
At kubectl applyContradictions the definition's rules know, such as a public client without PKCE, are refused at kubectl apply, before anything reaches the server. What the server or the organization's policy refuses shows on the resource as Refused, field by field.
They work together. Terraform is a fine way to build the cluster and its cloud around it; Ansible, to look after machines. The operator takes over inside the cluster, where your apps and their manifests already are.
Fits how you ship
An OIDCClient is just another manifest, so whatever delivers your Deployment delivers its client. Pick your tool.
# templates/oidcclient.yaml, in your app's chart
apiVersion: nauthera.io/v1alpha1
kind: OIDCClient
metadata:
name: {{ include "storefront.fullname" . }}
spec:
clientId: {{ .Values.oidc.clientId }}
redirectUris:
- https://{{ .Values.ingress.host }}/callback
grantTypes: [authorization_code, refresh_token]
tokenEndpointAuthMethod: client_secret_basic
pkcePolicy: required_s256
allowRefresh: true
secret:
generate: true
---
# templates/deployment.yaml (excerpt)
env:
- name: OIDC_CLIENT_SECRET
valueFrom:
secretKeyRef:
name: {{ include "storefront.fullname" . }}
key: client-secretapiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: storefront
namespace: argocd
spec:
project: default
source:
repoURL: https://git.example.com/platform/apps.git
path: storefront # Deployment + OIDCClient
targetRevision: main
destination:
server: https://kubernetes.default.svc
namespace: storefront
syncPolicy:
automated:
prune: true # removed from Git → deletionPolicy applies
selfHeal: trueapiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: storefront
namespace: flux-system
spec:
interval: 10m
path: ./storefront # Deployment + OIDCClient
prune: true
wait: true # waits for each resource's Ready condition
sourceRef:
kind: GitRepository
name: apps
targetNamespace: storefront$ kubectl apply -f oidcclient.yaml
oidcclient.nauthera.io/example-webapp created
$ kubectl wait --for=condition=Ready oidcclient/example-webapp -n storefront
oidcclient.nauthera.io/example-webapp condition met
$ kubectl get secret example-webapp -n storefront \
-o jsonpath='{.data.client-id}' | base64 -d
example-webappOne chart for the server and the operator
The server's Helm chart deploys the operator from the same release, with its mTLS client certificate from cert-manager, its permissions and the resource definitions. Your host, issuer, cache and Secret names go in a values file, as Installation shows.
Install the operator# my-values.yaml: your host, issuer, cache and Secret names (see Installation)
helm upgrade --install nauthera deploy/helm/nauthera-server \
--values deploy/helm/nauthera-server/profiles/production.yaml \
--values my-values.yaml \
--set certManager.grpcTLS.enabled=true \
--set operator.enabled=trueWhy Nauthera uses one
A client is configuration with a secret attached. Kept in a console, it drifts from the code that depends on it and its secret travels by chat. Kept as a manifest, it is reviewed, versioned and delivered with the app, and the operator handles the secret.
$ grep -E 'tokenEndpointAuthMethod|pkcePolicy' storefront-spa.yaml
tokenEndpointAuthMethod: none
pkcePolicy: optional
$ kubectl apply -f storefront-spa.yaml
The OIDCClient "storefront-spa" is invalid: spec: Invalid value: public clients (tokenEndpointAuthMethod 'none') must set pkcePolicy to 'required_s256'An OIDCClient sits beside the Deployment it serves: same repository, same review, same release. No ticket to an identity team, no console.
The secret goes from the server straight into a Secret the workload mounts. Delete the Secret to rotate it; the operator writes a new one and records the rotation.
Rules on the resource definition refuse contradictory clients at kubectl apply. The server checks again and reports a refusal on the resource, field by field.
The operator only sends manifests from the namespaces it covers, and the server only accepts the operations and organizations its identity is granted.
A client changed elsewhere is reported as Drifted and left alone until someone chooses to restore it, so a manual hotfix is never silently undone.
If the server stops answering, nothing is removed and nothing is retried in a storm. Resources wait, then catch up on their own. CI runs a client's whole life on kind, an outage included.
apiVersion: nauthera.io/v1alpha1
kind: OIDCClient
metadata:
name: example-webapp
namespace: storefront
spec:
clientId: example-webapp
redirectUris:
- https://app.example.com/callback
grantTypes:
- authorization_code
- refresh_token
tokenEndpointAuthMethod: client_secret_basic
pkcePolicy: required_s256
allowRefresh: true
secret:
generate: trueIs it for you?
Why not let apps register themselves?
Dynamic client registration (RFC 7591) is built for software meeting a server it has no prior relationship with. For your own apps it leaves the secret, the replicas and the clean-up to each app, and their metadata is only self-asserted. Operator or dynamic registration?
Not on Kubernetes?
Register clients from your own automation through the gRPC admin service, as nauthera-cli does, or by dynamic client registration, and read them through the admin REST API.
One email when the operator ships. No newsletter.
By joining, you agree to our Privacy Policy and Terms.