[Freeipa-devel] DNSSEC design page: key wrapping

[Dmitri Pal]

On 03/05/2014 11:06 AM, Simo Sorce wrote:
> On Wed, 2014-03-05 at 16:29 +0100, Martin Kosek wrote:
>> On 03/05/2014 03:04 PM, Simo Sorce wrote:
>>> On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote:
>>>> On 03/04/2014 11:14 PM, Petr Spacek wrote:
>>>>> On 4.3.2014 22:53, Simo Sorce wrote:
>>>>>> On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote:
>>>>>>> On 4.3.2014 22:15, Simo Sorce wrote:
>>>>>>>> On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote:
>>>> ...
>>>>>> I guess my only reservation is about whether DRM storage is replicated
>>>>>> or not. Although both the K/M and DNS cases do not require the Vault to
>>>>>> be online at all times because the keys will be downloaded and stored
>>>>>> locally and only needs to be accessed when they changed, there is the
>>>>>> problem of having all keys in a SPOF, that should not happen.
>>>>> According to http://www.freeipa.org/page/V4/Password_Vault#Replication the
>>>>> replication is available for DRM, we just need to use it.
>>>>>
>>>>> IMHO a vault without replication is not useful anyway. Users are not happy when
>>>>> their passwords disappear ;-)
>>>>>
>>>>>> The additional thing about the Vault is that we can use key escrow there
>>>>>> as a mechanism to re-encrypt automatically system relevant keys when a
>>>>>> new server is joined to the realm.
>>>>> So we agree that Vault offers what we want so we should use it, right?
>>>>>
>>>>> I think we should determine if we can use Vault for K/M. It would be another
>>>>> reason why we should use Vault instead of a custom solution.
>>>>>
>>>> Do we really want to use the heavy machinery Vault for DNSSEC keys? I would
>>>> personally like to avoid it and use something more lightweight.
>>>>
>>>> Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It
>>>> needs Tomcat and all the Java machinery, special installation, replication
>>>> scheme, difficult debugging etc. In my mind, Vault is a specialized heavy
>>>> component that solves specific problems that not every admin may want and thus
>>>> may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC).
>>> Well keep in mind that you do not need a vault instance on every DNS
>>> server, just like a CA a few servers would be sufficient. DNS key
>>> rotation happens relatively 'rarely' so the dependency is not a huge
>>> problem in terms of performance or management. There is the problem of
>>> the heavyweight java-based infrastructure, but we already have that
>>> dependency for the CA part, so it's not like we are adding anything new.
>> Yeah, but the plan is not force people to have the heavy weight Java
>> infrastructure on each server so that they are able to create more lightweight
>> servers only with components they choose:
>>
>> https://fedorahosted.org/freeipa/ticket/4058
> Yes, but the Vault does not need to be installed on each server, just on
> a couple of them like for the CA. In particular it doesn't need to be
> installed on the same servers that offer the DNS service.
>
> Simo.
>
I agree with Simo.

 From the big picture perspective we have more and more use cases when 
Vault becomes a requirement:
a) Storing passwords for users - initial case
b) Storing volume keys for Cinder - OpenStack - Barbican use case
c) Storing passwords for external cloud provider accounts - 
deltacloud/Manage IQ use case
d) Storing DNSSEC keys - your use case
e) Storing private keys for users - classical PKI escrow the DRM was 
built for
f) Storing private SSH key - there is a ticket for that kind of escrow 
functionality too.

For me it is apparent that vault will be a default component.
It is not as heavy weight now as it used to be. All Dogtag components 
can share same tomcat instance so if you have a CA on the system your 
incremental impact is very small.

So what we need is:
a) Solve the problem of the DRM install. Single server work was done by 
Rob. Ade will be able to take it over and hel;p with the DRM install 
across several servers (with replication).
b) There is REST API for Vault it requires certificate authentication 
for now. No Kerberos. We can probably live without Kerberos for now 
since SSSD has host cert.
c) We need to hook some kind of access control that would allow 
specifying policies about who can fetch which keys (this is regardless 
where they are stored Vault or LDAP)

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 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.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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