[Freeipa-devel] FreeIPA integration with external DNS services

[Endi Sukma Dewata]

On 12/10/2014 9:59 PM, Petr Spacek wrote:
>>>>> Alternatively we can use Vault for TSIG key storage and use Vault's capability
>>>>> to share keys among many users. In that case we don't have problem with key
>>>>> distribution nor authorization.
>>>>
>>>> I am not convinced we should grow Vault dependency for this functionality, it
>>>> requires the whole PKI machinery to be available. Many deployments do not use
>>>> it though.
>>>>
>>>>> Another possibility is to say that replica-deletion can be done only by root
>>>>> user or that updates to external DNS are supported only when running
>>>>> ipa-replica-manage as root.
>>>>
>>>> Why does root help? So that TSIG keys will be available on all IPA servers,
>>>> regardless whether they have DNS service running or not?
>>> The point is that we need to store TSIG keys "somewhere" to make them
>>> available to ipa* scripts on all replica but at the same not to human-users.
>>>
>>> BTW there don't need to be any 'DNS service' if only external DNS integration
>>> is in use.
>>>
>>>> It would be better to have the TSIG keys available using standard FreeIPA RBAC
>>>> roles, i.e. DS ACIs so that privileged users can also use the TSIG. Or am I
>>>> missing anything?
>>>
>>> Ideologically - no, it sounds fine.
>>> Technically - the problem is in implementation. We need a mechanism for secure
>>> key distribution *among users*, i.e. Vault-like functionality. I would rather
>>> not re-implement Vault just for external DNS.
>>>
>>> I think that external DNS could depend on Vault (assuming that external DNS
>>> support will be purely optional).
>>>
>>> DNSSEC key distribution is very different because it distributes keys to
>>> *servers* and there is no ACI mechanism on top of that - all DNS servers need
>>> to know all the keys anyway.
>>
>> So IIUC, the goal would be to put TSIG keys in the Vault and then make them
>> available for all IPA servers?
>>
>> I am now not sure if the Vault as proposed can easily select a group of
>> principals to allow reading the Vault or if it is only confined for the
>> owner/user principal. We would need to ask Endi (CCed).
>
> I assumed that very first sentence of
> http://www.freeipa.org/page/V4/Password_Vault_Implementation#Vault
> "Vault is a secure place to store data or a collection of secrets. A vault may
> be privately owned by a user, or shared among users, groups, or services."
> is correct :-)
>
> Endi, we would like to have one secret which is shared among services & users
> at the same time. Is it possible to do that with Vault?

Yes, the access to a particular vault is limited to the vault members & 
owners which can be a set of users, groups, and/or services. See 
http://www.freeipa.org/page/V4/Password_Vault_Implementation#Access_Control

A vault member can list, archive, and retrieve the secrets in a standard 
vault. With symmetric vault the member will need a vault password in 
order to archive and retrieve secrets. With asymmetric vault the member 
can only archive the secrets but not retrieve them since it only has the 
public key and not the private key.

A vault owner can list, archive, and retrieve the secrets like vault 
members, but it has the private key so it can retrieve secrets from 
asymmetric vault. The owner can also manage the list of members and 
owners of the vault, and change the vault password/keys.

There are commands to manage the members/owners. See 
http://www.freeipa.org/page/V4/Password_Vault_Implementation#Adding_vault_member

$ ipa vault-add-member MyVault --groups group1,group2
$ ipa vault-add-owner MyVault --users user1,user2
(we may need a separate option for services)

Below are the vault LDAP ACIs. See 
http://www.freeipa.org/page/V4/Password_Vault_Implementation#Access_Control_Attributes

aci: (targetfilter="(objectClass=ipaVault)")
   (targetattr="*")
   (version 3.0; acl "Vault members can access the vault";
    allow(read, search, compare) userattr="member#USERDN";)
aci: (targetfilter="(objectClass=ipaVault)")
   (targetattr="*")
   (version 3.0; acl "Indirect vault members can access the vault";
    allow(read, search, compare) userattr="member#GROUPDN";)

aci: (targetfilter="(objectClass=ipaVault)")
   (targetattr="*")
   (version 3.0; acl "Vault owners can modify the vault";
    allow(read, search, compare, write) userattr="owner#USERDN";)
aci: (targetfilter="(objectClass=ipaVault)")
   (targetattr="*")
   (version 3.0; acl "Indirect vault owners can modify the vault";
    allow(read, search, compare, write) userattr="owner#GROUPDN";)

Note that the secrets are stored separately in KRA, not in the IPA LDAP 
tree, so they are not directly controlled by the above ACIs. The vault 
service will first verify that you have access to the vault based on the 
above ACIs then it will let you archive/retrieve secrets in KRA.

-- 
Endi S. Dewata