Structure guide - organizing your secrets

There are many ways you could organize your secrets inside your organization. This guide will walk you through our recommended approach to do so.

The best way to think about organizing secrets is to think of the isolation and access boundaries you want to setup for your secrets.

Example scenario

You have an application named DreamCommerce with two services: PaymentsAPI and WebSearch. Each service has a dedicated team to develop; however, both services use the same underlying APIs with shared secrets. The DreamCommerce application and its services have four environments: development, CI, staging, and production.

Projects and applications

An HCP organization can have one or more HCP projects to segment HCP resource access within an organization, such as by team, use cases, or environment (development, staging, production, etc.). You can set user permissions at the project level.

To ensure the production environment has a separate isolation and access boundary, create separate HCP projects with clear naming convention such as:

• DreamCommerce-NonProd - a project to manage non-production HCP resources
• DreamCommerce-Prod - a project to manage production HCP resources

DreamCommerce-NonProd

Under the DreamCommerce-NonProd project, create HCP Vault Secrets applications with following naming convention: <SERVICE_NAME>-<ENVIRONMENT>.

DreamCommerce-Prod

For production, create an HCP Vault Secrets application per service. In addition, create a dedicated application for the CI automation tool to isolate two different types of clients.

Summary

Organizing your HCP Vault Secrets applications in this convention allows you to set granular control over which clients (users or systems) have access to the production environment while the non-production environments continue to support the engineering effort.