[Freeipa-devel] DNSSEC: upgrade path to Vault

[Petr Spacek]

On 12.3.2014 14:07, Ludwig Krispenz wrote:
>
> 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
The current schema stores only PKCS#11 metadata but nothing about key&signing 
policy and other DNSSEC-related stuff.

We don't have complete schema and we don't have to have it now. Look at the 
SQLite database in opendnssecv143.sqlite3.bz2 - it is pretty complex.

We don't have time to prepare schema & port OpenDNSSECv1 to LDAP backend. 
(Other aspect is that the schema is different for OpenDNSSEC v2.)

> 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

Yes, we will have to have such script for upgrades from short-term -> 
long-term solution.

-- 
Petr^2 Spacek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opendnssecv143.sqlite3.bz2
Type: application/x-bzip
Size: 19530 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140312/c5849d79/attachment.bin>