Experience of migration from one master to another

Icinga 2
1

Hi there,

is there anybody with experience to migrate a satellite with agents to another master with a new CA?

I used the satellite as CA Proxy and now I’m not sure if I will have to registrate every agent new to the new master, or if I would get new certificate signing requests on the new master and could handel it from there?

I would be happy to hear some experience,

kind regards Alicia

2

Hi,

a new CA key pair actually invalidates all existing signed certificates with the old CA. That being said, you need to re-create the signing requests and sign them with the new CA.

Is there a specific reason not to keep using the old CA?

In terms of possible migrations, there’s different attempts.

  • Collect all the public certificates from your satellites and agents. Create a new CSR from them, sign them on the master manually, and redeploy them.
  • Or you could use the CLI tooling to request new signed certificates from the parent host, pki request is what you’re looking for. If you are going the node setup/wizard route, ensure to have configuration backups as these CLI commands generate new configuration. Or you pass all required parameters e.g. to node setup.

Cheers,
Michael

3

Hi Michael,

thanks for your reply.

Because of some courios circumstances our Test-Stage was used for a lot of productiv servers. Now I am preparing the Production-Stage (new servers with new IPs) and I have to change all monitored productiv servers to the Production-Stage. Or is there a way to migrate the CA to another server? I haven’t found anything like that.
The satellite is in Production-Stage because we hoped we will have a littlebit less work if we don’t change it.

That what was I was thinking about, if we have to generate new signing requests but I’m almost looking for some examples how such a icinga2 node setup command would look like to do this with salt on every Agent-Server without a ticket and sign it afterwords from the master/CA.

It’s really weird to start a Icinga2-Test-Stage and now monitor about 180 servers. So I’m hoping to find a smooth way to change the CA.

Best regards,
Alicia

4

Simply put, that is what we recommend to include in your backups. Copying the .../ca path is enough, but only do that for migration purposes. If that’s exposed anywhere else, bad people can sign certificates and hijack your monitoring. Keep the CA safe and secure, that’s merely the point with not documenting this in deep for migrations.

When using the term salt, does that mean SaltStack?

Agreed, there could be more instructions on test stages and moving to production. Still, there’s two arguments - each system should be isolated on its own. Meaning to say, you have two Icinga CAs, and those systems cannot interfere with each other. Migration requires additional steps then. For easiness, sharing the same CA may work as well, but it may also open the doors for left-over endpoints, and wrong configurations between stage and prod.

That being said, I’d opt for creating a new CA and migrating existing satellites and CA with a gentle re-installation.

Cheers,
Michael

5

If I understand it right, I would have to change the zones.conf on every single server, so I would not save so much time with it. I think I will go further with a new CA. I have now tested the reconfiguration with icinga2 node setup and it worked pretty well.

Yes, we are starting to use SaltStack as part of Suse Manager, but there are not so much experience about it and not every server is connected right now.

That is the plan for now.

Thank you very much for your help!

Best regards,
Alicia

1 Like