To register a host, users need the following permissions:
<li>Read access to the host, either via "Read access to all hosts and folders" or via via contact groups.</li>
<li>Write access to the host, either via "Write access to all hosts and folders" or via "Modify existing hosts" and write access to the specific host via contact groups.</li> </ul>
We use in our organization tools like Ivanti or RedHat Satellite to automate the deployment of new systems or new software. To automate registration I need to hand out the access credentials to several teams which must not have access to monitoring configuration. Probably e.g. an Ivanti package could be dissolved and anybody having access to the content of this package has then also access to the agent registration credentials.
If the automation user now needs full write access to all hosts I may grant almost anybody in our global IT to add/remove hosts or folders in our monitoring systems which is not acceptable.
I like to discuss with you if I maybe overlocked something and how you plan to manage this change.
I support your doubts, @AndiU I think we talked about this shortly at the conference. This seems like a security issue if one wants to use TLS registration in practice with larger environments where manual registration is not feasible.
The workaround using a third host to register the tls certificates and distribute them afterwards seems rather complicated as you then need to figure out how this third host gets access to all hosts to be monitored.
Actually there is no doubt. In most cases this is not acceptable. Therefore currently the automatic deployment of the agent registration is not feasible if the access to the initial deployment package cannot be controlled. This would require a more fine-grained permission. So @AndiU or who ever is responsible for the permission system needs to look into this problem.
If this constraint remains we cannot use agent updater anymore or at least we cannot use the TLS encryption which would be very welcome as the current symmetric encryption is also not save.
I didnt had a closer look to this new feature because I am still fully busy with 2.0 upgrade, so please apologize in case writing nonsense.
Could it maybe an option that the agent do some kind of pre-registration and finally a user with sufficient rights is doing the final step in GUI Setup? There could be a view with a list of all pre-registered agents filtered by access rights of the user. Its not fully automatic anymore but anyway the user who is responsible for the host needs to do some configuration stuff on the host. So the effort would be acceptable.
Thanks for the great discussion here guys! We already started discussion on this internally.
I know you know this, but just to clarify and to keep everyone on the same page:
The agent update registration is not affected by this discussion, permissions there are already granular
We are talking about the registration for TLS encryption between server and agent
That being said, I want to make you aware of the so-called registration by proxy. I know it has already been mentioned, but I want to stress this. This method allows you to run most of the registration process on the Checkmk server, and then you only need to transfer the resulting file to the system to be registered and import it there. I do realize that this is not perfectly automatable, but if you implement a smart process, this should work well in the environments outlined here.
To conclude: We are already discussing tightening the permissions concerning the registration process for TLS, so the suggested alternative is not the last word here. Maybe some of you can give it a try and let me know, how it went.
Thanks for your hint but also proxy-register will not work in any case because the user who has access to the console of the host must not have access to the monitoring configuration.
As we have a fully automated deployment process I even don’t see the benefit because as far as I understand an automation user with write access is still needed.
I hear you. I was hoping you might find a smart way for your processes, but I do get the challenge.
There is one more thing: The Werk you quote already states, that the user used for the registration process does not have to have full read/write access to all hosts. It is possible to use a user, that can only access hosts based on their contact groups.
Again it depends on your specific environment, if that scales for you, but at least security-wise this is way better than full access, and you are empowered to decide which approach you want to pursue.
We have a dedicated team working only on monitoring configuration. The teams working on system operation must not have access to the monitoring configuration and the monitoring team must not have access to the systems.
Sorry for jumping in on an “old” thread but this just stoke me as I’m trying to register agents with automation (windows and linux) and we are in the same situation as mike1098 that we have a clear segregation of duties (Part of ISO27000) and can’t give any automation read/write access to the hosts in checkmk as the automation spawns multiple teams.
If this can’t be fixed we won’t be able to use TLS at all.
I am currently busy with updates to 2.0 but as soon as I have time I will verify this and open an official ticket. If one can do it before I would be happy. Let me know in case you need support from my end to push this.
It definitely needs to be fixed. That’s an absolute no-go.
Same here, quite busy with 2.1 but yes I think I will need to create a case.
There was also a issue defining what role is actually required, even after adding the correct contact group and adding “Modify existing hosts” to the automation user I was not able to register. I had to revert back to cmkadmin to get it to work.
it was also not clear if you could use an automation user as the TLS registration command expected a password and you “only” have a secret. Compared to the agent update registration you have to use the -P or -S options while supplying password or secret. More confusion
For a user to be able to do the cmk-agent-ctl register, which is needed to enable the TLS encryption (available from 2.1.0 onwards), you have to add the following rights (internal name “general.agent_pairing”) to his/her role.
We needed to make a few architectural changes to get this working in the more general context that we’ll have in the 2.2 CCE.
We are not done yet, and this may still be subject to change, but I thought I’ll let you know what we’re planning currently, so you can provide feedback.
In Checkmk 2.1 things will not change, and 2.1 agent controllers out there will continue to work with Checkmk 2.2 (but probably not with Checkmk 2.3).
In Checkmk 2.2 we also have the CCE, where we are not only talking about the registration of existing hosts, but also about cmk-agent-ctl regsiter-new, a command that will create a host in the site and register to it (if the site is set up for it). For this and the existing case we plan to introduce 4 new permissions for agent registration (the “Agent pairing” permission is no longer relevant). With these new permissions you can do nothing but the operations mentioned here.
For cmk-agent-ctl register (registration of an agent controller to an existing host) the user needs to fulfill (at least) one of the following conditions:
They have the “Register any existing host” permission
They have the “Register managed existing hosts” permission and are in a contact group of the host in question
They have actual read/write access to the host, either via “Write access to all hosts and folders” or via “Modify existing hosts” and write access to the specific host via contact groups.
For cmk-agent-ctl register-new (triggering an automation that ultimately creates a host on the site, registers the agent to it, discovers the a host and activates the changes) the user needs to fulfill
(at least) one of the following conditions:
They have the “Register any new host” permission
They have the “Register new hosts in managed folders” permission and are in a contact group of the folder in question
They have actual read/write access to the folder, (either via “Write access to all hosts and folders” or write access to the specific folder via contact groups) and all permissions required to do the implied actions (create the host, register it, discover services, activate the changes)
Note that the “Register new” permissions will not allow you to perform any of the mentioned actions outside of the scope of the processes triggered by the agent controller command.
Again: This is preliminary, not a documentation. But I’d like to hear your feedback.
I’m wondering if splitting the permissions a tiny bit further would make sense. If I understand the permissions correctly, it won’t make a difference if the host a user tries to register has been registered before. I think when it comes to a user that is used in scripts and whose password is hence possibly widely accessible, it would be nice to only allow the “initial” registration but no kind of “re-registering”. I.e. once a host has been registered as “db01” and handed it’s TLS certificate, you can’t simply register another host claiming to be “db01”
(Come to think of it though, I think this is less of an issue for TLS registration and more for the bakery, where another host claiming to be “db01” could actually download an agent that it shouldn’t have access to. Maybe however it is also an issue for TLS registration once the push-agent comes into play, where suddenly another host could claim to be “db01” and sent malicious/misleading agent output incl. piggyback data.)
I see what you mean; but to be honest I am not sure if it’s worth it (in the sense that every feature increases the complexity, and the time needed on both sides, devs and users, to handle everything correctly). But there is this limitation, currently, as you correctly observed. It may be smaller than you think though, I’m not sure:
What you can do currently is
Create an automation user to bake agent packages that will automatically create the host object in the monitoring and register themselves when they are installed on a host. The secret contained in the agent package can not be used to re-register. Ultimately the site decides which hosts to create where (hosts can not be overwritten!).
Create a user that can only register to existing hosts, but not create hosts in this automated manner.
What you can’t do is create a user that can register to an existing host, but only once (or only the first time, which is not the same). You could create a user that is allowed to register, and then just remove it after a short period of time…
About this I have a question:
As far as I know only the site to which the agent is registered can poll the agent. In a distributed environment with disabled Setup this means the registration hast to be done with the remote site. Will then the host created twice on master and on remote site or how does that works?