# Remove labels (or ownership) from secret **URL:** \ **Category:** Elastic Cloud on Kubernetes (ECK)\ **Created:** [August 3, 2021, 9:48am UTC](https://discuss.elastic.co/t/remove-labels-or-ownership-from-secret/280293 "2021-08-03T09:48:38Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![pkaramol](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pkaramol/32/22610_2.png) [@pkaramol](https://discuss.elastic.co/u/pkaramol)\ **Post date:** [August 3, 2021, 9:48am UTC](https://discuss.elastic.co/t/remove-labels-or-ownership-from-secret/280293/1 "2021-08-03T09:48:38Z")
I want to edit / remove those labels from the `elastic` user secret ```auto eck.k8s.elastic.co/credentials: "true" eck.k8s.elastic.co/owner-kind: Elasticsearch eck.k8s.elastic.co/owner-name: myClusterName eck.k8s.elastic.co/owner-namespace: elastic ``` However they seem to be kinda immutable despite successful execution of the following ```auto kubectl label secret myClusterName-es-elastic-user eck.k8s.elastic.co/owner-kind=None --overwrite ``` How can I go about this? ---
**Author:** ![legoguy1000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/legoguy1000/32/54301_2.png) [@legoguy1000](https://discuss.elastic.co/u/legoguy1000)\ **Post date:** [August 3, 2021, 11:54am UTC](https://discuss.elastic.co/t/remove-labels-or-ownership-from-secret/280293/2 "2021-08-03T11:54:57Z")
I would check the logs for the ECK operator. I suspect that it is reverting the changes for that secret. ---
**Author:** ![pebrc](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pebrc/32/101790_2.png) [@pebrc](https://discuss.elastic.co/u/pebrc)\ **Post date:** [August 3, 2021, 12:48pm UTC](https://discuss.elastic.co/t/remove-labels-or-ownership-from-secret/280293/3 "2021-08-03T12:48:49Z")
These are internal labels that are managed by the operator and cannot be removed. The operator will recreate them if they have been removed as it is watching these secrets for changes. We are using them to track ownership of those secrets without resorting to Kubernetes owner references [which can be problematic on older versions of Kubernetes](https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-common-problems.html#k8s-common-problems-owner-refs) if users copy the secrets to other namespaces. The credentials label is used to identify resources holding credentials and is a "user facing" label if you will. It can be used to [rotate credentials if necessary](https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-rotate-credentials.html). ---
**Author:** ![pkaramol](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pkaramol/32/22610_2.png) [@pkaramol](https://discuss.elastic.co/u/pkaramol)\ **Post date:** [August 3, 2021, 12:55pm UTC](https://discuss.elastic.co/t/remove-labels-or-ownership-from-secret/280293/4 "2021-08-03T12:55:03Z")
I want to delete and (re-create) the specified secret with the exact same name but with custom password for the `elastic` user. Is this feasible? When I delete it I don't have time to manually re-create it (it gets recreated by the operator apparently) This is why I tried to remove the above labels (thinking I would disassociate the ownership temporarily) Is there a way around this? ---
**Author:** ![pebrc](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pebrc/32/101790_2.png) [@pebrc](https://discuss.elastic.co/u/pebrc)\ **Post date:** [August 3, 2021, 2:14pm UTC](https://discuss.elastic.co/t/remove-labels-or-ownership-from-secret/280293/5 "2021-08-03T14:14:28Z")
You could temporarily [exclude the cluster](https://www.elastic.co/guide/en/cloud-on-k8s/master/k8s-troubleshooting-methods.html#k8s-exclude-resource) where you are trying to set the password from being managed by the operator. However, this is a bit hacky in my opinion. If you just want a user with a set password the recommended way would be to just create a new user in the so called [native realm](https://www.elastic.co/guide/en/elasticsearch/reference/current/native-realm.html#managing-native-users) via Kibana with the right permissions and password of your choice. ---
**Author:** ![pkaramol](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pkaramol/32/22610_2.png) [@pkaramol](https://discuss.elastic.co/u/pkaramol)\ **Post date:** [August 3, 2021, 2:44pm UTC](https://discuss.elastic.co/t/remove-labels-or-ownership-from-secret/280293/6 "2021-08-03T14:44:34Z")
Thanks. It is just we are trying to do the whole thing declaratively via GitOps (with encrypted secrets of course) ---
**Author:** ![pebrc](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pebrc/32/101790_2.png) [@pebrc](https://discuss.elastic.co/u/pebrc)\ **Post date:** [August 3, 2021, 2:58pm UTC](https://discuss.elastic.co/t/remove-labels-or-ownership-from-secret/280293/7 "2021-08-03T14:58:34Z")
> [@pkaramol](#): > > It is just we are trying to do the whole thing declaratively via GitOps (with encrypted secrets of course) For that case ECK has extra support for the so called [file realm](https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-users-and-roles.html) where you would declaratively set up your users in a secret that is managed and controlled by you (see my link) as opposed to trying to manipulate the secret of the built-in elastic super user. The elastic super user should not be used in day-to-day operations anyway and is more meant as an escape hatch for admins if things go wrong (or for experimentation in a POC etc) ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [August 31, 2021, 2:59pm UTC](https://discuss.elastic.co/t/remove-labels-or-ownership-from-secret/280293/8 "2021-08-31T14:59:19Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.