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.
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.
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.
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.
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!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact @fayepal if you think this should be re-opened.