結論

Operatorが管理するリソースを手で直しても、reconcileで元に戻ります。直すべきは、Operatorが入力として見ている「原本」です。

何が起きたか

OpenShift上のある製品でカスタムドメイン名を変更したら、ログインが401で通らなくなりました。原因は内部通信用のCA証明書が新旧で食い違っていたことです。

そのCAを保持しているConfigMapを手で書き換えると、401は消えます。ところがしばらくすると再発し、ConfigMapを見ると古いCAに戻っていました。直す→戻るを何度か繰り返して、ようやく「直す場所が違う」と気づきました。

なぜ巻き戻るのか

この製品では、証明書が3層のチェーンで管理されていました。

Operatorは「あるべき状態」を定期的に原本から作り直します。ConfigMapだけ直しても、次のreconcileで原本の旧CAがコピーされ戻ります。原本のSecretを直せば、reconcile後も新CAが維持されます。

直し方

原本のSecretを更新し、reconcileを待つと派生物まで自動で伝播します。

# 現状を保存（type の確認も兼ねる）
oc get secret <cert-secret> -n <namespace> -o yaml > cert-secret-backup.yaml
oc get secret <cert-secret> -n <namespace> -o jsonpath='{.type}{"\n"}'

# 中身だけ差し替える（type / labels / ownerReferences を保持）
oc patch secret <cert-secret> -n <namespace> --type=merge -p "$(cat <<EOF
{"data":{
  "ca.crt":"$(base64 -w0 ca.crt)",
  "tls.crt":"$(base64 -w0 tls.crt)",
  "tls.key":"$(base64 -w0 tls.key)"
}}
EOF
)"

# チェーンが繋がっているか確認（中間CAがある場合は -untrusted intermediate.crt を追加）
openssl verify -CAfile ca.crt tls.crt

oc delete → oc create で作り直すと、Secretのtypeが Opaque に変わったり、ownerReferencesが消えてOperatorにデフォルト値で再作成されたりします。中身だけpatchするのが安全です。

派生のConfigMapや成果物には手を触れません。原本が正しくなれば、Operatorが下流を作り直してくれます。

ハマりやすい点

同名・別鍵のCA。 新旧のCAがCNまで同じで鍵だけ違うことがあります。名前で見ると「同じCAだ」と誤認しやすく、証明書検証の失敗を長く追う羽目になります。発行日や鍵の指紋で区別してください。

副次エラーに釣られる。 証明書チェーンが切れると、認証やアプリ層で別のエラーコードが出ることがあります。表面のエラーを追うと迷子になります。ログを時系列で並べ、どのエラーが他方を引き起こしているのか因果を追うのが早道です。

派生物が新しくなっても反映されない。 トラストストアは起動時に読み込まれることが多く、ConfigMapとp12が更新されても参照側のPodは旧トラストストアを掴んだままです。伝播を確認したら、参照側をrolloutしてください。

まとめ

Operator管理下のリソースを手で直すときの手順です。

派生物には ownerReferences が付くので、それを辿って原本を特定する
派生物ではなく原本を直す
reconcileで派生物まで伝播したことを確認し、参照側Podをrolloutする

「一時的に直ったのにしばらくすると戻る」なら、原本ではなく派生物を直している可能性が高いです。