Is there a way to "audit" access to a particular secret - i.e. determine all parties with access?

[Ray Terrill]

Say I have an arbitrary secret /secret/mysecret - is there a way to see who has access to that (other than by inspecting all policies)?

[Calvin Leung Huang]

Ray,

There is no specific way to see who has access to a particular secret other than inspecting policies.

- Calvin 

[Dave Cottlehuber]

On Mon, 18 Jun 2018, at 19:18, Calvin Leung Huang wrote:
> Ray,
>
> There is no specific way to see who has access to a particular secret other
> than inspecting policies.
>
> - Calvin

Thanks for the clarification Calvin.

BTW when we decommissioned Novell File & Directory Services for Microsoft's Active Directory, policy verification was the feature I missed most. The ability to verify actual controls vs specified policies is part of many security audits, as are integration tests to programmers.

A+
Dave

[Jeff Mitchell]

Hi Dave,

We have an internal API that just came out that lets a token view a resultant set of policy. So far our use-case has been for UIs to better know what to show to the user as available options. However, we might be able to add the ability for this to be looked up via an accessor as well; that way anyone with appropriate access to view accessors for tokens could also understand the full set. Feel free to file a feature request on GitHub if you think this would work for you, and if you want to test it out now, you can run "vault read -format=json sys/internal/ui/resultant-acl" -- but you'll need 0.10.3.

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/1529513588.2625189.1414698272.01BF96C1%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[Ray Terrill]

Jeff -

What would be super slick for our use case is to be able to navigate to a particular secret in UI - then view that resultant set of policy granting access to that secret from the secret itself.

-Ray

[J. Konrad Tegtmeier-Rottach]

> We have an internal API that just came out that lets a token view a

> resultant set of policy. However, we might be able to add the

> ability for this to be looked up via an accessor as well; that way
> anyone with appropriate access to view accessors for tokens could
> also understand the full set.

I'd certainly be excited to see this become an official feature!

This seems quite handy for debugging and verifying permissions caused
by interacting policies, and for writing new ones, particularly when
there's a sizable corpus of existing policies involved.

It'd be particularly nice for these use-case if the endpoint for the
resultant policy itemized which policy(/ies) contributed to each of
the final resultant rules.

Regards,
KT