SecretPadded

Docs version v1 (main) · Nauthera is pre-1.0, in a design-partner program

An IdentityProvider's or OIDCClient's client secret, or an LDAPDirectory's bind password, begins or ends with whitespace; the resource is Ready=False, Error, and nothing is sent.

#Meaning

The value under spec.clientSecretRef.key begins or ends with whitespace, usually the trailing newline echo or a pasted value leaves. No provider issues such a secret and every provider refuses it, so the operator does not register it until it is removed. An LDAPDirectory reports the same for a padded bind password, and an OIDCClient for a padded value under spec.secret.secretRef.key, which no client would send.

#Impact

The organization's end users cannot sign in or sign up through this provider if it was never registered; an existing registration keeps its previous secret.

#Diagnosis

1. kubectl -n <ns> describe identityprovider <name> names the Secret and key, as the admin dashboard's Problems page does.
2. kubectl -n <ns> get secret <secret> -o jsonpath='{.data.client-secret}' | base64 -d | tail -c 1 | od -c shows the last byte without printing the secret.

#Mitigation

• Write the value again without the whitespace: kubectl -n <ns> create secret generic <secret> --from-literal=client-secret="$(printf '%s' "$VALUE")" --dry-run=client -o yaml | kubectl apply -f -.
• Fix the source (a secrets manager entry, a script using echo) so the next sync does not add it back. The resource is reconciled when the Secret changes.

#Escalation

The team that owns the provider's credential fixes the value. Escalate only if the value has no surrounding whitespace and the condition stays.

Operator failure reasons · Generated from operator/internal/runbook/conditions.yaml in nauthera-server.