Security concerns with Checkmk Werk 14079

Hello Community,

I am a little concerned about Werk 14079.

To register a host, users need the following permissions:


<li>Agent pairing.</li>

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

Thank you for your contribution



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.

@os-s what’s your take on this :)?

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.

1 Like

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.

1 Like

Hello Robin,

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.