CheckMK Enterprise v2 Overview

I have a rhetoric question for MK architects:
Why you forget about enterprise users which bring the main income?

Weak points:

  • Secrets handling is absent.
    • All passwords stored in clear text in configuration( which prevents usage of IaC approach)
    • Passwords accessible in GUI by ‘inspect’ for users with access to WATO
    • No handling secrets handling in exceptions - it just throws your secret to alert
      Since you introduced the “password management” feature(which still using clear-text passwords) why not to implement integrations with hashicorp vault for example?
  • Plugin development:
    • Your mistake in the plugin can break all instances. So one typo can cause long downtime, since cmk -X is useless, and you have just a KeyError: ‘sql_function’ and no info what causes this.
    • Documentation - Publishing docs after release - ok then we just wasted time for migration after beta.
    • Examples of new v2 approach - probably just missed them.
  • Activation - Do you really need 30 seconds and reload core in 2021 to apply changes?

From strong sides:

  • Performance 4CPU&8GB RAM is enough for more than 1000 hosts.
  • Many things are ready out of the box
  • simple update process(But not available through UI)
  • local checks/ simple active checks scripts(with command line arguments)

From my perspective, there is only one reason to upgrade to v2 - python3. And often that reason would not enough for old complicated installations.
I would ask to share a community opinion, I am curious how that article corresponds to others.

Why should a third party product add any value here? The checks still need the credentials in plain text.

The password store does enough to hide the password from the GUI. And when you have access to the filesystem all hope is lost anyway.

Why don’t you use a development instance to develop extensions?

value - passwords saved in app designed to store them securely.
the system administrator doesn’t have direct access to them, can be rotated and updated with a centralized solution. Monitoring admins also only know a secret identifier.
Configuration is independent of secrets - can be stored in git shared or deployed without access to actual secrets.
So scheme when we have a wrapper function which retrieves a password from the vault, authenticate to resource and clean up a password is possible.

Of cause I use. But why not implement boundaries, that code from ~local can’t break monitoring. From my point of view, no plugin should interfere with the rest of the code. If the plugin is broken - we lost only this plugin, not the entire monitoring.

Then it is not possible to use any of the classic active checks. For only internal functions such an approach will work but not for the Nagios compatible active checks.

1 Like

Same approach as used now - in ruleset we have a password identifier which replaced with value on classical active check call. It less secure than a fully integrated approach, but will work as a compatible workaround.

How do you get the passwords from the Hashicorp vault?

Don’t you need some kind of authentication to be able to extract passwords from there?
Where are the credentials stored for this auth?

You only loose your development instance. And this can easily be fixed by correcting the last change you just made. Or by just creating a new development site.

Hi @bohdan.udovenko

thank you for your feedback! We depend on users and customers like you to keep pushing us to build a good product.

@r.sander and @andreas-doehler have already addressed some of what you said on a technical level.

As usual, many paths lead to Rome. And not in every case will we take exactly the path that a specific user (you, for example) would like us to take. That does not mean we are “forgetting about enterprise users” as you put it. Or any users, for that matter.

There are a number of features in the 2.0 that were built specifically with Enterprise users in mind, at based on their feedback - the REST API, more extensive Audit Logging, Distributed Agent Bakery, SAML authentication and a few others come to mind.

But, as always, we can’t do everything our users would like us to. So some things just don’t make the cut for this release because they may be “good enough for now” for the majority of our users - they way Checkmk handles passwords might be such an example. Others may just not be possible with the constraints (technical or other) we operate under. And there are also cases where our users request something, and we decide that it does not make sense to build this into Checkmk.

So bear with us and continue to give us feedback like that! We promise that we listen, even if we can’t immediately take care of everything!