Secret segmentation

There are many ways to segment secrets in DMNO. The most common is via plugin instances. This allows you to create a separate instance for each environment or service, giving you full control over which secrets are used where.

In general, you should apply the principle of least privilege when it comes to secrets. The facets of this are different for each organization, but as a rule of thumb, you should aim to:

• Minimize the number of people who have access to secrets, and regularly review and audit who does
• Minimize the environments (e.g., dev, staging, production) and their associated machine identities that have access to secrets
• Rotate secrets whenever possible
• Use short-lived credentials whenever possible

Sample setups

Assuming something resembling a trunk-based workflow (i.e., you have a single production environment and are using feature flags to manage changes across environments), the minimum viable setup that we recommend looks something like this:

• a plugin instance for dev secrets - those that are necessary for local development and any shared dev services
• a plugin instance for prod secrets - those that are necessary for production services

The next step would be split out those plugin instances per service in each environment. For example, say your application has a web service and a backend service. You would then create web-dev,web-prod, backend-dev, and backend-prod plugin instances.

We’re not advocating for these as optimal setups for all applications, but they’re a good starting point. The more you can apply the principle of least privilege, the better.