[Freeipa-devel] DNSSEC: upgrade path to Vault

Wed Mar 12 15:54:29 UTC 2014

On 03/12/2014 04:28 PM, Petr Spacek wrote:
> 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.
ok, so this is not the softhsm pkcs11 sqlite database, but  a db 
containing other dnssec data, you didn't say that we need ldap schema 
for this and for which subset of it

>
> 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.
>
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140312/0a662374/attachment.htm>