Node setup possible without connection from agent to master

Hello Icinga Community,

does anybody know if there is a way to make a node setup for a agent without a connection from the agent to the master? We would like to only allow the connection from the master to the agent node what works pretty well for the monitoring but I can not find a way to make the node setup without a connection from the agent node to the master cluster once?

Best regards,
Alicia

You can create the certificates manually on the master (in a directory which is writable for the icinga user)

icinga2 pki new-cert --cn server.foo.bar --key server.foo.bar.key --csr server.foo.bar.csr
icinga2 pki sign-csr --csr server.foo.bar.csr --cert server.foo.bar.crt

and then copy the certificate and the key into /var/lib/icinga2/certs on the agent node
The ca.crt from /var/lib/icinga2/ca may be needed as well.

Make sure that the cn in the certificate matches the fqdn of the machine and the certs are readable for icinga2.
After that, write a proper constants.conf and zones.conf and you are all set.

Hi,
since Icinga 2.8 you don’t need access to the server anymore to use the node wizard. The only thing you need is the ca.crt on your Client.

Read this for more information: https://icinga.com/2017/11/13/how-to-icinga-2-ca-proxy/

Thank you both for the replies :slight_smile:

Ok, that way is a lot of individual work but I will try it, if there is no integrated way with the icinga2 node setup :slight_smile:

Yes that was my hope. So we tried it today with that:

icinga2 node setup  \
--cn $CN \
--endpoint $ENDPOINT \
--endpoint $ENDPOINT2 \
--zone $CN \
--parent_zone master \
--parent_host $MASTER \
--trustedcert /var/lib/icinga2/certs/trusted-parent.crt \
--accept-commands --accept-config \
--disable-confd

but we got the following error:

information/cli: Verifying parent host connection information: host 'master1.domain.com', port '5665'.
information/cli: Using the following CN (defaults to FQDN): 'agent-server.domain.com'.
information/cli: Backup file '/var/lib/icinga2/certs//agent-server.domain.com.key.orig' already exists. Skipping backup.
information/cli: Backup file '/var/lib/icinga2/certs//agent-server.domain.com.crt.orig' already exists. Skipping backup.
information/base: Writing private key to '/var/lib/icinga2/certs//agent-server.domain.com.key'.
information/base: Writing X509 certificate to '/var/lib/icinga2/certs//agent-server.domain.com.crt'.
information/cli: Verifying trusted certificate file '/var/lib/icinga2/certs/trusted-parent.crt'.
information/cli: Requesting a signed certificate from the parent Icinga node.
critical/cli: Cannot connect to host 'master1.domain.com' on port '5665'
critical/cli: Failed to fetch signed certificate from parent Icinga node 'master1.domain.com, 5665'. Please try again. 

So for me it looks like the server would need to conntect the master once to request the signed certificate?

try it with manually with node wizard on the agent and see if that works. I’am pretty sure your parameters are wrong, as you need to tell the setup that you want to use the CAProxy Feature somehow… I’am only using the Agent on Windowsservers with the powershell framework/module, so the parameters are different.

If you omit the --parent_host parameter, the CLI command will not attempt to connect to the parent endpoint for sending the signing request. Instead, you are asked to put the public ca.crt manually into /var/lib/icinga2/certs. The same method exists within the node wizard CLI command.

Excerpt from the CLI command code:

        /* If no parent connection was made, the user must supply the ca.crt before restarting Icinga 2.*/
        if (!connectToParent) {
                Log(LogWarning, "cli")
                        << "No connection to the parent node was specified.\n\n"
                        << "Please copy the public CA certificate from your master/satellite\n"
                        << "into '" << ca << "' before starting Icinga 2.\n";
        } else {
                Log(LogInformation, "cli", "Make sure to restart Icinga 2.");
        }

The --endpoint parameter takes care of adding the Endpoint name and host attribute, this isn’t done via --parent_host parameter in this specific case.

2 Likes

seems like I don’t need the CAProxy because I don’t work with a satellite.

Thanks :bouquet: that worked for the node setup :slight_smile: I also could sign the fingerprint, but now I get some errors on the master:

information/ApiListener: Reconnecting to endpoint 'agent-server.domain.com' via host 'xxx.xxx.xxx.xxx' and port '5665'
warning/ApiListener: Certificate validation failed for endpoint 'agent-server.domain.com': code 18: self signed certificate
information/ApiListener: New client connection for identity 'agent-server.domain.com' to [xxx.xxx.xxx.xxx]:5665 (certificate validation failed: code 18: self signed certificate)
information/ApiListener: Finished reconnecting to endpoint 'agent-server.domain.com' via host 'xxx.xxx.xxx.xxx' and port '5665'
information/JsonRpcConnection: Received certificate request for CN 'agent-server.domain.com' not signed by our CA.
information/JsonRpcConnection: Sending certificate response for CN 'agent-server.domain.com' to endpoint 'agent-server.domain.com'.
warning/JsonRpcConnection: API client disconnected for identity 'agent-server.domain.com'

with a icinga2 ca list --all I can see the signed Fingerprint, seems like I have to wait for the server admin to look in his log…

What’s going on on the agent side? Always keep both logs opened.

Not so easy if you have no rights to the agent server :slight_smile: but after a second restart of the icinga2 service on Agent now it works :slight_smile: maybe the Agent needs a restart after signing the fingerprint?

But great that it now works, thank you all for your help!

@mfriedrich Do you know what icinga2 version is needed on a agent to use this way?

1 Like

AFAIK 2.9 added the connection-less mode to node setup, and normally a restart is not necessary with reloading the TLS certificates in memory. But if it helps, why not.

I wouldn’t recommend to use agents older than 2.11 anyways, granted that the master is uptodate with 2.11.2.

I would recommend my collegues to use a OS which is new enough to install icinga2 in 2.11 … but that isn’t something I can change :slight_smile:

2 Likes

Hi, i have the same problem that the restart is required, good to know that it exists on Linux too:

Its a problem, because if someone installs the agent via autodeploy and he has no access to Icinga, he needs to wait until the csr is signed and then he needs to restart the service. So we always have the problem, that two teams need to wait on each other.

I will open an issue for that.