Remove labels (or ownership) from secret

Elastic Orchestration Elastic Cloud on Kubernetes (ECK)
1

I want to edit / remove those labels from the elastic user secret

    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

kubectl label secret  myClusterName-es-elastic-user eck.k8s.elastic.co/owner-kind=None --overwrite

How can I go about this?

2

I would check the logs for the ECK operator. I suspect that it is reverting the changes for that secret.

3

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 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.

4

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?

5

You could temporarily exclude the cluster 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 via Kibana with the right permissions and password of your choice.

1 Like
6

Thanks.
It is just we are trying to do the whole thing declaratively via GitOps (with encrypted secrets of course)

7

For that case ECK has extra support for the so called file realm 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)

1 Like
8

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.