Sentinel policies offer a powerful way to enforce granular access controls in Vault, going beyond basic ACLs. When dealing with advanced authentication methods like Enterprise Gateway Policies (EGP) and Restricted Gateway Policies (RGP), understanding how Sentinel interacts with these mechanisms is key.
Let’s see Sentinel in action with a simplified EGP scenario. Imagine a policy that only allows an identity from a specific "engineering" namespace to authenticate via EGP.
# Example Sentinel Policy for EGP
policy "egp_engineering_access" {
path "auth/jwt/login" {
capabilities = ["create"]
# This is a simplified example, actual EGP checks would be more complex
# and involve checking claims within the JWT token itself.
# For demonstration, we'll assume a claim 'namespace' exists.
# In a real scenario, this would be handled by EGP's internal logic
# which Sentinel can then query.
}
# This rule demonstrates how Sentinel *could* interact with EGP claims
# if EGP exposed them directly for policy evaluation.
# The actual mechanism involves EGP's internal validation.
# This is illustrative of the *principle* of restricting by identity attributes.
rule "allow_engineering_namespace" {
# This 'claim' is hypothetical for Sentinel's direct access.
# EGP handles the validation of the actual JWT claims.
# Sentinel's role here is to enforce *after* EGP has validated.
# A more realistic Sentinel rule would check attributes *derived* from EGP's success.
# For this example, let's assume EGP successfully authenticates and
# Sentinel then checks a *derived* attribute or a separate identity lookup.
# Let's simulate a successful EGP auth that provides an 'egp_namespace' attribute.
# In reality, Sentinel would evaluate attributes associated with the authenticated identity.
when {
# This condition would typically be met if EGP successfully authenticated
# and attributed the identity to the 'engineering' namespace.
# The exact way this attribute is exposed to Sentinel depends on Vault configuration.
# For demonstration, we use a hypothetical attribute 'egp_namespace'.
# A real-world policy might check 'vault.identity.entity.alias.metadata.namespace'
# after an EGP-authenticated entity has been processed.
# Simplified representation: Assume EGP success implies a namespace attribute
# that Sentinel can inspect.
# If EGP is configured to map namespaces, Sentinel might check entity attributes.
# For this example, let's assume EGP successfully authenticated a user
# and an associated entity has a metadata tag indicating the namespace.
# The actual check would look at the authenticated entity's properties.
# Let's assume the entity has a metadata key 'namespace' populated by EGP.
vault.identity.entity.metadata.namespace == "engineering"
}
allow = true
}
}
This Sentinel policy egp_engineering_access aims to restrict access to the auth/jwt/login endpoint. The rule "allow_engineering_namespace" is where the logic gets interesting. It conceptually checks if the authenticated identity, after being processed by EGP, belongs to the "engineering" namespace. The when block uses a hypothetical vault.identity.entity.metadata.namespace == "engineering" condition. In a real EGP integration, EGP would validate the incoming JWT, potentially mapping claims within the token to Vault identity entities and their metadata. Sentinel then acts on these established identity attributes. If EGP successfully authenticates a user whose token claims are mapped to the "engineering" namespace by EGP, and this namespace information is stored as metadata on the Vault identity entity, Sentinel can then enforce policies based on that metadata.
The core problem Sentinel policies solve with EGP and RGP is moving beyond "who can authenticate" to "who can authenticate how, and under what conditions, based on their organizational identity." EGP and RGP act as sophisticated identity brokers, validating external identity tokens (like JWTs, SAML assertions, or OIDC tokens). Sentinel then layers fine-grained authorization on top of these validated identities.
Internally, when a user attempts to authenticate via EGP/RGP, Vault first passes the request to the configured EGP/RGP auth method. This method validates the external token against its configured identity provider (e.g., Okta, Auth0, Azure AD). If validation is successful, EGP/RGP can optionally create or update a Vault identity entity and associate aliases with it, often enriching these entities with metadata derived from the identity token’s claims (like group memberships or organizational roles). Once the identity is established in Vault, Sentinel policies are evaluated against the requested operation (e.g., create on auth/jwt/login) and the attributes of the authenticated identity.
The exact levers you control are manifold. You can dictate which EGP/RGP configurations are allowed to authenticate to specific Vault paths. You can enforce that authentication must come from a specific identity provider configuration. Crucially, you can enforce policies based on the attributes of the authenticated identity, such as group memberships, roles, or namespaces that EGP/RGP has mapped and associated with the Vault identity entity. This allows for dynamic, attribute-based access control that adapts as your organizational structure or user roles change.
The most surprising truth is that Sentinel policies don’t directly validate the external identity tokens themselves; they validate after EGP/RGP has done the heavy lifting. Sentinel’s power lies in its ability to enforce rules based on the outcome of EGP/RGP’s validation and the resulting Vault identity attributes. It’s a crucial distinction: EGP/RGP is the gatekeeper for authentication, while Sentinel is the bouncer for authorization based on who got past the gatekeeper and what we know about them.
A common pitfall is assuming Sentinel can directly inspect claims within an incoming JWT before EGP/RGP has processed it. Sentinel operates on the context of the authenticated request within Vault. If EGP/RGP is configured to map a JWT claim like roles: ["auditor"] to a Vault entity’s metadata tag vault.entity.metadata.roles = "auditor", then your Sentinel policy can indeed check vault.entity.metadata.roles == "auditor". But Sentinel won’t see the raw roles claim directly; it sees the result of EGP/RGP’s mapping.
The next logical step is exploring how to use Sentinel to control access to specific Vault secrets after an EGP/RGP-authenticated user has obtained a token.