1--- 2layout: "docs" 3page_title: "Vault Enterprise Sentinel Integration" 4sidebar_title: "Sentinel" 5sidebar_current: "docs-vault-enterprise-sentinel" 6description: |- 7 An overview of how Sentinel interacts with Vault Enterprise. 8 9--- 10 11# Overview 12 13Vault Enterprise integrates HashiCorp Sentinel to provide a rich set of access 14control functionality. Because Vault is a security-focused product trusted with 15high-risk secrets and assets, and because of its default-deny stance, 16integration with Vault is implemented in a defense-in-depth fashion. This takes 17the form of multiple types of policies and a fixed evaluation order. 18 19## Policy Types 20 21Vault's policy system has been expanded to support three types of policies: 22 23- `ACLs` - These are the [traditional Vault 24 policies](/docs/concepts/policies.html) and remain unchanged. 25 26- `Role Governing Policies (RGPs)` - RGPs are Sentinel policies that are tied 27 to particular tokens, Identity entities, or Identity groups. They have access 28 to a rich set of controls across various aspects of Vault. 29 30- `Endpoint Governing Policies (EGPs)` - EGPs are Sentinel policies that are 31 tied to particular paths instead of tokens. They have access to as much 32 request information as possible, but they can take effect even on 33 unauthenticated paths, such as login paths. 34 35Not every unauthenticated path supports EGPs. For instance, the paths related 36to root token generation cannot support EGPs because it's already the mechanism 37of last resort if, for instance, all clients are locked out of Vault due to 38misconfigured EGPs. 39 40Like with ACLs, [root tokens](/docs/concepts/tokens.html#root-tokens) tokens 41are not subject to Sentinel policy checks. 42 43Sentinel execution should be considered to be significantly slower than normal 44ACL policy checking. If high performance is needed, testing should be performed 45appropriately when introducing Sentinel policies. 46 47## Policy Evaluation 48 49During evaluation, all policy types, if they exist, must grant access. 50Evaluation uses the following logic: 51 521. If the request is unauthenticated, skip to step 3. Otherwise, evaluate the 53 token's ACL policies. These must grant access; as always, a failure to be 54 granted capabilities on a path via ACL policies denies the request. 552. RGPs attached to the token are evaluated. All policies must pass according 56 to their enforcement level. 573. EGPs set on the requested path, and any prefix-matching EGPs set on 58 less-specific paths, are evaluated. All policies must pass according to 59 their enforcement level. 60 61Any failure at any of these steps results in a denied request. 62 63## Policy Overriding 64 65Vault supports normal Sentinel overriding behavior. Requests to override can be 66specified on the command line via the `policy-override` flag or in HTTP 67requests by setting the `X-Vault-Policy-Override` header to `true`. 68 69Override requests are visible in Vault's audit log; in addition, override 70requests and their eventual status (whether they ended up being required) are 71logged as warnings in Vault's server logs. 72 73## MFA 74 75Sentinel policies support the [Identity-based MFA 76system](/docs/enterprise/mfa/index.html) in Vault Enterprise. Within a single 77request, multiple checks of any named MFA method will only trigger 78authentication behavior for that method once, regardless of whether its 79validity is checked via ACLs, RGPs, or EGPs. 80 81EGPs can be used to require MFA on otherwise unauthenticated paths, such as 82login paths. On such paths, the request data will perform a lookahead to try to 83discover the appropriate Identity information to use for MFA. It may be 84necessary to pre-populate Identity entries or supply additional parameters with 85the request if you require more information to use MFA than the endpoint is 86able to glean from the original request alone. 87 88# Using Sentinel 89 90## Configuration 91 92Sentinel policies can be configured via the `sys/policies/rgp/` and 93`sys/policies/egp/` endpoints; see [the 94documentation](/api/system/policies.html) for more information. 95 96Once set, RGPs can be assigned to Identity entities and groups or to tokens 97just like ACL policies. As a result, they cannot share names with ACL policies. 98 99When setting an EGP, a list of paths must be provided specifying on which paths 100that EGP should take effect. Endpoints can have multiple distinct EGPs set on 101them; all are evaluated for each request. Paths can use a glob character (`*`) 102as the last character of the path to perform a prefix match; a path that 103consists only of a `*` will apply to the root of the API. Since requests are 104subject to an EGPs exactly matching the requested path and any glob EGPs 105sitting further up the request path, an EGP with a path of `*` will thus take 106effect on all requests. 107 108## Properties and Examples 109 110See the [Examples](/docs/enterprise/sentinel/examples.html) page for examples 111of Sentinel in action, and the 112[Properties](/docs/enterprise/sentinel/properties.html) page for detailed 113property documentation. 114 115## Learn 116 117Refer to the [Sentinel Policies](https://learn.hashicorp.com/vault/identity-access-management/iam-sentinel) 118guide for a step-by-step tutorial. 119