App Role authentication backend

[Michael Wain]

Hi All!

Im just looking over the documentation for App Role (https://github.com/hashicorp/vault/blob/master/website/source/docs/auth/approle.html.md)

Am i right in thinking that for an app to get a secret-id, it require the role-id and an vault-token?

Would one or both of role-id and vault-token need to be secret? As the combination of the 2 would allow access to the vault?

[Adam Greene]

Hey Michael,

Would one or both of role-id and vault-token need to be secret? As the combination of the 2 would allow access to the vault?

vault-token: yes.  

role-id: depends on your security requirements, and whether and how you are using a secret ID.  If you are using a secret ID, at least for us, the answer was no (we store it in our docker meta-data)

vault-token + role-id: should not give you 'full' access to vault.  Policies and roles are your friend :)

as a thought experiment, and to help me wrap my head around this, I compared a single token approach vs app-role.  Now anytime my thoughts are involved, all the caveats apply :)

Simple flow:

  - get a token (e.g. aws-ec2 host-specific token)

  - use that token to get new tokens tied to a specific policy and inject that into your app

Pros: easy to understand

Cons: The host token can do all sorts of things *at run time*.  Yes, you can limit its actions, via a policy, to specific `/auth/token/create/[role_name]`, but it still leaves open a lot of choices that a script (or errant user) can run at run-time.

App-role:

  - get a token (e.g. aws-ec2 host-specific token)

  - either:

    - use that token, in conjunction with a role-id, to be able to get a secret

    - have a separate process get a secret

    - forgo requiring a secret (it is required by default but you can disable this)

  - use token, role and secret to get a new token 

Pros: Flexibility!  You can configure all sorts of parameters (use limits, ttls, etc) and polices at *configuration* time rather than at run time.  The host token can be setup to only do one or two very specific actions with very short TTLs and nothing else.  There is also more flexibility to separate out who and what can handle role_ids, host token, and secrets.

Cons: Flexibility!  :)

Hope that helps,

Adam

 

[Michael Wain]

Hi Adam!

Thanks for the reply, really helpful!

> vault-token + role-id: should not give you 'full' access to vault.  Policies and roles are your friend :)
Perhaps i used 'access to vault' loosely, what i meant they would have access to the secret data the policies attached the to role-id ? 

Still struggling the the host token concept + role-id.

This is how i think it should be implemented:

If i had 5 host/apps which needs access to some secrets which are restricted with policy 'my-secret-policy'.

• Create an approle named 'myapp' with the policy 'my-secret-policy'
• Generate a vault token for the 5 host/apps with a policy which is restricted to '/auth/approle/role/myapp/role-id' and '/auth/approle/role/myapp/secret-id'
• Use the vault token to get the role-id and secret-id
• Use the role-id and secret-id to '/auth/approle/login' to get a vault token to access secrets

Now the problem i can see with the above approach is all that is needed is the host vault token to get access secrets protected by 'my-secret-policy'? 

If i was to ship host vault token + role-id to the 5 hosts/apps the same issue is i have all the info required to access the secrets?

Puzzled what protection this is giving, or am i implementing it wrong.

[Jeff Mitchell]

Hi Michael,

The idea isn't to give your services a Vault token to allow them to
generate secret-ids; the idea is you give them the secret-id instead.
(You can also use the app-id model of pushing your own secret-ids in.)

The main benefit you have over giving out tokens is that when a token
fetched with an approle secret-id expires, the secret-id (unless also
bound by an expiry or use-count) can be used to get a new token.
Otherwise you have to give your application a new token somehow.

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/5438c443-8c9c-49e8-ad1c-3c5292a7008d%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Michael Wain]

Hi Jeff,

From what i can see from the docs, a low privileged token needs distributing to the apps for them to pull a secret ID?

I'm probably miss understanding the workflow. Could provide a quick example on how apps/services would auth?

Michael

> 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/w9HmAoT4d1U/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/CAORe8GE1WD9qD2cCEAw8EbK8Ku5%3DW-NYGBqQx8zxARTZ0Gwhtw%40mail.gmail.com.

[Jeff Mitchell]

Hi Michael,

In your model, you are giving them a token that they use to get a
secret ID. Just give them the secret ID instead!

Best,
Jeff

> To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/04CCA05C-2715-41EF-8157-4E66DD4C4495%40gmail.com.

[Michael Wain]

Hi...

_scratches head_ but... I'm needing to generate "pull" a secret-id from vault?

Michael

> To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAORe8GH-KaBD%2BEOTC%3DXbVxai9kk7ayCBTxBan6jSDie_999GtQ%40mail.gmail.com.

[Jeff Mitchell]

Hi Michael,

The thing that pulls out the secret-id doesn't need to be your end
client, and isn't intended to be. Rather than you as an operator
generating a token and giving that to your client, you as an operator
pull out a secret-id from the appropriate role and give that to your
client.

Best,
Jeff

> To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/7DF8199B-67E6-4FB1-88AA-0C6D24558B37%40gmail.com.

[Michael Wain]

Oh.. Ok I read it as the app/service will be authenticating.

So I still need to somehow generate and distribute the secret-Id(securely) to the apps/services?

Michael

> To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAORe8GG1Gvkohh8RHjbroj_kFCBS_MCx0RTfgpxt05Wkh0f1CA%40mail.gmail.com.

[Jeff Mitchell]

Yes -- but response wrapping
(https://www.vaultproject.io/docs/concepts/response-wrapping.html) can
be a really good building block!

Best,
Jeff

> To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/6DD5BF32-DF82-4468-A7B6-798B75CF91FF%40gmail.com.

[Richard Mauri]

Aha, so a system that integrates cubbyhole and approle together would be a replacement for our current appid with homegrown/ad-hoc credential discovery mechanism.

When might Nomad be integrated into a final solution to distribute wrapped credentials?

I think it is the missing link. Right? Might I hold fast with our appid mechanism until that is in place

- Richard

[Jeff Mitchell]

Hi Richard,

Vault/Nomad integration is coming. Soon!

Best,
Jeff

> https://groups.google.com/d/msgid/vault-tool/eb14c883-0628-4111-9548-6395e3ee1a86%40googlegroups.com.

[Lars Sommer]

Hello! I am very familiar with the App-ID method of authentication and indeed built a full automation pipeline around it for new API's to have access to datastores and secrets, but I am having a hard time wrapping my head around the App-Role concept.

Can someone outline the major differences between the two? Is Secret-ID the successor to User-ID in the App-ID authentication model? 

[Vishal Nayak]

Hi Lars,

> Can someone outline the major differences between the two?

AppRole attempts to solve some of the problems which the AppID backend
had. For example, not able to list out the user-ids, questionable
uniqueness of app-ids, by design not being able to support multiple
different authentication factors, etc. Also, along with the solutions
to the shortcomings, AppRole supports all the use cases that were
satisfied by the AppID backend, through its "Push" model.

> Is Secret-ID the successor to User-ID in the App-ID authentication model?

Sort of, yes, but more flexible and powerful, since the SecretIDs can
have their own TTL, usage counts, and accessors. Coupled with the
response wrapping, AppRole can be a very strong authenticator.

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/f1f65fa7-db42-4958-a272-b66e94009148%40googlegroups.com.

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



--

vn

[Michael Fischer]

When you create the AppRole, specify the policy list (comma-separated) as an argument-value pair. https://www.vaultproject.io/docs/auth/approle.html  (under /auth/approle/role/[role_name]).

On Fri, Oct 28, 2016 at 9:43 AM, Lars Sommer <lars.j...@gmail.com> wrote:

Ok I think that makes sense, but I can't seem to map a policy to the AppRole the same way I could map a policy to App-ID. How does one assign a policy to an AppRole?

I used to hit:

curl -s -o /dev/null -w "%{http_code}" \

    -H "X-Vault-Token: $VAULT_IRT" \

    -H "Content-Type: application/json" \

    -X PUT \

    -d '{"value":"policy_name"}' \

    $VAULT_ADDR/v1/auth/app-id/map/app-id/$VAULT_APP_ID

But I don't see the same functionality with AppRole.

https://www.vaultproject.io/docs/auth/app-id.html

vs

https://www.vaultproject.io/docs/auth/approle.html

I'm probably missing an obvious redesign or something. 

On Wednesday, August 17, 2016 at 7:33:44 AM UTC-7, Michael Wain wrote:

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/8598afc1-03de-4876-84e7-22776c52340e%40googlegroups.com.