Check for validity of CA

widhalmt commented 4 years ago

Due to the nature of containers on the one hand and Icinga 2 on the other hand, we have a higher risk than usual for losing CA files. (thanks to @bodsch for your feedback on this topic)

We have to make sure that every instance checks the local information about the central Icinga 2 CA.

What to do if the container runs the config master but the CA is broken? How to detect reliably? What to do if it's broken? Output an error? Rebuild it?
If a satellite or agent has already pulled the CA certificate but it's not valid anymore (e.g. because someone replaced the CA on the config master), pull the CA cert again and request a new certificate

In my opinion we should not:

Check for validity in running containers on a regular basis. If the CA breaks, just restart the container
Allow for deploying custom CA files on the config master. While it's something, some users (especially enterprise-size) sometimes request, there's no benefit from using certificates signed by a company CA safe for not having to discuss how certificates work. And there are lots of potential pitfalls when a custom certificate file is used - so I would opt against allowing replacing them.

bodsch commented 4 years ago

Another possibility would be to store zertificate and CA in a key-value memory (like consul).

Al2Klimov commented 3 years ago

Which "higher risk"?

bodsch commented 3 years ago

"higher risk" means a user destroys the Icinga master or - worst case scenario - deletes the CA.

The latter has happened to me more than once because people didn't want to deal with the architecture.

Al2Klimov commented 3 years ago

You mean they destroy the container including the /data volume?

Which architecture and why they didn't want to deal with it?

bodsch commented 3 years ago

correct. both the container and the volume in which the data was stored were destroyed.

Take any AWS instance and a team that doesn't understand the Icinga architecture. There are more than enough of the latter.

Al2Klimov commented 5 months ago

Actually Icinga checks the CA (along with the complete chain) on every single cluster connection attempt. Failures are logged of course. The CA is an essential part of the cluster trust architecture, so I'm afraid we can't do this:

someone replaced the CA on the config master), pull the CA cert again and request a new certificate

We can't distinguish between on purpose rotation, volume defect and MITM. Also, with a KV DB we'd just move the single point of failure. Long live backups!

Icinga / docker-icinga2

Check for validity of CA #6