Shedding identity_policies

We’re in the process of migrating from LDAP to Okta for authentication, so I’m revisiting how our policies are attached to users.

To test I’ve setup identity groups externally aliased to groups in LDAP and Okta (“foo” in LDAP, maps to “ldap-foo” - for okta, “okta-foo”).

I’ve then attached the “can-do-foo” policy to both the “ldap-foo” and “okta-foo” groups and removed the direct mapping in ldap and okta.

Now however, when I create a token and specify only the “can-do-bar” policy, I still get the “can-do-foo” policy attached.

I appreciate that I still have the same identity (just as I still have the same LDAP identity), but if I’m asking for a token with only certain policies, I definitely don’t want extra ones added.

We currently create identity tokens (tokens that identify someone, but have no policies attached) as a way to authenticate to some systems.

Is there a way to say -no-identity-policies - or should we avoid identities for now?

JAmes

You didn’t really explain your use-case – why you want to create a policy without that identity. There are various ways to do this but it would be helpful to understand what you’re trying to do.

why

There are three main use cases:

  1. Service Authentication: A short-lived, policy-free token is created and sent to a remote service as a form of an authentication token. That token is used as identification of the user by the remote service by looking up its details in Vault. The user and the service have no other shared form of authn/identity and the this also means the user doesn’t need to log in again.

  2. Bequeath Temporary Access: Quite often administrators and operators have access to many things and from time to time we generate a short-lived, wrapped token with only one or two policies and hand the wrapped token to a coworker to finish a particular activity. We do this as a way of saying “we would do this ourselves, but we trust you to do it”.

  3. Removing a Policy: Those of us who administer Vault have a “root-all” policy. We also have a “root-latch” policy. The “root-latch” policy effectively neuters the access granted in the “root-all” policy to prevent us from footgunning. We create tokens without the “root-latch” policy to enable the access in “root-all” when we do administrative work.

HTH,

JAmes

If the entity retains group membership (and associate identity policies) after there are no longer external groups being returned, it may be due to the bug described at the start of the 1.3.4 changelog: https://github.com/hashicorp/vault/blob/master/CHANGELOG.md#134-march-19th-2020

Hey kalafut,

Thanks for this. In this case, the group membership of the original entity remains the same. The issue is that I’m creating a new token explicitly listing the policies I want the token to have, but Vault is still adding extra policies as they’re attached to the entity.

JAmes

@idcmp did you try this with Vault 1.3.4 yet?
1.4 went GA today and will have the fix mentioned above.

Oh cool! I’ll give it a try! Thank you!

Hi @mikegreen,

I’m now on Vault 1.4.2 on client and server and I’ve tried this and still have the same issue.

The groups “developers” and “operators” mapped as external groups via the identity backend. I successfully authenticate via Okta:

$ vault login -method=oidc -path=oktapreview
...
token                s.example
token_policies       ["default"]
identity_policies    ["default" "developers" "operators"]
policies             ["default" "developers" "operators"]
...

$ VAULT_TOKEN=s.example vault token lookup
...
display_name         oktapreview-idcmp
meta                 [role:oktapreview-user]

My goal: Create a Vault token that has no policies, but continues to maintain some of the identity information, so I specify -policy=""

$ VAULT_TOKEN=s.example vault token create -policy="" -no-default-policy -ttl=5m
Key                  Value
---                  -----
token                s.example2
token_duration       5m
token_renewable      true
token_policies       []
identity_policies    ["default" "developers" "operators"]
policies             ["default" "developers" "operators"]

Policies from the identity are still present even though I’ve specifically asked for no policies.

JAmes