Sooooo Got Percona setup and it’s working great, BUUUUT there is an issue.
The main admin account password is in plain text in:
/usr/local/percona/pmm2/config/pmm-agent.yaml
Which is fine for systems where a controlled set of people are root.
BUT I host some servers for other people, and I only want them to have VIEW access to Percona via their user account.
How can I hide/obfuscate or otherwise eliminate this password being in there in plain text?
SSH Key? Something like that? or anything?
Thanks,
Matt
1 Like
So I thought I had found a way around this with Orgs and Users,
So I created a new Org, made a new user, made the user an Admin of the new Org, but pmm-agent says invalid password when I update the config on that.
And when I switch to that Org all the dashboards say they cannot be found.
The node still belongs to the Primary Org, and I don’t see any way to move it to the new Org, so that the Admin access would apply.
Thanks,
Matt
1 Like
unfortunately orgs doesn’t work the way you (or I) would like them too…they’re sort of pseudo multi-tenancy but no real isolation of the data…just limiting what you’re exposed to…the downside is that you must install dashboards and graphs for each org and we do not do that by default (so you create a new ord, that’s an empty shell you can put dashboards that look at more (or less) filtered data compared to another org and you can limit peoples access/association to orgs…but not really security.
There is a way to hide that password and for the life of me I can’t find it…so I’m pinging a colleague but he’s 6 hrs ahead and should be enjoying family time so I scheduled the ping for first thing his morning…if he doesn’t post directly here i’ll post what he does to avoid users with (pmm-client) server access from reading that file and granting themselves pmm-server admin rights.
1 Like
Hi @Matt_Westfall
I am afraid that I’m not sure what Steve is thinking about to hide the password.
Which is fine for systems where a controlled set of people are root.
Are you allowing users to be root that shouldn’t have access to read the config? The file is written out as 0660 for the pmm-agent
user and group, but if you are allowing users superuser access then you are going to be up against it in terms of securing the file.
However, there is no reason to be using the admin account in the first place. The user for the agent simply needs Grafana admin, which is not a full admin account and so PMM-specific admin features are not visible.
To improve on that further, you could create an API key, where API keys have a TTL and thus allows you to rotate tokens with automation, e.g. create a process that does the following:
- Create API key with TTL x
- Register/configure instance using the API key
- Schedule task at interval x - y to call process
N.B. the API keys need admin privileges, but you can’t login to the UI with them
To take that a step further, you could generate API keys per instance to limit the scope of its usage not only in time but also to be able to revoke a single instance’s access without the need to reconfigure all of the other instances.
For reference:
- create the user via Server Admin → Users
- create the API keys via Configuration → Users → API keys
Going back to your original concern about the visibility of the config file content, you could try the following (completely untested):
- Override the systemd unit file to add
ExecStartPre
and ExecStartPost
ExecStartPre
will read from a secure provider to retrieve the password and update the YAML
ExecStartPost
will remove the password from the YAML
1 Like
Well these are customer machines, so they have root on their machines, but I want to put them in Percona. And I don’t care if they can see everything IN Percona, just not change and mess with things.
API Key should be perfect.
Do I just put the API Key in place of the password in the pmm-agent config file?
Thanks,
Matt
1 Like
Actually just using Grafana admin should work fine, because they would obviously know their own password to login and view anyway
1 Like
So, the API keys are used as follows… whichever way that you are doing things:
managing the config file
server:
username: api_key
password: <insert the base64-encoded key that is generated>
pmm-admin
pmm-admin config --server-url=https://api_key@<insert the base64-encoded key that is generated>@<server ip>:<server port>/
pmm-agent
pmm-agent setup ... --server-username=api_key --server-password=<insert the base64-encoded key that is generated> ...
N.B. the API keys need admin privileges, but you can’t login to the UI with them
However, as these do require the admin role, they could be used with the API to change things.
Actually just using Grafana admin should work fine, because they would obviously know their own password to login and view anyway
1 Like