On 7/31/2014 1:30 PM, Simo Sorce wrote:
http://www.freeipa.org/page/V4/Password_Vault_Implementation
I was thinking whether we should use a single attribute for each vault,
and format the data within the vault as a json blob, to organize the
data within the blob.
This would allow us to encrypt everything including names and
descriptions of the single secrets. This way we also do not need to
verify the password, as there is a single encrypted blob and not
multiple ones.
I am more concerned about an admin just seeing the secrets descriptions,
or someone finding a backup etc...
I was considering the vault as a unit to which either you have or not
access based on encryption, not on access control done in LDAP. See
above my proposal also that goes in this direction.
The "compartment" concept was actually proposed by Dmitri to help manage
the secrets. I translated that into "vault" since a vault is essentially
a compartment.
We can certainly change the design to use separate password for each
secret. But suppose you have many secrets, you will be responsible to
remember the password for each secret. Would that be a reasonable
requirement for people in general? Encrypting the secret metadata is a
separate issue, we can do that either way. See comments below.
Vault as a compartment will help reduce that burden by using the same
password for multiple secrets. It also can help if you're sharing
multiple secrets with the same group of people. You can also create
separate vaults for each secret if necessary, or the server can be
configured to limit the number of secrets in each vault.
Or we can make the access control more granular. Only owners can see the
list of secrets.
I am not sure listing the secrets within the vault w/o decrypting the
vault is necessarily valuable.
Any concern about the crypto operations being computationally expensive,
or retrieving the whole blob just to see the metadata would waste bandwidth?
Even if we encrypt individual secrets with the metadata, the secret name
itself will still be visible to the admin, and it might give out clues
as to what is in the secret. You can use cryptic names for the secrets,
but you'll have to maintain it on your own.
Let's see if the analogy with safe deposit box in a bank makes sense:
1. Use one box (vault) to store multiple items (secrets). You will have
one key (vault password) and you will need it to see what's inside.
2. Like #1, but the bank keeps a list of items (metadata) in the box and
only share it with authorized people (vault members). You can identify
yourself as a member with an ID (Kerberos principal), but you still need
a key (vault password) to get the items.
3. Use a separate box to store each item (separate password for each
secret). You will have to manually keep track which key for which box/item.
* Why services are in the /shared/ namespace ?
Services don't seem to be something that you want to associate with a
specific user.
Not with a user, with a service.
/services/open...@foo.example.com/
We probably can add new commands (or repurpose the commands) to manage
the namespace. So initially there will be /users and /shared, but you
can add others such as /services.
So in that case it's put under the /shared namespace.
Even so, the vault membership can still be limited to certain
users/service instances. Being in /shared doesn't mean it's open for public.
Understood, but if you have the same "service" on multiple machines then
it quickly becomes difficult to sort it out, I would prefer a logic
similar that of the user, just with fully qualified service names under
a /services/ namespace
The vault namespace is hierarchical, so you can organize it in any way
you want:
* /services/<service name>@<server name>
* /shared/services/<server name>/<service name>
In the current wiki page the service admin can pick the vault name
(/shared/services is just an example), but the secret names in it are
generated from the service principal (to make sure the service admin and
the service instance use the same secret name).
--
Endi S. Dewata
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
