Set up Icinga2 automatically via Puppet

@lbetz: Thanks for your fast reply. I’ve changed it back to ticketsalt because of this points from @dnsmichi: https://github.com/Icinga/puppet-icinga2/issues/495

My code on my Puppet-Master for the Icinga2-Slave is this:

$master_cert = 'icinga2master.vorlage.local'
$master_ip = '192.168.117.30'

# get it on CA host 'openssl x509 -noout -fingerprint -sha1 -inform pem -in /var/lib/icinga2/certs/master.localdomain.crt'
$fingerprint = 'CC:90:41:24:D0:92:CA:C3:C8:A4:75:97:C7:32:CB:91:45:78:6H:28'


class { '::icinga2':
        manage_repo => true,
        manage_package => true,
        confd     => false,
        features  => ['checker','mainlog','notification','statusdata','compatlog','command'],
        constants => {
                'NodeName' => $facts['fqdn'],
        },
}

class { '::icinga2::feature::api':
        pki             => 'icinga2',
        ca_host         => $master_ip,
        ticket_salt     => '<ticketsalt>',
        ensure          => 'present',
        accept_config   => true,
        accept_commands => true,
        endpoints       => {
          'NodeName'       => {},
          "${master_cert}" => {
             'host' => $master_ip,
          }
        },
        zones           => {
          'ZoneName' => {
            'endpoints' => [ 'NodeName' ],
            'parent'    => 'master',
          },
          'master' => {
            'endpoints' => [ $master_cert ],
          },
        },
        fingerprint     => $fingerprint,
}

icinga2::object::zone { 'global-templates':
  global => true,
}

( ticket_salt => ’ <ticketsalt>’ is from /etc/icinga2/constants.conf )
(fingerprint ==> ‘CC:90:41:24:D0:92:CA:C3:C8:A4:75:97:C7:32:CB:91:45:78:6H:28’ is that value which I get when I execute ‘openssl x509 -noout -fingerprint -sha1 -inform pem -in /var/lib/icinga2/certs/master.localdomain.crt’)

…when I do then an ‘puppet agent -t’ the following /etc/icinga2/zones.conf will be created on my Slave:

# This file is managed by Puppet. DO NOT EDIT.

object Endpoint NodeName {
}

object Endpoint "icinga2master.vorlage.local" {
  host = "192.168.117.30"
}

object Zone ZoneName {
  endpoints = [ NodeName, ]
  parent = "master"
}

object Zone "global-templates" {
  global = true
}

object Zone "master" {
  endpoints = [ "icinga2master.vorlage.local", ]
}

(I don’t know the correct Syntax how to ask “ZoneName” and “NodeName” correct from hiera, do you have an idea? )

When I reexecute the command from @dnsmichi icinga2 pki ticket --cn worker-template.local
I got the same as this morning:

root@icinga2master:~# icinga2 pki ticket --cn worker-template.local
<ticketsalt>
root@icinga2master:~#

But I also have to say that I signed my Icinga2 node - which I created via puppet - on my Icinga2 master by hand and it worked.
Then I reset the Icinga2 node to test it again but the old Status of the VM is signed anymore on my Icinga2-Master…

Hope that’s all understandable what I’ve written…

@lbetz, @dnsmichi: Do you have any ideas? At the weekend I’ve tested again by resetting my Test-VMs to an old Snapshot an I’ve used the TicketSalt from my Icinga2-Master (/etc/icinga2/constants.conf):

/* Secret key for remote node tickets */
const TicketSalt = “<ticketsalt>”`

…and the Fingerprint from my Icinga2-Master (which I get via ‘openssl x509 -noout -fingerprint -sha1 -inform pem -in /var/lib/icinga2/certs/icinga2master.vorlage.local.crt’):

root@icinga2master:~# openssl x509 -noout -fingerprint -sha1 -inform pem -in /var/lib/icinga2/certs/icinga2master.vorlage.local.crt
SHA1 Fingerprint=CC:90:41:24:D0:92:CA:C3:C8:A4:75:97:C7:32:CB:91:45:78:6H:28
root@icinga2master:~#

When I have now an look in my Logs on the Icinga2-Master (/var/log/icinga2/icinga2.log) I can see the following at the time of my Puppet-Run / trying to connect from the Icinga2-Satelitte to the Icinga2-Master:

[2019-05-19 21:54:26 +0200] information/WorkQueue: #7 (IdoMysqlConnection, ido-mysql) items: 6, rate: 2.98333/s (179/min 931/5min 2761/15min);
[2019-05-19 21:54:46 +0200] information/ConfigObject: Dumping program state to file '/var/lib/icinga2/icinga2.state'
[2019-05-19 21:54:56 +0200] information/WorkQueue: #5 (ApiListener, RelayQueue) items: 0, rate: 0.7/s (42/min 197/5min 594/15min);
[2019-05-19 21:54:56 +0200] information/WorkQueue: #6 (ApiListener, SyncQueue) items: 0, rate:  0/s (0/min 0/5min 0/15min);
[2019-05-19 21:54:56 +0200] information/WorkQueue: #7 (IdoMysqlConnection, ido-mysql) items: 6, rate: 3.01667/s (181/min 933/5min 2823/15min);
[2019-05-19 21:55:01 +0200] information/ApiListener: New client connection from [192.168.117.25]:43078 (no client certificate)
[2019-05-19 21:55:01 +0200] warning/TlsStream: TLS stream was disconnected.
[2019-05-19 21:55:01 +0200] information/ApiListener: No data received on new API connection. Ensure that the remote endpoints are properly configured in a cluster setup.
[2019-05-19 21:55:02 +0200] information/ApiListener: New client connection for identity 'worker-template.local' from [192.168.117.25]:43080 (certificate validation failed: code 18: self signed certificate)
[2019-05-19 21:55:02 +0200] information/JsonRpcConnection: Received certificate request for CN 'worker-template.local' not signed by our CA.
[2019-05-19 21:55:02 +0200] information/JsonRpcConnection: Sending certificate response for CN 'worker-template.local' to endpoint 'worker-template.local' (auto-signing ticket).
[2019-05-19 21:55:02 +0200] warning/TlsStream: TLS stream was disconnected.
[2019-05-19 21:55:02 +0200] warning/JsonRpcConnection: API client disconnected for identity 'worker-template.local'
[2019-05-19 21:55:03 +0200] information/ApiListener: New client connection for identity 'worker-template.local' from [192.168.117.25]:43082 (no Endpoint object found for identity)
[2019-05-19 21:55:03 +0200] information/JsonRpcConnection: Received certificate request for CN 'worker-template.local' signed by our CA.
[2019-05-19 21:55:03 +0200] information/JsonRpcConnection: The certificate for CN 'worker-template.local' is valid and uptodate. Skipping automated renewal.
[2019-05-19 21:55:06 +0200] information/WorkQueue: #7 (IdoMysqlConnection, ido-mysql) items: 6, rate: 2.98333/s (179/min 933/5min 2824/15min);
[2019-05-19 21:55:12 +0200] information/WorkQueue: #11 (JsonRpcConnection, #0) items: 0, rate: 0.05/s (3/min 3/5min 3/15min);
[2019-05-19 21:55:16 +0200] information/WorkQueue: #7 (IdoMysqlConnection, ido-mysql) items: 6, rate: 2.98333/s (179/min 931/5min 2820/15min);
[2019-05-19 21:55:26 +0200] information/WorkQueue: #7 (IdoMysqlConnection, ido-mysql) items: 6, rate: 2.95/s (177/min 929/5min 2820/15min);

Did I understand correctly that the connection worked and the Icinga2-Satelitte is connected with the Icinga2-Master?

Hi,

while I appreciate all the details, I’ve lost track on what exactly is the problem now. Is it still the wrong PKI ticket being generated?

Yet again, you’ve shared your private TicketSalt again. Please avoid that in future postings, replace that with something like <ticketsalt>.

The logs look sane, the satellite wants a certificate and gets it auto-signed.

[2019-05-19 21:55:02 +0200] information/ApiListener: New client connection for identity 'worker-template.local' from [192.168.117.25]:43080 (certificate validation failed: code 18: self signed certificate)
[2019-05-19 21:55:02 +0200] information/JsonRpcConnection: Received certificate request for CN 'worker-template.local' not signed by our CA.
[2019-05-19 21:55:02 +0200] information/JsonRpcConnection: Sending certificate response for CN 'worker-template.local' to endpoint 'worker-template.local' (auto-signing ticket).

The only issue with connecting is that there’s no Endpoint object on the master yet.

[2019-05-19 21:55:03 +0200] information/ApiListener: New client connection for identity 'worker-template.local' from [192.168.117.25]:43082 (no Endpoint object found for identity)
[2019-05-19 21:55:03 +0200] information/JsonRpcConnection: Received certificate request for CN 'worker-template.local' signed by our CA.
[2019-05-19 21:55:03 +0200] information/JsonRpcConnection: The certificate for CN 'worker-template.local' is valid and uptodate. Skipping automated renewal.

That being said, TLS works, but the secondary level of trust is not yet configured - thus generating the Endpoint object for the satellite on the master. Similar thing as if you would manually edit zones.conf with a manual setup.

I would investigate into this direction if I were you.

Cheers,
Michael

1 Like

@dnsmichi: Thanks a lot for your fast reply :).

Hi,
while I appreciate all the details, I’ve lost track on what exactly is the problem now. Is it still the wrong PKI ticket being generated?

No, that seems to work fine now after I’ve used the Fingerprint at the TicketSalt from my Icinga2-Master (If I understood you correctly, does the output from the file /var/log/icinga2/icinga2.log mean that too, right?)

The only issue with connecting is that there’s no Endpoint object on the master yet.

[2019-05-19 21:55:03 +0200] information/ApiListener: New client connection for identity 'worker-template.local' from [192.168.117.25]:43082 (no Endpoint object found for identity)
[2019-05-19 21:55:03 +0200] information/JsonRpcConnection: Received certificate request for CN 'worker-template.local' signed by our CA.
[2019-05-19 21:55:03 +0200] information/JsonRpcConnection: The certificate for CN 'worker-template.local' is valid and uptodate. Skipping automated renewal.

That being said, TLS works, but the secondary level of trust is not yet configured - thus generating the Endpoint object for the satellite on the master. Similar thing as if you would manually edit zones.conf with a manual setup.

Okay, that sounds good :). But how can I configure the secondary level of trust that the Endpoint object will generated for the satellite on the master?
I don’t want to edit zones.conf manually but via Puppet…

Hope, everything is clear what I wanna do :)…

Thanks a lot and best regards,
Matthias

Similar to how you’ve created the profile for your satellite, the master also needs to have the zones and endpoints hash configured inside the API feature. @lbetz already pointed you towards the examples directory on GitHub, specifically this one:

Might also be worthwhile to look for a workshop, configuring Puppet and discussing things online really is hard.

Cheers,
Michael

hi @maze-m,

have a look on your other thread from me.

cu denny