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