how to renew AppRole secret-id?

[Russell Roy]

Simple question:   how to renew AppRole secret-id?

/ # vault write auth/approle/role/testrole period=20m

Success! Data written to: auth/approle/role/testrole

/ # vault write -f auth/approle/role/testrole/secret-id

Key               Value

---               -----

secret_id         5fb77b62-6f13-6c47-71b6-0404d9374063

secret_id_accessor dba393e5-221b-8401-28e0-e806e49b07d1

/ # vault token-renew 5fb77b62-6f13-6c47-71b6-0404d9374063

Error renewing token: Error making API request.

URL: PUT http://127.0.0.1:8200/v1/auth/token/renew

Code: 400. Errors:

* token not found

/ #

[Jeff Mitchell]

Hi Russell,

The secret ID is not a token; it and the role ID can be used to log
into Vault (similar to a username/password) to then retrieve an actual
Vault token. Therefore, you don't renew 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/e1b68252-4054-4b1c-8f39-d72faf360d2e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Russell Roy]

Jeff,

Thanks for your response, that helps...some.

I understand about the secret_id + role_id --> vault_token.  But what's got me confused is something which relates to this that you said in an earlier post in this forum:

"...The main benefit [with secret-id's] 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."

 

https://groups.google.com/forum/#!msg/vault-tool/w9HmAoT4d1U/dEhqhPCnBAAJ 

If secret ID can't be renewed then it will always be bound by an expiry..,, at least as per the approle parameters definitions:

    secret_id_num_uses (int)

        Number of times a SecretID can access the role, after which the SecretID

        will expire. Defaults to 0 meaning that the the secret_id is of unlimited use.

    secret_id_ttl (duration (sec))

        Duration in seconds after which the issued SecretID should expire. Defaults

        to 0, in which case the value will fall back to the system/mount defaults.

The workflow I'm trying to address here is one in which some (arbitrary) deployment engine deploys an app together with a wrapped secret id.   The app will use that to secure a Vault and Consul token ... but ,(I think), we want to avoid writing those as stateful info in some plain text config file.   Everything's fine so long as the app is up and running but, should the app (or node) for whatever reason restart, I'd like a way for the app to re-acquire Vault/Consul tokens without needing the deployment engine in the loop to issue a new secret id.

I thought the way I was going to go about that was by sticking something in an app signal handler which on the way out would re-wrap (with short time fuse) the secret ID and stick that out on disk for the app to use when it comes up again.    That of course only works if the secret ID can live forever or be renewed.   The secret_id_ttl says it can't live forever, and you say it can't be renewed.   So, I'm stuck.

Am I missing something or do I simply have the wrong approach for how AppRole is supposed to work?

Thanks,

Russell

[Jeff Mitchell]

Hi Russell,

I just looked at the code and checked behavior myself and as near as I
can tell from both, this is actually a documentation bug -- a 0 value
(the default) for the secret id TTL means no expiration. It's possible
that this changed somewhere in the implementation along the way and
the docs weren't updated at the time.

Do you actually see this behavior, or were you simply trying to figure
out an approach based on the docs?

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/f9fb1294-19d1-446f-bee9-cb7ab10de815%40googlegroups.com.

[Russell Roy]

Jeff,

Ok, that sounds like good news.   No, I hadn't actually tried it but was just formulating a plan based on the docs.

I'll go ahead and give that a try a little later on today.    If I find out it's behaves differently than you stated it should I'll get back to you.

Thanks for the quick turnaround on this.

- Russell

[Jimit Modi]

Hello Russell,

Did you tried the behaviour ? Not passing secret_id_ttl while creating the approle will it create never expiring secret_id ?

Thanks

[Sai Krishna]

Hi All,

In my case I am planning to provide secretID & RoleID during install, and I want to rotate secretID of my role at regular frequency. How do I achieve that.

What is the best way to share secretID with the clients

[Sai Krishna]

Can any one let me know , if it is possible to rotate secretID, else what is an alternative ?

[Roman Eos]

just run vault write -f again it will return you new secret id

пн, 20 мая 2019 г. в 12:19, Sai Krishna <saikrish...@gmail.com>:

--
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/f9c4a6f1-5800-4cd5-be1f-76f48933590b%40googlegroups.com.

[Sai Krishna]

Hi Roman, Thanks for the reply.

By doing so, my old secret-id and it's tokens are still valid .But  I want them to be revoked . As a security guide line I want to rotate my secret ID at regular intervals.

Thanks,

Sai.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAD0f7BZ%2BjFA5MsBcifBKvRqvWS_rrE9-k7b7Zn%2BExdbi_1Y0rA%40mail.gmail.com.

[Michel Vocks]

Hi there,

like Roman already said, you can generate a new secret-id by writing to the roles "secret-id" API endpoint.

If you want to revoke a secret-id and all child tokens you can do that by either providing the secret-id which should be revoked or you can also provide the secret-id accessor:

// Revoke by secret-id
vault write auth/approle/role/my-role/secret-id/destroy secret_id=192142cf-3492-0178-016e-39baee71a7e2

// Revoke by secret-id accessor
vault write auth/approle/role/my-role/secret-id-accessor/destroy secret_id_accessor=44c302c9-2cf9-4bb6-c939-c5148c433e4f

See the API documentation for further information:

https://www.vaultproject.io/api/auth/approle/index.html#destroy-approle-secret-id

https://www.vaultproject.io/api/auth/approle/index.html#destroy-approle-secret-id-accessor

Cheers,

Michel

Sai.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/f9c4a6f1-5800-4cd5-be1f-76f48933590b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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...@googlegroups.com.

[Sai Krishna]

Hi Michel, I have tried that but the tokens that are already generated are still valid after destroying the secretID?

Is that expected behaviour ?

Thanks,

Sai.

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/9e28f497-5239-485e-ad4e-d6d13ab81dd0%40googlegroups.com.

[Michel Vocks]

Is that expected behaviour ?

Yes, this is the expected behavior. It was also surprising for me at first but when you compare AppRole with the Username/Password auth backend then it makes sense.

For example, when you change a password from a user, you also don't expect that all child tokens are revoked and for the AppRole secret-id it is the same.

I assume that the only way (currently) to revoke the child tokens is to revoke all existing tokens created by the AppRole path e.g.:

vault token revoke -mode="path" auth/approle/

This will revoke all tokens created by the auth backend located at the path "auth/approle/".

In general, I think the best approach is to set a relatively short token TTL for the used AppRole role.

In that case, you don't have to force a manual rotation of all created tokens, instead all generated tokens will automatically be revoked after expiration.

Cheers,

Michel

[Sai Krishna]

Ok. Got it. 

I have kept the option of Having low TTL as last way of doing it. Looks like now I am left only with that . 

Thanks again Michel for all your inputs.

--

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/31f9eee1-5552-44e1-99e8-44aa823fcfe3%40googlegroups.com.