TrustAnchorUnavailable
Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program
The operator has no usable CA to verify the server with; its pod is not ready, and a resource it reconciles is Ready=False, Pending.
Meaning
The file --server-ca-file names is missing, unreadable, or holds no PEM certificate. The
message names the file. With the chart it is ca.crt in the operator's credential Secret
under /, or the key operator.server.caKey of
operator.server.caSecret under /. An issuer that is not a
CA (an ACME issuer) writes no ca.crt, which is the usual cause.
Impact
Nothing reaches the server: no OIDCClient is registered or updated, no secret is delivered,
no deletion under Delete completes. Registered clients keep working for their
applications and end users. Every application team using the operator is blocked.
Diagnosis
kubectl -n <release-ns> logs deploy/names the file.<release>-operator | grep 'control plane not reachable' kubectl -n <release-ns> get secret <secret> -o jsonpath='{.shows whether the key holds a certificate.data. ca\. crt}' | base64 -d | openssl x509 -noout -subject kubectl -n <release-ns> describe pod -l app.for a volume that failed to mount.kubernetes. io/ component=operator
Mitigation
- With the chart's own keypair (
certManager.), itsgrpcTLS. client. enabled ca.crtis the control plane's CA: check the Certificate is Ready and the Secret was not replaced. - With your own credential Secret and no
ca.crtin it, put the authority that issued the server's gRPC certificate in a Secret and setoperator.server.caSecretandoperator.server.caKey.
Escalation
Escalate to the platform team that owns the operator's release. If the file holds a valid PEM certificate and the reason persists, open an issue with the condition message, the operator's version and the CA certificate's subject and fingerprint. No private keys.
Operator failure reasons · Generated from operator/ in nauthera-server.