Revoke all tokens by using display-name or meta data?

[Allan Feid]

Hello all,

I'm wondering if there is currently a way to revoke all tokens or leases based on their meta data. 

If not, my use case is largely around creating tokens with specific policies applied where authentication is done outside of vault. 

Each of the tokens has the username in the metadata and a deterministic display-name. I'd like to be able to revoke all of those by using a username (which is only part of the metadata). One work around I can think of is to store username => lease-id and then call the revoke API for each lease-id in my mapping for an individual user. 

I tried looking into the /sys/raw piece, but it seems I would have to use the consul api to list all keys in sys/token/id, then use the vault api to retrieve each token ID to inspect the metadata for each token. This may be the best way to ensure all tokens for a given user have been revoked.

Thanks,

Allan

[Jeff Mitchell]

Hi Allan,

On Thu, Jun 9, 2016 at 11:41 AM, 'Allan Feid' via Vault
<vault...@googlegroups.com> wrote:
> I'm wondering if there is currently a way to revoke all tokens or leases
> based on their meta data.

There isn't a built-in way, partly because Vault doesn't currently
index and store this information (there are various reasons why that
is a challenge in Vault, in large part because many of its potential
storage subsystems are sensitive to key counts). However...

> Each of the tokens has the username in the metadata and a deterministic
> display-name. I'd like to be able to revoke all of those by using a username
> (which is only part of the metadata). One work around I can think of is to
> store username => lease-id and then call the revoke API for each lease-id in
> my mapping for an individual user.

There's no lease-id for tokens -- there's just the token ID which you
probably don't want to store. However, since 0.5.2 tokens are now
issued with accessors that can be used to perform lookups and/or
revocation on a token without knowing the token ID.

So one possibility is to store a mapping of token accessors to each
user. This is much safer than storing the token IDs, and easy to do if
you have a system generating tokens for users.

Another possibility is to enable an audit mount with the hmac_accessor
option set to false. Since token metadata is audit-logged in
plaintext, if the accessor is also logged in plaintext, you could
easily parse through the audit logs as needed to get the list of
accessors belonging to a particular user, and then revoke the
corresponding tokens.

Hope that helps!
--Jeff

[Allan Feid]

Jeff,

Thank you for the response. I went with using consul to list sys/token/id/ and the raw api to retrieve each of those tokens. This way I didn't have to worry about maintaining a mapping and possibly missing anything related to a user.

Thanks,

Allan

--
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 a topic in the Google Groups "Vault" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vault-tool/nrmNgBwhBEc/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/CAORe8GFXn-4fX9rEQsBRLJ4An26WhJvv29EQ5HN92yGJ%2BVauyw%40mail.gmail.com.

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

[fcioc...@mintel.com]

Hi

I am trying to reproduce exactly the same thing , using the raw api to get a list of all tokens. 

I am currently using the "file backend" since i am just testing this, so i have structure like

VAULT/sys/token/id/_TOKEN_ID1 

I am really struggling to get the sys/raw api to get me the ID 

Everything i do just return an Empty result. 

curl -H "X-Vault-Token: XXXXX" -X GET http://localhost:8200/v1/sys/raw/_TOKENID 

{"errors":[]} 

For sure i am doing this wrong but i can't seem to find any example whatsoever on how to use this API , could you share an example of your working code ? 

Thanks

[fcioc...@mintel.com]

I managed to get one more step, but still getting empty value in return 

./vault read /sys/raw/sys/token/id/XXXXXXXX

Key     Value

---     -----

I am trying to get back the "ID" of the token, which as far as i understand is a decoded version of the XXXX above, so that i can then pass it to 

./vault token-lookup DECODED_ID 

and get the info i need about the token , like TTL left and so on ... 

Is this even the right way to do it ? 

[fcioc...@mintel.com]

Seems like my problem is with the "vault" cli client, 

I am using the ROOT TOKEN ID for my auth

Quering the HTTP Endpoint is returing the info i need , but using the vault cli on the very same Endpoint returns empty. 

$ curl -H "X-Vault-Token: MYROOTTOKEN" -X GET http://localhost:8200/v1/sys/raw/sys/token/id/XXXXX | jq -r .value | jq .

  

{

  "Role": "",

  "ExplicitMaxTTL": 0,

  "TTL": 0,

  "CreationTime": 1468931436,

  "ID": "XXXXID",

  "Accessor": "XXXXACCESSOR",

  "Parent": "",

  "Policies": [

    "root"

  ],

  "Path": "auth/token/root",

  "Meta": null,

  "DisplayName": "root",

  "NumUses": 0

}

$ /data/tmp/vault read -format=json sys/raw/sys/token/id/XXXXX                    

 {

        "lease_id": "",

        "lease_duration": 0,

        "renewable": false,

        "data": null,

        "warnings": null

[Jeff Mitchell]

Hello,

The CLI is an API client and as such is expecting data in a format it knows about and can parse. Anything that you get from the raw endpoint will be in an arbitrary format, so it is unable to decode any expected structure. That's why you are seeing this behavior.

Best,
Jeff

Mintel Group Ltd | 11 Pilgrim Street | London | EC4V 6RN
Registered in England: Number 1475918. | VAT Number: GB 232 9342 72

Contact details for our other offices can be found at http://www.mintel.com/office-locations.

This email and any attachments may include content that is confidential, privileged
or otherwise protected under applicable law. Unauthorised disclosure, copying, distribution
or use of the contents is prohibited and may be unlawful. If you have received this email in error,
including without appropriate authorisation, then please reply to the sender about the error
and delete this email and any attachments.

--
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/fe521214-2a54-474b-933f-d7b5a837863b%40googlegroups.com.