I have built a cluster with Username / Password in security section for CB 6.5 helm charts.
Now since the cluster is ready I want to update the secutity sections to use adminSecrets instead Username/password .
Can I do that w/o rebuilding the cluster and impacting any data or node/port associated with all the k8s services ?
Hi, so by default, the chart will create a secret for you (based on the username and password supplied in the chart). It will be named the same as your helm deployment, so if you do helm install foo, it will create a secret called foo.
Therefore, to create a cluster with admin credentials that are not created by the helm chart, if the cluster is named foo, create a secret named foo in the namespaces you wish to create the cluster in, with the username and password keys populated.
To update to “doing your own thing” on an existing cluster, the same applies, do nothing, unset the password in the chart and it will still function, using what is already set. The helm chart will always use the chart defined username, so ensure the secret and chard variable match, Also you cannot change the admin username.
I should point out that changing the password is not supported until 2.1 is released.
Thanks for the clarification . however I am not sure if my questions directly addressed , I may be missing something .
Here is details :
cluster-dev created with username , password in helm while we did helm install
I have created a separate secrets.yaml to create username and password and it looks like below and I named it cb-secret
I want to use helm upgrade to refer adminSecret: cb-secret and remove username and password and redeploy cluster and nothing in the existing cluster should be impact including service / ports / names /data
I am getting error during helm upgrade : :
spec.authSecret in body cannot be updated
My operator chart version :: couchbase-operator-2.0.1 . I wonder if this is allowed if yes then what I am doing wrong here
It is not possible to replace the the secret name yet. You have to either:
Pre-create it with the same name as the cluster, as I stated above
Reuse the one created by the Helm chart. Removing the “password” attribute from values.yaml will have the effect of “unamanaging” it
If you wish to change the password, you must wait until Operator 2.1 is released. Or if you cannot wait, stop the operator, manually update the password in the UI, update the secret password, restart the operator.
I guess I am not replacing secret-name , I am trying to replace username, password combination with adminSecrets .while cluster being up and running . Internally yes username and password will be hold inside adminSecrets .
Are you saying pre-create the secret like 'couchbase-cluster-dev-couchbase-cluster-dev ’ for my below example and then do refer it into chart with adminSecret: couchbase-cluster-dev-couchbase-cluster-dev and then do helm upgrade ?
As I tried already with adminSecret: cb-secret and it doesn’t work with error stated earlier
k get cbc
NAME VERSION SIZE STATUS UUID AGE
couchbase-cluster-dev 6.5.1 6 Running 9cecc6d7b0530c480a6dc9eae9a64931 23h
k get secrets
NAME TYPE DATA AGE
backup-couchbase-cluster-dev-token-t9m88 kubernetes.io/service-account-token 3 23h
backup-couchbase-operator-dev-couchbase-cluster-token-wnks6 kubernetes.io/service-account-token 3 2d18h
cb-secret Opaque 2 26h
couchbase-cluster-dev-couchbase-cluster-dev Opaque 2 23h
couchbase-operator-dev-cboperator-token-zmpvk kubernetes.io/service-account-token 3 2d18h
couchbase-operator-dev-couchbase-cluster-operator-tls Opaque 1 2d18h
couchbase-operator-dev-couchbase-cluster-server-tls Opaque 2 2d18h
I have build 4 cluster already with username , password and for the security compliance reason I have to change them to use adminSecrets . I don’t want to wipe the cluster and start fresh installation again . so thinking helm upgrade will help .
There is not a lot you can do. The name of the secret is now fixed.
The username and password only actually exist in “plaintext” in your laptop, or wherever your values.yaml file lives. It should be safe to remove the password field and run upgrade. If the values.yaml lives in change control, as I say it will use whatever is already set in the Kubernetes resource if you undefine it.
As I say, if you want to change the password, either wait until 2.1 is released, or follow the manual steps outlined above.
Again I am not changing the password … I am trying to replace password / username Yaml specification with adminSecrets specification. I will try to your point from above and I assume you are saying this is not possible until Operator 2.1 ?
@eldorado - I can understand a bit of the confusion here, so let me try from a slightly different angle: @simon.murray please correct me in case I get it wrong
When you setup the clusters in the first place, even though you supplied a username and password, the Operator automatically turned those credentials into a secret which is created automatically. You should be able to see that the secret exists and there is nowhere that the actual username and password are currently stored.
There actually isn’t a need for you to “switch” from a user/pass setup into one using adminSecrets…it’s already done. When you want to make other changes/modifications to that cluster, you should be able to just remove the data in the ‘password’ field of your helm chart and apply whatever update you are trying to perform. Our Operator will automatically identify the fact that there was a pre-created secret and re-use it.
Unfortunately at this time you cannot change the username, password nor secret after a cluster has been deployed. This is something planned for a later release (i.e. user and password rotation).
At the moment, going forward, it would be best if you supplied your own adminSecret in the first place…but for now those clusters that you have already deployed are using a secret already, it’s just one that we created for you and will continue to use for future changes.
this is pretty clear perry and I understand the completely theory behind it . Thank you !
In short I can do helm upgrade now but has to use pre-config cb supplied automated secrets which will take care of things.
Now looks like I can’t change password inside the automated cb provided secret and got that it would be next release.
Sorry @simon.murray . you may be saying same thing but I was not getting . my bad
Appreciate both of you
Now my last questions how this secret password tied with CB Admin Console UI password ?
I believe it will be same initially but if I want to change Administrator password in Console should be updating secrets or no ?
I have seen its not updating secrets … is that separate flow managing password for UI Admin console ?
Sorry, I missed this last question. I’d hold off doing any password rotation for a few more weeks…
We have native support for this coming in Operator 2.1. What will that look like? Simply put, just change the password in the admin secret, the Operator will change it for you in Couchbase Server, and the same password can then be used in the UI to login.