Implicit Entities

[Geoff Webster]

Are there any further docs on Implicit Entities?

Right now I mainly use LDAP for user access to Vault.

I think I fully understand that I can map the LDAP Groups I use for access to Vault to Group Entities so that groups could have templated access to group "namespaces" within the KV store.

What I am wondering is if implicit entities can be used to allow anyone who can login to Vault on our LDAP auth mount to have a templated policy for a user KV "namespace", or if I'd have to map each and every user manually/script.

[Andrew Meyer]

Are you using OpenLDAP or MS AD?  I'm using FreeIPA but I feel like vault isn't recognizing the groups at all.

[Geoff Webster]

We're using AD but group mappings aren't an issue. I was just trying to understand if I'm going to have to map each and every user who wants to use Vault with an entity or if Vault can autocreate entities and alias on login, since it appears you do need to map each group.

[Nathan Basanese]

  // , I have the same question.

If Vault doesn't directly create entities and aliases, then it's time to discuss how we could automate it. 

There are plenty of services and use cases out there for triggering some change in a system upon an update to AD. Doing this for Vault should be straightforward. 

[Andrew Meyer]

So we are using FreeIPA (Redhat's LDAP implementation).  And yes, you have to map every user to the group or it won't work.  After adding the group to the policy.  Finally generating the token.  It kind of sucks.

[Jeff Mitchell]

Hi there,

Geoff:

Vault creates entities automatically on any login, and it creates an alias to that entity using parameters defined by the authentication plugin such that repeat authentications result in the same entity. So what you're asking for is exactly what happens.

Andrew:

I don't really know anything about FreeIPA, but it sounds like your group filter is wrong. You may want to try figuring out the correct one using ldapsearch, which is a faster/easier way to figure out the right parameters.

Best,

Jeff

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/f8a60627-33f9-4979-ad68-cc472a7368e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Meyer]

FreeIPA is an all encompassing tool similar to MS AD.  However it uses OpenLDAP RFC2307bis.  The filter seems to be working since i'm able to see the groups.  But if I apply the policy to the group its not applying it automatically to the user.  

Andrew Meyer

You received this message because you are subscribed to a topic in the Google Groups "Vault" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vault-tool/YmAL0OeM8wg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAORe8GF%3DUoufVtEsEU5aJns9CpweF2N_K-MAQ5aap5-ieVgnYQ%40mail.gmail.com.

[Jeff Mitchell]

Hi Andrew,

Are you talking about Identity groups or LDAP groups? If you're talking about Identity groups, keep in mind that although entities are created implicitly, groups aren't. For the groups you want to use, you need to create an external group with an alias matching the group from your LDAP mount.

Best,

Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CA%2BabcpUG8m%3DPZ%2B0vacAw%2B94FraHkkLrr1Lewn8-2HcKtDfopYA%40mail.gmail.com.

[Andrew Meyer]

So I'm using LDAP groups.  I add my users to the LDAP groups and in order to make it work in vault I run the following:

vault write auth/ldap/groups/vault-admins policies=ops

Then I end up adding the user in vault to group.

vaultwrite auth/ldap/users/bilbo.baggins groups=vault-admins policies=ops-write

Am I doing this wrong?

[Jeff Mitchell]

Hi Andrew,

You're not doing anything wrong, you're just doing management at the ldap group layer instead of at the vault identity layer.

Best,

Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/d78ddbc5-122f-4dcb-89a9-e0646fa6aea1%40googlegroups.com.

[Andrew Meyer]

That's really what I want.  Unless there is a way to get vault to allow anyone in the ldap group vault-admins full access w/o having to add individual users to the group within vault.  I might not be understanding the best way to do it.

[Nathan Basanese]

  // , Does Vault generate any kind of entity meta-data related to the LDAP Group for the entities it creates upon successful LDAP authentications?

I'm tentatively exploring ways to use AD group membership as a single source of truth for human authentication to Vault, because that would allow us to "plug in" existing authorization systems to Vault's policy templating.

But like I said, other tools can do some of the lifting here, like generating Vault policies and LDAP Group mappings based on AD group membership, for instance.

Anyway, this whole "AD groups somehow affecting Vault authorizations in an automated way" thing is something I'm going to take a few hours to look into in a couple of weeks or so, once I have a better grasp on Vault Policy Templating and stuff. 

[Nathan Basanese]

  // , It looks like avoiding advanced AD synchronization features was an intentional (and perhaps wise) design decision on the part of the Vault developers, according to this: 

"We don't create group aliases automatically. We're thinking of putting in a config option for this, but I had a little asterisk on that slide a little while back and the reason is because if you have 100 groups, but you only care about three of them in a Vault and they automatically populate, now you have 100 groups in a Vault, most of which you don't want. So, we're probably going to have a way to toggle that, but for right now, if you're trying to play around with it, you have to actually create the group aliases first and then once it's created there and it sees that alias exists, it'll start doing the mapping for you. So, just a little trade-off."

https://groups.google.com/forum/#!topic/vault-tool/eZZQMDWIdsk

We could create group aliases as needed, I suppose. What I'm thinking about now, is a revocation scenario: 

1. An AD group is created in AD

2. Some kind of synchronization or triggering tool triggers an update in Vault, depending on whether the AD group matches some kind of pattern, e.g. it starts with SEC-*. 

3. That trigger-er then updates Vault by attaching a Vault Policy to an LDAP role corresponding to that AD group.

4. An AD user Jim is added to an AD group.

5. The user Jim logs in to Vault with his AD credentials, using the LDAP authentication method.

6. Ho ho, Merry Christmas, he gets a token. 

7. But, oh no, Jim's been hacked! 

8. So he now gets removed from the AD group until InfoSec can find out what's going on. 

9. In the mean time, although he can't log in again, Jim's token is still valid.

There are 4 options to deal with this that I can think of right now:

1. I just accept the risk, because it's not too bad as long as tokens are short lived, or even only allow a few uses. And I can add a section to the runbook that says to manually delete any such tokens for revocation. 

2. Make the triggering system automatically send token revocation API calls to Vault for a user if it notices that user's removal from one of its watched AD groups. 

3. Limit LDAP authorizations to capabilities that are less problematic in the event of a compromised token, like ["list"] and ["create"] access without ["read"] access, and such.

4. Something else

Less reasonable options: 

Write an AD synchronization plugin

Stop using AD at all

SEAL THE VAULT