AppRole approach vs. Token approach

[Michael Hedgpeth]

I'm new to vault and am trying to understand two approaches to managing secret access. By reading the documentation, I came up with a workflow that looks like it will work for our more static provisioned infrastructure:

1. Create a policy for the application

2. Generate a token that has that policy

3. Store the token on the node using file permissions during provisioning phase

4. Configuration management (Chef/Ansible/Puppet) OR application reads that token in and authenticates with it

5. Configuration management OR application reads and uses the secrets

As I read the documentation, I see that my workflow is possibly not preferred and that I should be using AppRoles. That would change my approach to:

1. Create a policy for the application

2. Create an approle and assign it to the policy

3. Generate a secret-id from the approle (not sure how) 

4. Store the secret-id on the node using file permissions during the provisioning phase

5. CM or App uses the approle + secret-id to generate a token that will expire (not sure how this works, with CLI?)

6. CM or App now reads the secrets

The benefits of the AppRole is that you can expire tokens and even secret-ids much more easily since everyone doesn't share one. But everyone shares the secret-id so I'm not sure how this is better.

Am I missing something with the workflow description or the benefits of AppRole given my use case?

Thanks,

Michael

[Vishal Nayak]

Hi Michael,

> Generate a secret-id from the approle (not sure how)

You'll also need a mandatory role ID to be supplied to the login
endpoint. Secret ID is required only if the bound parameter set on the
role is `bound_secret_id` (which is set by default). After creating an
AppRole, endpoints `auth/approle/role/[role_name]/role-id` and
`auth/approle/role/[role_name]/secret-id` can be used to fetch a role
ID and to generate a secret ID. Note that the role ID is a constant
for a role (it is fetched), while the secret IDs are generated (which
is why everyone *need* not share a secret ID). The generated secret
IDs can have use-counts set, based on the role settings, thereby
controlling how many times an app can use a specific secret ID to
fetch Vault tokens.

> Am I missing something with the workflow description or the benefits of AppRole given my use case?

The endpoints to fetch role IDs and generate secret IDs are
authenticated paths, meaning that they require a valid Vault token to
be presented. A common question which the community asks is: "How can
we use role IDs and secret IDs when they themselves need a token in
the first place?". To explain this situation, I'll resort to an
exemplary use case. Assume that the goal is to have a setup like this:
"Vault admin should set up AppRoles, a dedicated service should fetch
role IDs from the backend and another dedicated service should fetch
new secret IDs from the backend. The credentials should be
bootstrapped into Apps, VMs, Services or whatever. All these should
happen with acceptable levels of security, in the sense that the
intermediate hops (dedicated services, which may be CM tools, or a
series of untrusted services) should be NOT be able to fetch Vault
tokens themselves, and in case they did, it should be successfully
detectable".

The Cubbyhole Authentication Principles (termed Response-Wrapping
feature in Vault)
[https://www.hashicorp.com/blog/vault-cubbyhole-principles.html], in
combination with AppRole authentication backend makes a genuine
attempt at providing a solution to this problem. In a simplistic case,
only one single entity may set up AppRoles, fetch the role IDs and
fetches new secret IDs. In this case, accountability will be implicit
and the same service can bootstrap the credentials into the Apps and
Services.

In a slightly stringent setup, dedicated tokens can be issued to all
the intermediate hops by the Vault admin. These tokens can just do
what they are destined for, like, just fetching the role ID, or just
fetching the new secret IDs. Ideally, these intermediate hops will
only have partial access to the credentials and won't be able to fetch
actual Vault tokens since the credentials are spread across by
different services. AppRole fits nicely into this use case since the
role ID and the secret ID paths are ACL-able and specific tokens can
be issued for these.

For even more complex setups where properties like confidentiality,
integrity and non-repudiation are desired, an impressive and a proud
twist, response-wrapping comes to the rescue! By simply specifying a
flag (-wrap-ttl) while fetching the role IDs and/or secret IDs, an
actual response is NOT returned. Instead, actual response will be
stored in a newly generated token's cubbyhole, and this new token is
returned. The use count on this new token will be 1. The services
which are supposed to simply bootstrap the credential into services,
if unwrap the wrapped token and peeks into the secret, then the actual
service won't be able to do it (which is clearly detectable). Only the
actual service, ideally should unwrap all the shards of the
credentials and use them to fetch a Vault tokens. This is simply
fabulous for various setups involving too many untrusted services in
the pipeline. On top of this, wrapped tokens expire after its TTL
expires, providing more control on the timing of the credential usage.
All unwrap requests can be monitored using Vault's audit logs.

These are the few benefits of AppRole. There are more, in the sense
that, not just the path that creates/updates the role, but each field
modification of an AppRole can also be ACLed. Its designed to be
extremely flexible for control delegation.

I hope people find this information useful.

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/6ad5623c-7b58-4b5f-8722-40db1c0d76a2%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
vn

[Michael Hedgpeth]

Vishal,

Thanks for the response. I read it over many times and it has helped me better understand the feature.

This brings up another couple of questions:

What is the process for when/if the token generated by the secret-id/role-id expires? I understand the process for initial provisioning but not for after that. Should the token have read rights to the secret-id so when it expires, it can generate another one?

We will probably introduce vault in phases, first phase being secrets read from CM and later on the secrets being read from the applications themselves. We don't want to do it all at once. Is it safe to say in this situation that the role-id/secret-id workflow would be beneficial. The way I see it the CM is acting as the "application" in this situation.

Thanks again,

Michael

[Vishal Nayak]

Hi Michael,

> What is the process for when/if the token generated by the secret-id/role-id expires? I understand the process for initial provisioning but not for after that.

A role ID does not expire, unless the operator deletes the role at the
backend. Secret IDs also do not expire by default, but can be assigned
a TTL so it expires, neither will it have the "number of uses" set by
default. But the tokens issued will have a TTL associated with them
and they will eventually expire. It is the job of the applications to
maintain the Vault tokens issued. It really depends on the how the
setup is, either the application itself may renew and/or rotate the
tokens, or another dedicated process may do it, or a dedicated service
may do it. Based on the organizational policy, applications may simply
fetch new tokens if the secret ID lives for a relatively longer
duration and if they are configured to be used multiple times.

> Should the token have read rights to the secret-id so when it expires, it can generate another one?

I guess this factor could also be wired in. Note that there are
separate endpoints for reading the properties of secret ID using
secret ID itself or using its accessor. You could choose to delegate
the one you deem fit.

> We will probably introduce vault in phases, first phase being secrets read from CM and later on the secrets being read from the applications themselves. We don't want to do it all at once. Is it safe to say in this situation that the role-id/secret-id workflow would be beneficial. The way I see it the CM is acting as the "application" in this situation.

Yes, CM in this case acts as the "application", in other words, a
client to Vault. Configuring the backend and the services in phases
sounds sane to me. As long as the credential dependencies are resolved
in topological order, things should behave well. As of today, there
are two types of bounds (it is likely going to increase over time)
available on the backend: `bind_secret_id` and `bound_cidr_list`. So,
a combination of `role_id/bound_cidr_list` may also be a good fit for
some of your applications.

Regards,
Vishal

> https://groups.google.com/d/msgid/vault-tool/63be414d-ff2e-4e1f-9ff2-ed82c5a2ea68%40googlegroups.com.

[Jeff Mitchell]

Hi Micahel,

> What is the process for when/if the token generated by the secret-id/role-id
> expires? I understand the process for initial provisioning but not for after
> that. Should the token have read rights to the secret-id so when it expires,
> it can generate another one?

Secret-id/role-id are similar to a username/password -- it's a
credential that allows you to get a Vault token, but it provides an
indirect layer of management (for instance, it can be easier to find
and remove valid secret IDs than tokens). Generally speaking you will
simply re-use the same secret-id to get a new Vault token.

> We will probably introduce vault in phases, first phase being secrets read
> from CM and later on the secrets being read from the applications
> themselves. We don't want to do it all at once. Is it safe to say in this
> situation that the role-id/secret-id workflow would be beneficial. The way I
> see it the CM is acting as the "application" in this situation.

Sure, that's one way that it can be done. Another common workflow at
this point is that people the CM master nodes a more privileged token
that allow it to generate secret-ids (or generate tokens directly),
response wrap those values, and pass it down to the local agent to
give to the application.

Best,
Jeff

[bar...@bossanova.com]

If I revoke/delete a secret_id or role_id are tokens created from that secret_id/role_id revoked?

If that isn't the case, is there a chain of api calls that I can make so I can go from role_id to the tokens created under it?

Thanks!

-b

[Jeff Mitchell]

Hi Barrett,

This is not currently possible, although we have some work going on in
the next few months that will enable this kind of workflow.

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/9e10bf0f-0d68-482d-b23f-0c491f197ada%40googlegroups.com.

[Michael Hedgpeth]

Jeff, to aid in your prioritization, one of my colleagues was asking this same question: how can we audit where the secret-ids are being consumed and how do we revoke them outside of a normal lease policy? I'll tell him that this is in the works.

Thanks,

Michael