[Freeipa-devel] DNSSEC: upgrade path to Vault

[Ludwig Krispenz]

On 03/12/2014 01:09 PM, Petr Spacek wrote:
> 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.
the schema proposal contains attributes for the metadata, so this should 
be ok. But I think right now the export function available in 
opendnsssec/softhsm only exports keys. We would have to have sql scripts 
to read and convert the sqlite3 database
>
> Does it clear the confusion?
>