[Freeipa-devel] DNSSEC: upgrade path to Vault

[Simo Sorce]

On Tue, 2014-03-11 at 11:33 +0100, Petr Spacek wrote:
> Yesterday we have agreed that DNSSEC support is not going to depend on Vault 
> from the beginning and that we can migrate to Vault later.
> 
> Here I'm proposing safe upgrade path from non-vault to Vault solution.
> 
> After all, it seems relatively easy.

Ok let me put my 2c in.

> TL;DR version
> =============
> Use information in cn=masters to detect if there are old replicas and 
> temporarily convert new keys from Vault to LDAP storage (until all old 
> replicas are deleted).

I think this is not necessary, we do not support running an
infrastructure for long times with mixed major IPA versions.
So we should not need to do this.

> Full version
> ============
> IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA server and 
> separate key import/export daemon (i.e. script called from cron or something 
> like that) on all IPA servers.
> 
> In 4.0, we can add new LDAP objects for DNSSEC-related IPA services (please 
> propose better names :-):
> - key generator:
> cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example

As Martin said -> DNSSEC, the version is irrelevant here unless you are
proposing to be able to run v1 or v2 conditionally with the same code
base, if not then on upgrade the new openDNSSEC code will simply be
upgraded like all other freeipa components. We do not capture version
number for any of them.

> - key imported/exporter:
> cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example

This is probably not needed as a separate key, if we are using systemd
then we simply make one unit file depend on another so both start
together in master, while on replica we only have 1 service to start
anyway.
If we are on sysv we will deploy our own init script that start both
components at the same time on master, only one on replicas.

The difference about what to start will be that only one master is
configured as key generator, we do not even need to represent this in
ldap in theory, because you cannot move the role by simply changing an
LDAP entry anyway, and the difference can simply be a configuration file
on the keygenerator master.

> Initial state before upgrade:
> - N IPA 4.0 replicas
> - N DNSSECKeyImporterv1 service instances (i.e. key distribution for IPA 4.0)
> - 1 OpenDNSSECv1 service instance (key generator)
> 
> Now we want to upgrade a first replica to IPA 4.1. For simplicity, let's add a 
> *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can 
> generalize the procedure if this requirement is not acceptable.)

I think we can proceed with this restriction for now, either tat or the
admin is required to stop and unconfigure the key generator service
anyway.

> Upgrade procedure:
> - stop OpenDNSSECv1 service
> - stop DNSSECKeyImporterv1 service

stpo DNSSEC (will stop both)

> - convert OpenDNSSECv1 database to OpenDNSSECv2
> This step is not related to Vault. We need to covert local SQLite database 
> from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC.
> 
> - convert private keys from LDAP to Vault *but let them in LDAP for a while*.

This is only true *if* we'll decide to move storage to the Vault, we may
not want to, or it may happen in a separate release.

> - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there 
> are any other replicas with DNSSECKeyImporterv1 service:
> a) No such replica exists -> delete old-fashioned keys from LDAP.

I say we do this step unconditionally if we move to the vault, all other
DNS server have functional keys for a while anyway (should always have
at least 1 month autonomy), and we clearly state people must upgrade the
infrastructure in a week not in months. So we should never need to keep
old keys.

> b) Another replica with DNSSECKeyImporterv1 service exists:
> - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion 
> from Vault to LDAP.

We do not need this, you must update all replicas to a vesion that knows
what to do and then they'll find the new keys where they are.

> - DNSSECKeyImporterv2 can check e.g. daily if all DNSSECKeyImporterv1 
> instances were deleted or not. Then it can delete old-fashioned keys from LDAP 
> and also stop itself when all old replicas were deleted (and compatibility 
> mode is not needed anymore).

We also avoid this.
The *only* thing we really need to do IMO is that if a DNS server finds
out it's key for a zone are expired then it shuts down itself and makes
itself unavailable so clients will start falling over to another DNS
server and the admin will have to troubleshoot and resolve out why the
keys were not accessible. If the reason is that they forgot to update a
replica then they should just proceed and update and the DNS server will
restart after that (we may want to make sure we have a way to pull the
latest key at upgrade or we have chick egg issue where replica update
fails because DNS does not start).

> This approach removes time constraints from upgrade procedure and prevents DNS 
> servers from failing when update is delayed etc. As a result, admin can 
> upgrade replica-by-replica at will.

I want time constraints and I want DNS server to fail fast.
constraints are in the order of 1 month though, not a few days.
I think 1 month is sufficient.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York