Autonomous operator: update spec.authSecret for existing couchbase server

Does the autonomous operator support spec.authSecret change after cluster creation?

I tried the next approaches:

  • Update secret data for the existing cluster -> nothing happened.
  • Create a new secret (with a new name) and modify the cluster manifest. Got an error from operator admission controller

error: couchbaseclusters.couchbase.com “XXX” could not be patched: admission webhook “couchbase-fabric-couchbase-admission-controller.couchbase-fabric.svc” denied the request: validation failure list:
spec.authSecret in body cannot be updated

with kubectl replace -f:

Error from server: error when replacing “/tmp/kubectl-edit-yasey.yaml”: admission webhook “couchbase-fabric-couchbase-admission-controller.couchbase-fabric.svc” denied the request: validation failure list:
spec.authSecret in body cannot be updated

What do you think about providing an option that provides user management capabilities with an operator in a declarative way with CR?

PS. operator’s code isn’t open-sourced right? Is there any change to see the code in the future?

1 Like

Passwords cannot be rotated at present. This is a complex problem. Consider if the secret were changed while the operator were not running, on restart it would fail to even submit the request because it no longer knows about the old password to authenticate against the API. We may allow online-only password rotation – so the Operator knows both the old and new password – at some point in the future once we have determined and documented all the different permutations, and what could possibly go wrong for users.

My suggestion is to kubectl exec onto a pod and run couchbase-cli reset-admin-password. Modify the authentication secret with the new credentials, then restart the Operator to refresh the client with the new credentials.

You are right, the Operator is a licensed enterprise-only product, is not publicly available and will not be placed in the public domain for the foreseeable future.