Quartz 5

Vault API - Architecture

4 min read

pentest api-security vault aws ssm okta appsec

Vault API — Architecture

Architecture and trust-boundary detail for the Vault API engagement. Information is classified by certainty — see kickoff to validate To Confirm items.

Architecture Diagram

flowchart TD
    subgraph Network
        U[User / Application] --> VPN[VPN / Genesys VPC]
    end

    subgraph Identity
        VPN --> Okta[Okta SSO]
        Okta --> Token[Bearer Token]
        Okta --> SSO[SSO Group]
    end

    subgraph Authorization
        Token --> Vault[Vault API]
        SSO --> Vault
        TeamID[Team ID] --> Vault
        Vault --> AuthZ[Vault Authorization Logic]
    end

    subgraph Backend
        AuthZ --> IAM[AWS IAM / Backend Role]
        IAM --> SSM[AWS SSM Parameter Store]
    end

    subgraph Environments
        Vault --- Test[Test]
        Vault --- Staging[Staging]
        Vault --- Prod[Production]
    end

Confirmed

Confirmed

  • Vault API is an internal secrets-management API.
  • AWS SSM Parameter Store is the backend storage layer.
  • Vault provides an abstraction / security layer in front of SSM.
  • The pentest focuses on Vault’s API, authorization logic, identity boundaries, secret handling, and backend AWS permission scope — not attacking SSM directly.

Inferred / Working Assumptions

Inferred

The following reflects engagement prep documentation. Validate during kickoff.

Request Path

User/Application → VPN/VPC → Okta → Bearer Token → Team ID / Authorization → Vault API → AWS SSM Parameter Store

Trust Boundaries

BoundaryExpected Role
VPN / VPCNetwork access control — only trusted clients reach the API
Okta authenticationIdentity proof — who is calling
Bearer tokenSession credential derived from Okta SSO
SSO groupGroup membership that may influence access
Team IDAuthorization scope — which team’s resources are in play
Vault authorization logicServer-side enforcement before SSM calls
AWS IAM / SSM permissionsBackend role scope — what SSM paths the service can reach
Environment separationTest / Staging / Production isolation

Core Authorization Question

Important

How does Vault map an authenticated Okta identity + Team ID to the exact secrets/resources that identity is allowed to access?

Team A must not reach Team B by manipulating:

  • Team ID
  • Secret / resource ID
  • Parameter path or name
  • Application ID
  • Request context (headers, body fields, query params)

AWS SSM Parameter Store

Inferred

  • SSM = backend key/value parameter and secret storage.
  • Vault = front-end authorization and abstraction layer.

Important

The main pentest question is not “Can AWS SSM be hacked?” The main question is:

“Can Vault cause SSM to return something the caller should not be allowed to access?”

Example scenario:

  1. User is authorized only for Team A.
  2. Vault’s backend AWS role has access to Team A, Team B, and Team C SSM paths.
  3. Vault must enforce the Team A boundary before making any SSM request.

Warning

If Vault passes through an out-of-scope path or ID, the backend role may return the secret — the failure is in Vault’s authorization, not in SSM.

AWS IAM / Backend Permission Boundary

Inferred

  • Vault uses an AWS IAM role to access SSM.
  • That role may have broader SSM scope than any single caller.
  • Application-level authorization in Vault is therefore critical.

See Vault API - Test Cases > AWS Permission Boundary for testing ideas.

Environment Boundaries

Inferred

Distinct environments expected: Test, Staging, Production.

Potential crossover risks to validate:

  • Identity crossover — staging token reaching production
  • Data crossover — production secrets in non-production
  • Permission crossover — broader IAM in lower environments

Downstream Consumers

Inferred

The GForge engagement source documents a runtime secret path: Internal Vault → AWS SSM Parameter Store → External Secrets Operator → application environment variables. This suggests applications consume Vault-managed secrets indirectly through SSM rather than by calling the Vault API at runtime.

To Confirm

Whether the “Internal Vault” in that path is this Vault API or a different internal Vault component. The GForge source does not establish this, so do not assume the two are the same service.

Detail lives with the consuming engagement → GForge - Architecture > Supporting Secret and Configuration Path

To Confirm

To Confirm

All items below must be validated during kickoff / testing. Full list: Vault API - Kickoff Questions

  • How Okta identity maps to Team ID
  • Whether Team ID is client-controlled or server-derived
  • Backend AWS IAM role and SSM scope
  • SSM naming / path convention
  • Test vs Staging vs Production differences
  • Logging and audit locations
  • Supported secret lifecycle operations (read / create / update / delete / rotation)

Graph View

Backlinks