[Freeipa-devel] DNSSEC: upgrade path to Vault

[Martin Kosek]

On 03/11/2014 11:33 AM, Petr Spacek wrote:
> On 10.3.2014 12:08, Martin Kosek wrote:
>> On 03/10/2014 11:49 AM, Petr Spacek wrote:
>>> On 7.3.2014 17:33, Dmitri Pal wrote:
>>>> I do not think it is the right architectural approach to try to fix a specific
>>>> use case with one off solution while we already know that we need a key
>>>> storage.
>>>> I would rather do things right and reusable than jam them into the currently
>>>> proposed release boundaries.
>>> I want to make clear that I'm not opposed to Vault in general. I'm questioning
>>> the necessity of Vault from the beginning because it will delay DNSSEC
>>> significantly.
>>
>> +1, I also now see number of scenarios where Vault will be needed.
>>
>>>
>>> One of the proposals in this thread is to use something simple for DNSSEC keys
>>> (with few lines of Python code) and migrate DNSSEC with Vault when Vault is
>>> available and stable enough (in some later release).
>>>
>>>> I understand that Vault brings a lot of work to the table. But let us do it
>>>> right and if it does not fit into 4.0 let us do it in 4.1.
>>> We will have one huge release with DNSSEC + Vault at once if we to postpone
>>> DNSSEC to the same release as Vault.
>>>
>>> As a result, it would be harder to debug it because we will have to find if
>>> something is broken because of:
>>> - DNSSEC-IPA integration
>>> - Vault-IPA integration
>>> - DNSSEC-Vault integration.
>>>
>>> I don't think it is a good idea to make such huge release.
>>>
>>> "Release early, release often"
>>>
>>
>> I must say I tend to agree with Petr. If the "poor man's solution" of DNSSEC
>> without Vault does not cost us too much time and it would seem that the Vault
>> is not going to squeeze in 4.0 deadlines, I would rather release the poor man's
>> solution in 4.0 and switch to Vault when it's available in 4.1.
>>
>> This would let our users test the non-Vault parts of our DNSSEC solution
>> instead of waiting to test a perfect solution.
> 
> 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.
> 
> 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).
> 
> 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

cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example

DNSSEC will be translated by FreeIPA to appropriate service name. This can vary
between platforms. "v1" can be an attribute of the entry, I would not add it's
to name.

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

I am thinking it may be sufficient to have just:

cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example

for all DNSSEC empowered masters and then just have:
ipaConfigString: keygenerator

... in the master VM. I am just trying to be future agnostic and avoid
hardcoding service names and implementations details in cn=masters. FreeIPA on
master would know what services to run when it is a keygenerator or not.

> 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.)
> 
> Upgrade procedure:
> - stop OpenDNSSECv1 service
> - stop DNSSECKeyImporterv1 service
> - 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*.
> - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there
> are any other replicas with DNSSECKeyImporterv1 service:

In my proposal, one would just search for "cn=DNSSEC,cn=*,cn=masters..." with
filter "(ipaConfigString=version 1)".

> a) No such replica exists -> delete old-fashioned keys from LDAP.
> b) Another replica with DNSSECKeyImporterv1 service exists:
> - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion
> from Vault to LDAP.
> - 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).
> 
> 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.

Ok, though I am a little bit afraid that the temporary solution would become a
permanent solution. There would need to be something forcing and pushing admins
to migrate.

Martin