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

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.


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?

Freeipa-devel mailing list

Reply via email to