Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pxc-db pmm configure pmmserverkey #1586

Open
weiss-m opened this issue Jan 8, 2024 · 4 comments
Open

pxc-db pmm configure pmmserverkey #1586

weiss-m opened this issue Jan 8, 2024 · 4 comments
Assignees

Comments

@weiss-m
Copy link

weiss-m commented Jan 8, 2024

We use the pxc operator password auto generation feature for pxc accounts like root, xtrabackup ...

Unfortunately, pxc operator can't auto generate pmmserverkey.
So we have to add the pmmserverkey manually to the existing k8s secret which already contains the auto generated passwords for root,xtrabackup ...
https://github.com/percona/percona-xtradb-cluster-operator/blob/main/deploy/secrets.yaml#L11
https://docs.percona.com/percona-operator-for-mysql/pxc/monitoring.html#install-pmm-server

This is a manual step which we would like to avoid. We are using argocd for deployment of several pxc clusters.
So, one option would be, to use kustomize to add pmmserverkey to the existing k8s secret. This is not an option for us because we don't store passwords in clear text in git.
We would like to use sealed secrets, but sealed secrets doesn't support addition of a key, value pair to an existing k8s secret.

Would it be possible to store auto generated and manual created credentials in separate k8s secrets?

@spron-in
Copy link
Collaborator

spron-in commented Jan 9, 2024

Hey @weiss-m ,

so let me see if I understand the problem:

  1. You deploy PXC with argocd
  2. You rely on auto-generated secrets for MySQL
  3. At the same time you use PMM and you don't have an easy automated way to add pmmserverkey into the generated secret.

Let me think how we can do that.
@hors @egegunes any thoughts?

@spron-in spron-in self-assigned this Jan 9, 2024
@weiss-m
Copy link
Author

weiss-m commented Jan 11, 2024

Just for my understanding, is the following assumption correct? The operator uses cluster-secrets as input and applies the password accordingly to cluster-secrets in the database and afterward applying it writes the passwords in secret internal-cluster ?
So in cluster-secrets is always the desired state? And in internal-cluster the current state?

@spron-in
Copy link
Collaborator

Yes, you are correct.

@ydixken
Copy link

ydixken commented Sep 19, 2024

Also raising this issue with the Percona Support, as we currently have to configure pmm manually (create the API key) on cluster creation, there should be a way to provide a pre-seeded api key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants