Operator Status

The Nauthera operator is meant to make Kubernetes manifests the source of truth for OAuth clients and their sign-in branding. It will reconcile them into nauthera-server through the gRPC AdminService. It does not reconcile anything yet. This page describes what exists and what is still to come.

#What exists today

The manager runs controller-runtime with leader election, metrics on :8080 and health probes on :8081. No reconcilers are registered yet, so creating an OIDCClient or a Branding object has no effect on the server.

#Connecting to the server

Whoever deploys the operator configures where the server is and how to reach it. This is operator configuration, not a custom resource:

The operator calls GetServerInfo every minute (every 15 seconds while the call is failing) and re-reads the three files each time, so a renewed certificate is used without a restart. Its /readyz includes a control-plane check that fails with a reason (Unreachable, Refused, CredentialUnavailable or TrustAnchorUnavailable). It also logs which server build answered.

On the server side, the operator's certificate common name must be listed in server.grpc.tls.allowed_client_identities. In the Helm chart, that list is certManager.grpcTLS.allowedClientIdentities, and the production profile allows nauthera-operator.

#With cert-manager

A Certificate in the operator's namespace produces a kubernetes.io/tls Secret that holds exactly the three files the operator reads. Mount it without subPath, so the kubelet refreshes the files when cert-manager renews them.

Known limitations:

• The issuer must be able to reach the operator's namespace. The server chart's internal CA is a namespaced Issuer. Use a ClusterIssuer, or run the operator in the server's namespace.
• ca.crt needs a CA-type issuer (CA or self-signed). ACME issuers do not fill it in, so supply the trust anchor from another Secret.
• The server does not reload its own gRPC certificate or client CA yet (#443). Restart it before the old certificate expires, or the operator reports Unreachable.
• Rotating the CA itself is not seamless. Distribute the old and new CAs together (for example with trust-manager) until every certificate has been reissued.

#What reconciliation will look like

The resources are already shaped for the planned workflow:

• spec is owned by the operator and status by the server. The server's etag lets the operator tell its own writes from someone else's, and refuses a write that would overwrite another manager's change.
• With secret.generate: true, the server generates a client secret and returns it once. The operator will write it to a Kubernetes Secret and record it in status.secretRef (#386).
• Deleting a manifest will have defined consequences for the client it registered (#387).

Further planned work: making the control plane safe for more than one operator (#378), configuring a central server from downstream clusters (#379), letting security constrain what developers may register (#380), and noticing when a resource changes outside the operator (#408).

#In the meantime

Register clients with the gRPC AdminService or dynamic client registration. See Clients. The resource references are here:

• OIDCClient
• Branding