Envase Vault Security Model
This document describes how Envase Vault controls access to the secrets it manages. It is intended for developers integrating with Envase Vault, for reviewers assessing the service, and as a record of the access decisions the service deliberately makes.
Trust Boundary
Envase Vault serves a restricted set of internal Envase applications and services. Credentials to access Envase Vault are issued only to those clients. Envase Vault has no external, customer-facing, or self-service clients, and customers never communicate with Envase Vault directly.
This is the primary access control for the service. Every other control described in this document operates inside that boundary and assumes the caller is already a trusted Envase client. The consequence worth stating plainly is that Envase Vault does not attempt to defend one authorized client from another. It defends the secrets it holds from everything outside the boundary.
Access Paths
Envase Vault exposes two interfaces, and they are governed by two different control planes. A client uses one or the other, not both.
REST API
The REST API is fronted by Amazon API Gateway and protected by an Amazon Cognito authorizer. A caller must present a valid access token obtained through the standard Authentication/Authorization process, and the token must carry the scope required by the route it is calling. Authorization is enforced at the gateway, before the service code is invoked.
Each environment has its own Amazon Cognito user pool. A token issued for one environment is not accepted by any other.
AWS Lambda Functions
The AWS Lambda functions are not behind the Amazon Cognito authorizer, and OAuth scopes do not apply to them. Access is governed entirely by AWS IAM: the caller’s execution role must be granted permission to invoke the specific function. These functions are not reachable from the public internet.
Important
Because the two interfaces are governed by different controls, restricting a client’s scopes on the REST API does not restrict what that client can do through the function interface, and the reverse. A client deployed inside the Envase AWS account should be granted AWS IAM invoke permission only for the functions it actually uses.
Secrets Are Not Bound to a Creating Client
Envase Vault records no owning client for a secret, and performs no ownership check on read, update, or delete. This is a deliberate design decision, not an omission.
The reason is that the client that writes a secret is routinely not the client that reads it. Secrets are commonly provisioned by an administrative client and consumed by one or more runtime services. Deriving ownership from the creating client and enforcing it on retrieval would break the service’s normal usage pattern.
The same reasoning applies to the concept of an owning application. Standard secrets represent Envase itself rather than any individual application, so there is no application to bind them to. Two services that both need to authenticate as Envase to the same external provider are expected to read the same standard secret.
Note
Because of this, a reviewer should not expect to find per-caller authorization logic in the service, and its absence is not a defect. The authorization boundary for Envase Vault is the scope carried by the caller’s token, combined with the restricted issuance of client credentials described in Trust Boundary.
Organization Secrets and Customer Data
Organization secrets hold credentials belonging to individual Envase customers, keyed by organization id. Any client holding vault/organizations can read the secrets of any organization.
This is not a multi-tenant isolation concern, because no customer is ever issued a client. Organizations are a way of organizing customer credentials that Envase holds and manages on their behalf; they are not a security principal and they are not an access boundary. There is no path by which one customer could use Envase Vault to reach another customer’s secrets, because customers have no access to Envase Vault at all.
Organization secrets are nonetheless customer data, and the separate vault/organizations scope exists so that clients dealing only with company-level credentials are not granted access to them.
Environment Isolation
Envase Vault is deployed to three isolated environments: development, staging, and production. The isolation is enforced in several places at once:
Each environment has a separate Amazon Cognito user pool, so a token minted for one environment is rejected by the others.
Each environment has a distinct API endpoint and a distinct function prefix.
The environment is embedded in every secret’s key and ERN, for example
ern:vault:prd:my-provider-credentials.Every listing operation filters on the environment tag, so a request can only ever enumerate secrets belonging to its own environment.
A credential compromised in development therefore cannot reach staging or production secrets.
Handling of Secret Values
Envase Vault limits the exposure of secret values in its responses:
The listing routes return only metadata: the secret id, its description, its link, and its organization where applicable. They never return secret values, so listing cannot be used to harvest secrets in bulk.
Create, update, and delete responses omit the secret value. The value is deliberately discarded before the response is serialized, to avoid transmitting secrets that the caller already has.
Only an explicit get of a single secret returns the value.
Deletion is not immediate destruction. Envase Vault does not request a forced delete, so a deleted secret enters the AWS Secrets Manager recovery window and can be restored within that period.
Accepted Risks
The design above accepts the following risk, which is recorded here so that it is understood rather than rediscovered:
A compromised client credential exposes every secret within that credential’s scope, for that credential’s environment. A stolen token or client secret carrying vault/secrets can be used to read, overwrite, or delete all standard secrets in its environment, and likewise for vault/organizations and organization secrets.
This risk is accepted because the alternative, binding secrets to a creating or consuming client, is incompatible with how Envase Vault is used, as described in Secrets Are Not Bound to a Creating Client. The controls that address it are:
Restricting the issuance of Envase Vault client credentials to a small, known set of internal applications and services.
Issuing each client the minimum scope it requires.
Granting AWS IAM invoke permission on the function interface only where it is needed.
Rotating client credentials, and monitoring Envase Vault access through AWS CloudTrail.