[Freeipa-devel] DNSSEC: upgrade path to Vault

[Petr Spacek]

On 12.3.2014 12:12, Ludwig Krispenz wrote:
> 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
>>
>> - key imported/exporter:
>> cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example
>>
>>
>>
>> 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.
> do we need to convert SQLite ? I thought in phase 1 we would have scripts
> exporting from OpenDNSSEC database and store in ldap, then the data already
> exist in ldap. We would ned to replace the sofhthsm module by our own pkcs11
> module using ldap dn directly

I'm sorry for not being clear.

The short-term plain is going to be executed without significant changes:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm

This discussion is more about potential problems with upgrade from short-term 
solution to the long-term one - I'm updating
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm
right now.

To answer your question about SQLite database:
We will have *encryption keys* in LDAP already from the very beginning 
(exported to LDAP by a script) so upgrade from export script to PKCS#11 module 
should be be smooth.

The problem is with various metadata stored in OpenDNSSEC's database so we 
will have to convert them to LDAP. In short-term we have neither intent nor 
time to design a LDAP schema for OpenDNSSEC database, just for the keys.

Does it clear the confusion?

-- 
Petr^2 Spacek