Suggestion for Sentinel Playground: initial mock/policy for Vault

Sentinel
1

The current Sentinel Playground displays an initial sample policy and mock suited for Terraform use-cases.

It would be nice to have an option to choose initial setup suited for Vault Sentinel use-cases instead.

2

Hi @maxb

Firstly, thanks a lot for the feedback, I really appreciate you taking the time to help us improve the Sentinel Playground experience.

Do you have any thoughts on what the right policy example might be for Vault? If you could share an example of the first use case that you needed to implement in Vault that would be great.

Regards,

Ryan Hall

3

I found the hardest part of using Sentinel with Vault specifically, being figuring out which properties are available to test.

Sentinel Properties | Vault by HashiCorp does exist but it’s fairly minimal, and also wrong in places. (Don’t ask me exactly where right now - I’m responding at the weekend, without access to my workplace’s Vault Enterprise installation, but I’ll try to remember and file a separate report later.)

Therefore, I think the most useful thing the Playground could do, would be to provide a pre-written set of mocks, which showcase as much of the available properties from a real example Vault request as possible.

So:

  • A namespace mock that describes the real values returned by Vault for the root namespace. Bonus: include a commented out example for a request to an example child namespace.

  • A request mock - pick some example request - say a read from a KV (that’s a commonplace thing nearly everyone is going to want to do) - and show all of the properties from a real example Vault request of that type.

  • A replication mock - let’s just pretend this Vault is both a DR and Performance primary for example’s sake. Bonus: comments describing all other possible values of the state.

  • A token mock - again, just a dump of the available data for a real Vault request.

  • An identity mock - same again, but this one is really important as it’s both a complex structure, and one people are particularly likely to want to use in enforcing access.

  • An mfa mock - I don’t actually use this feature, but it wouldn’t hurt to include this for completeness

  • A controlgroup mock - Control groups pretty much REQUIRE use of Sentinel to prevent self-approval of requests, so this is an important one

And then for the script itself it would be a balance of showcasing a few interesting features without being too overwhelming.

Some examples that come to mind:

  • Assume that a control group is being used, and check the request isn’t being approved by the same entity that made it.

  • Check whether the token contains a policy named ‘out-of-hours-access’, and if not, deny if outside of 9am-6pm

  • Do a regex match on the identity alias name, confirm it doesn’t end with ‘-guest’

(That last one, is because I went for months believing Sentinel lacked regex match capability, because there is no mention of it in Import: strings | Sentinel by HashiCorp - because it’s not part of the strings namespace, but is a core language operator.)

2 Likes