GatePlane Documentation

In technical terms

3 min read

GatePlane provides a series of Vault/OpenBao Source-Available Plugins (Elastic License v2) under Github. The plugins are designed to take advantage of Vault/OpenBao’s AuthN/AuthZ, integrations, and logging mechanism, adding the much needed Conditional Access aspect to Vault/OpenBao.

Authorization

As Vault/OpenBao plugins, they expose the functionalities of requesting, approving and claiming access under Vault/OpenBao paths (e.g: auth/gateplane-plugin/[request|approve|claim]), and as such, access to them can be configured using standard HCL Vault/OpenBao Policies. E.g (given a GatePlane plugin is mounted under auth/gateplane-plugin):

requestor.hcl

/*
This policy allows its bearer to create AccessRequests
and claim the access when properly approved.
*/
path "auth/gateplane-plugin/request" {
	capabilities=["update","read"]
}
 
path "auth/gateplane-plugin/claim" {
	capabilities=["update"]
}

approver.hcl

/*
This policy allows its bearer to approve and
monitor AccessRequests
*/
path "auth/gateplane-plugin/request" {
	// needed to be able to inspect created AccesRequests
	capabilities=["list"]
}
 
path "auth/gateplane-plugin/approve" {
	capabilities=["update"]
}

Identity Management & Authentication

Each of the GatePlane functionalities is bound to the concept of Vault/OpenBao Entities. They can only be accessed by leveraging the Authentication integrations (Auth Backends) available in Vault/OpenBao, such as OIDC/JWT (providers like Okta, Google Workspace, etc), Certificates, or Username / Password authentication.

This ensures that GatePlane is aware of which identities perform what actions, information that can be used for metrics, auditing and notifications.

Integrations

GatePlane taps in the Integrations of Vault/OpenBao for providing access, only adding the Conditional and Just-In-Time (JIT) aspect to them. This can be better demonstrated by an example.

An AWS Secrets Engine, that could generate credentials by issuing a GET Request to Vault/OpenBao path aws/account1/creds/role1, would mean a standing AWS access for the bearers of the below Vault/OpenBao Policy:

aws-access.hcl

path "aws/account1/creds/role1" {
	capabilities=["read"]
}

Assigning the aws-access policy directly results in the aforementioned standing AWS access, as one can ALWAYS read from this path and get new AWS Credentials.

GatePlane policy-gate plugin (mounted under auth/gateplane-plugin along with the previous requestor and approver Policies) would make this access conditional, as described in steps:

  1. Replace aws-access Policy with requestor for the desired user/Entity
  2. Configure GatePlane policy-gate to grant the aws-access Policy (easy as vault write auth/gateplane-plugin/config policies=aws-access)
  3. Add the approver Policy to users that should grant this specific AWS access

Hint

Approvers do not need to have access to the resource they approve access to.

Having an approver Policy does not require or overlap with the requestor Policy

Hint

Users can NEVER approve their own request.

Having both requestor and approver Policies on the same user does not result in Privilege Escalation

Now, this flow works out-of-the-box with ALL Vault/OpenBao Secrets Engines (Databases, Kubernetes, SSH, as well as AWS / GCP / Azure)!

Auditing

As GatePlane is another Vault/OpenBao plugin, access to it is logged in the same Vault/OpenBao log structure, and streamed where Vault/OpenBao is already being logged. A sample response log can be found below, for Entity 5ec53023-d998-6b3d-f58f-49976f3b1af7 requesting the access granted by the above AWS example (path: auth/gateplane-plugin/request), providing the informative reason: I want to get in.

{
  "time": "2025-07-01T09:46:52.41978581Z",
  "type": "response",
  "auth": {
	[...]
    "entity_id": "5ec53023-d998-6b3d-f58f-49976f3b1af7",
	[...]
  },
  "request": {
	[...]
    "operation": "update",
    "mount_point": "auth/gateplane-plugin/",
    "mount_type": "gateplane-policy-gate",
    "mount_accessor": "auth_gateplane-policy-gate_645f27d4",
    "mount_running_version": "v0.1.0-base0.2.1",
    "mount_running_sha256": "faff20703f53ab4dd2c8bf319ce571052f23c59e406188c37cb11f845b9eae6f",
    "mount_class": "auth",
    "mount_is_external_plugin": true,
	[...]
    "path": "auth/gateplane-plugin/request",
    "data": {
      "reason": "I want to get in"
    },
	[...]
  },
  "response": {
	[...]
    "data": {
      "exp": "hmac-sha256:cc4f790575cabb8ea6fcb220a168ffe03e6291a25b099d6b6006d88626890580",
      "iat": "hmac-sha256:b1d0c28ccd26970f39013585e2df0879e68dcde890a05a3a512035ecba037fae",
      "overwrite": false,
      "reason": "I want to get in",
      "request_id": "5ec53023-d998-6b3d-f58f-49976f3b1af7",
      "status": "hmac-sha256:09e24c800a285172f96f99a50bf6be1b468df0492dc8db27b0588d0489281238"
    }
  }
}

Hint

Such logs can be used by detection engineers to find problematic patterns, such as the same couple of requestor and approver performing together repeatedly, indicating possible insider threats.

Backlinks