Add policy to existing userpass account using CLI

[raz...@aire.io]

Hi All,

First of all: great product! I have just started using it.

I am trying to add a policy to an existing userpass account using the CLI.

For ex:

vault policy-write batman batman.hcl

vault auth-enable userpass

// this works

vault write auth/userpass/users/razvan password=pass policies="batman"

// this "update" or "add" to an existing user does not  - it just overwrites

vault write auth/userpass/users/razvan password=pass

vault write auth/usepass/users/razvan policies="batman"

Cheers,

Razvan

[vishal nayak]

Hi Razvan,

Each write command overwrites the entire configuration. 

Updating requires all the values to be provided together. 

This is a consistent behavior across all the Vault commands. 

Regards,

Vishal

--
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/aee2e2b1-d424-43ca-ba2f-f69dd31fc45f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

vn

[raz...@aire.io]

Hi Vishal,

Thank you for the prompt answer.

If you don't mind I would like to double check:

1) The password and policies must be set together when using the userpass auth backend. Is there any way to separate the account creation from the policy association for userpass using the HTTP API or any other approach?

2) Given that password and policy must be set together what would be the best practice to add policies to the account if I do not know the password? ( I should not know the password but I should be allowed to add policies)  

3) I would like to use vault in this manner:

create account1

<later>

associate policy1 to account1

<later>

associate policy2 to account1

Would the Github auth backend help me in this scenario?

Cheers,

Razvan

Vishal

To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/aee2e2b1-d424-43ca-ba2f-f69dd31fc45f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

vn

[vishal nayak]

Hi Razvan,

1) The password and policies must be set together when using the userpass auth backend. Is there any way to separate the account creation from the policy association for userpass using the HTTP API or any other approach?

With the userpass backend, there is currently no way of separating the account creation from the policy association. Password and policies have to be provided together. However, just FYI, if you need to associate more than one policy to a single account, that is possible by providing a comma separated list of policies.

 

 

2) Given that password and policy must be set together what would be the best practice to add policies to the account if I do not know the password? ( I should not know the password but I should be allowed to add policies)  

Authorization to the endpoint that configures the account, should have access to the password of the account. Actually, this is the same endpoint to reset the password as well. So, a user who can associate a policy to an account can as well reset it. As of now, there is no separate endpoint only to associate the policies to the account without knowing the password. I don't see your need for this use-case.

  

3) I would like to use vault in this manner:

create account1

<later>

associate policy1 to account1

<later>

associate policy2 to account1

Would the Github auth backend help me in this scenario?

In the github secret backend's perspective, the policies are associated to the teams in the github organization. You can associate any policy to the github team at any time and it would reflect during the login time. But this is unlike what you are expecting. This is at a github team's granularity, not at users'.

Regards,

Vishal

Vishal

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/aee2e2b1-d424-43ca-ba2f-f69dd31fc45f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

vn

--
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/c4b1b15d-5dbc-4f73-8b80-5edd8cf64655%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

vn

[Jeff Mitchell]

On Mon, Mar 14, 2016 at 1:39 PM, vishal nayak <vishal...@gmail.com> wrote:
> Hi Razvan,
>
>> 1) The password and policies must be set together when using the userpass
>> auth backend. Is there any way to separate the account creation from the
>> policy association for userpass using the HTTP API or any other approach?
>
>
> With the userpass backend, there is currently no way of separating the
> account creation from the policy association. Password and policies have to
> be provided together. However, just FYI, if you need to associate more than
> one policy to a single account, that is possible by providing a comma
> separated list of policies.

Just to add a bit of extra context, in 0.5 we exposed the capabilities
model within Vault to ACL policies. This model allows for a
distinction between create and update, however, support for this
distinction must be coded in where appropriate, and that has not been
done yet for userpass. If someone is interested in working on a PR I
can point you to some code that would be a good guide.

Best,
Jeff

[Timothy Kimball]

Vishal -

Comments inline...

Authorization to the endpoint that configures the account, should have access to the password of the account. Actually, this is the same endpoint to reset the password as well. So, a user who can associate a policy to an account can as well reset it. As of now, there is no separate endpoint only to associate the policies to the account without knowing the password. I don't see your need for this use-case.

  

The key use case here is that an administrator can give access to credentials to an existing named account w/o knowing the user's password.

I believe this is why a lot of default security settings in various products require a user to change their password on first login - to insure that the administrator is not able to easily impersonate a user. 

But maybe we should be managing vault in another way? Or having separate vault servers? Or use another method of authentication - maybe LDAP?

Thanks,

Tim

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAFy0tpyRD1Y3iDRixpP7DXHrb%3Da8k%2Bh5fprvZk4F69Bx%3DPJurQ%40mail.gmail.com.

[Jeff Mitchell]

Hi Tim,

On Tue, Mar 15, 2016 at 7:18 AM, Timothy Kimball
<timothy...@gmail.com> wrote:
> The key use case here is that an administrator can give access to
> credentials to an existing named account w/o knowing the user's password.
>
> I believe this is why a lot of default security settings in various products
> require a user to change their password on first login - to insure that the
> administrator is not able to easily impersonate a user.

This makes an assumption that an administrator knows the user's
password in the first place, which is not a model we encourage. The
model we were targeting here is that a provisioning script would
generate a password, pop it into Vault, and (mail/IM/whatever) the
user. This could be done fresh for each time the user needed to access
Vault, so every time the user would get a new password and no admin
would ever see it (and it's bcrypt-encrypted on the backend so even
access to /sys/raw wouldn't help an admin). This fits nicely into
Vault's overall model of short-lived credentials.

Obviously there are other ways in this scenario that admin tampering
could happen (access to email server, for instance), but that's true
for any system. Even with a password change endpoint, an admin with
enough access can simply give themselves a policy that allows access
to that user's password change endpoint. (The HMAC of the client token
used to access it will be different than the user's though, so if the
audit log is not tampered with, it would tell a story.)

This shouldn't be taken to mean that we can't add an endpoint that the
user can be given access to in order to change their password -- we
can, and we can try to get that into 0.5.2. It's just noting that an
explicit design goal of Vault was not to be an identity server, and
its capabilities were generally geared around avoiding manual
administrative tasks such as copy and pasting username/passwords, in
favor of making it easy to automate security needs (which *is* an
explicit design goal :-) ).

Best,
Jeff

[Timothy Kimball]

Jeff -

Thanks for the detail. I had a feeling we are doing something unintended :D

To confirm my understanding, asking the question another way: Is vault not intended to hold long running user credentials other than for administrators?

Our planned use of vault: We are storing all of our various environments credentials in one place and then granting and removing access to particular environments to various staff. 

So staff would by default have complete access to all test environments. Production environments would be granted on a case by case basis. 

So we have one central vault server for all environments. 

(Should have asked this question from the start!)

Thanks,

Tim

--
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/CAORe8GH7kFcOdenU55mQnmB6H2Nkr71yw%3Dc3s8x8%2By%2BZ7hYY7g%40mail.gmail.com.

[Jeff Mitchell]

Hi Tim,

On Tue, Mar 15, 2016 at 12:35 PM, Timothy Kimball
<timothy...@gmail.com> wrote:
> To confirm my understanding, asking the question another way: Is vault not
> intended to hold long running user credentials other than for
> administrators?

It's more like, Vault isn't intended to compete with LDAP or Crowd or
OpenAM or Active Directory -- places that hold all user information in
a specific query-able schema (you know...not just user name and
password, but email address, telephone number, desk number, location,
organizational unit, manager, etc). So the userpass backend wasn't
(originally) meant as a full-featured user store, merely as a way to
essentially have a public credential and a secret credential to gain a
Vault token, rather than actually having a concept of users (we have
some ideas about giving Vault better notions of identity across
backends, but nothing roadmapped right now). Even for those users in
the userpass backend, the general concept was that they would be
managed via an automated process, since making secret management
easily automated is a driving concern behind Vault.

I think what you want, for users to be able to change their own
password, is totally reasonable, I was just trying to give some
context around how it exists now. The fact that we envisioned most
people would drive it automatically doesn't mean we shouldn't
accommodate those doing it manually. (Be sure you have audit logging
turned on, though, or there's still plenty of abuse that can happen
without being caught. Also make sure that your Vault admins can't
mangle the audit log. Also, something about turtles.)

In terms of humans, there's no concept on our end that administrators
should have longer-running user credentials than anyone else :-) You
might choose to manage it that way, but it's not a requirement or
design goal by any means.

> Our planned use of vault: We are storing all of our various environments
> credentials in one place and then granting and removing access to particular
> environments to various staff.

Sounds perfect!

> So staff would by default have complete access to all test environments.
> Production environments would be granted on a case by case basis.
>
> So we have one central vault server for all environments.

Yep, sounds good.

Best,
Jeff

[Jeff Mitchell]

As an update: 0.5.2, coming today, allows the normal users path to be
used to modify user values, but:

1) The normal user path now honors the distinction between create and
update capabilities, so a less-privileged admin can be allowed to
create new users but not modify existing users.
2) Each user now has an endpoint that their token can be given access
to that allows changing the password associated with their username.
(There is a matching endpoint for policies, but you generally won't
want to give that to unprivileged users; it's meant to delegate to
other admins.)

--Jeff

[Tim Henderson]

2) Each user now has an endpoint that their token can be given access
to that allows changing the password associated with their username.
(There is a matching endpoint for policies, but you generally won't
want to give that to unprivileged users; it's meant to delegate to
other admins.) 

Is this the endpoint you are referring to? 

 curl  -X POST -d '{"password": "myNewPass"}' -H "X-Vault-Token:$VAULT_TOKEN"  http://127.0.0.1:8200/v1/auth/userpass/users/myusername/password

This is giving my 'default' policy users "permission denied".

[Jeff Mitchell]

Hi Tim,

That endpoint isn't in the default policy unless you've added it.

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/2d754a11-c2f0-4b79-a2ff-5d8511447d59%40googlegroups.com.

[Tim H]

That endpoint isn't in the default policy unless you've added it.

Jeff, 

How would you suggest defining a policy which allows a user to change their password?  Is there a special path for the "current" user?  I don't want to define policy for every single user to allow them to update their password. 

Tim H.

[Jeff Mitchell]

Hi Tim,

There is currently no path for the "current" user, but we would like
to enhance ACL functionality in ways that will enable this.

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/efc0bb81-75a0-4181-8908-9ddd4be8aa10%40googlegroups.com.

[Tim H]

There is currently no path for the "current" user, but we would like
to enhance ACL functionality in ways that will enable this.

Thanks for the quick reply.  So we are clear, short of defining a policy specific to each users userpass-password-path, this functionality is not possible...yet?

[Jeff Mitchell]

Tim,

That is correct.

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/ffc866b7-0bfb-4f59-9922-2201a16833e2%40googlegroups.com.

[Peter Ankerstål]

Will it be any time soon? 

Since users cant change their own passwords, and certificate authentication doesnt support encrypted keys Im now reduced to 0 useful ways for my users to authenticate.

One or both of them would be awsome.

[Jeff Mitchell]

Hi Peter,

No timeline yet. I'd love to see it in for 0.10 but can't make promises.

Best,

Jeff

To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/b6ea76f3-c93c-4722-8ac0-b4e18001e4a2%40googlegroups.com.