[Freeipa-devel] DNSSEC: upgrade path to Vault

[Dmitri Pal]

On 03/11/2014 07:53 AM, Petr Spacek wrote:
> On 11.3.2014 12:21, Martin Kosek 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 
>>>
>>
>> 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)".
> Why not :-) I do not care as long as it is unambiguous.
>
>>> 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.
>
> Could you be more specific? Is there any particular difference from 
> any other IPA upgrade?
>
> We always tell users to upgrade soon:
>> It is expected
>> that all servers will be upgraded in a relatively short period (days 
>> or weeks,
>> not months). They should be able to co-exist peacefully but new 
>> features will
>> not be available on old servers  [...]
>
> IMHO the key is in "new features will not be available on old 
> servers". In this case the "new feature" is "no single point of 
> failure" which seems pretty important to me :-)
>

The only narrow place IMO is the "-*Temporarily* run DNSSECKeyImporterv2 
which will do one-way key conversion from Vault to LDAP."
I think that OpenDNSSEC will use ldap up to the point when there are any 
masters that are old.
Even if the vault is installed but not everything is upgraded every time 
the OpenDNSSEC needs to dump the keys it will check if there are any 
servers that are old. If there are, it will continue doing things the 
old way using keys from LDAP but would save a copy in vault.
If it detects that there are no more old servers it will remove the ldap 
keys (and may be the old schema).
The DNS servers (if they reread data automatically) would detect that 
the keys are deleted and fall forward to vault.
If DNS servers do not reread keys automatically then they will do a 
check at the restart time and start reading the keys from vault.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/