Hi Michael, > I’d then recommend not to use the Puppet-CA, but a different method to create > and sign certificates for the Icinga2 cluster. > https://github.com/icinga/puppet-icinga2#ca-and-certificates
My thought was, it may possible to sign / import / whatever the certificates from the CA which is used by Icinga master on the satellites (in that case, by the CA from Puppet master at the office), so that the satellites trusts the master and vise versa. The agents trusts only the satellites. For me it sounds like, what Lennart wrote: (sorry, German only) https://blog.netways.de/2017/05/05/icinga-2-best-practice-teil-5-autosign-von-zertifikatsanfragen-in-verteilten-umgebungen/ > Opinions on that differ of course. Otherwise I would use the "build in" CA from Icinga2. >> >> The next thing is, that we don't have PuppetDB on DC1 and DC2 running, until >> we can make sure, that no passwords or other secrets are stored in plaintext >> for example in PuppetDB itself. It makes hiera-eyaml useless. I think, >> without PuppetDB I have to add just more lines to the manifests and/or hiera >> for creating the the correct agent -> satellite Icinga configs for DC1 and >> DC2. On the Icinga master side, I hope to find the right lines, to add the >> zones for the DC1 and DC2. The example4 >> (https://github.com/Icinga/puppet-icinga2/tree/master/examples/example4) >> have some Puppet examples for have external zones. I'm not sure, how to >> integrate them in my setup, without breaking anything ;-) >> > So to speak, the example uses exported resources and those require the > PuppetDB (just as explanation for others who can’t follow why it’s about > PuppetDB here). Yes, but only on the Icinga master side. Problem is here especially with the PuppetDB, that it holds nearly all passwords in cleartext, while all sensitive datas are saved in hiera-eyaml on the file system :-/ I have at the moment zero ideas, how to handle it, like saving passwords for snmp3 and/or checks other user credentials for service checks. Databases for example are O.K, because MySQL/PSQL .... can use files for getting passwords ... ( I have also posted the question on puppet-users: https://groups.google.com/forum/#!topic/puppet-users/ebTUra_xosM ) > Are those Puppet servers in DC1 and DC2 standalone Puppet masters, or how do > they relate to your central Puppet-Master? That will be hard to maintain if > the Puppet agent would need to 2 different parent locations (I doubt this > works and is safe). From that point of view, all of these instances are > isolated on their own, and likely should be treated as such. Yes, standalone. That is a requirement for the PCI DSS (https://www.pcisecuritystandards.org/minisite/en/). Office -> PuppetMaster-Office DC1 -> PuppetMaster-DC1 DC2 -> PuppetMaster-DC2 The only relation they have, is the same Git repo. Nothing more. So all three are completely independent. > How does one manage these Puppet environments without Icinga 2 currently? I hope, I understand the question ... At the office we running all the test and dev servers, so adding a new server is like every Puppet workflow: 1. Sysops add new manifest to the Git and push it to the repo on the Puppet server at office 2. Than running Puppet agent on the new server ... and testing ..., after testing / development is fine 3. The manifest would be copied from ENV dev to ENV live and values like hostname / IP / firewall would be changed afterwards 4. git commit ... 3. On the DC the new production server would be installed 3. The Puppet git repo on DC gets synchronized (git pull via SSH and two faster auth (yubikey)) 4. Now the manifest for the new live server is available on the DC Puppet master 5. Run Puppet agent ... That is the workflow for all DCs we have. So all depends on the Git repo, but nothing more. Back to Icinga2, it was first clear .... and saw no problems at the beginning, but It seems that a distributed/decentralized Icinga2 setup with Puppet isn't possible. The only way I think is: 1. Keep office Icinga master as it is with Puppetdb and for dev/test env 2. Create Icinga2 satellite/agent Puppet profile, which installs the Icinga2 and make use of Puppet templates for zone.conf/icinga2.conf 3. Create a plain directory which is recursive synchronized for Icinga2 /etc/zones.d/<DC>/<hosts>.conf In that way, I have to only get the certificate setup running in the correct way. The rest comes over the Icinga2 API, right? It is far a way from a dream setup, but usable I think. Any conclusions or other ideas ? cu denny _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
