We are currently not yet on the PRO plan, but looking at the docs, I’m not sure what I’m about to ask is actually possible.
We want application developers to have some autonomy in managing most secrets for their project, but there are certain secrets values they should not be able to see. For example, developers are not allowed to view the Prod Database password, but should be able to reference them.
Can this be achieved? Based on the docs it seems that collaborators are also allowed to generate service tokens. The service token can be used to fetch the underlying secret.
Maybe I’m going about this wrong. What are the best practices here?
Could you elaborate a little about the kinds of scenarios you’re wanting to handle here where you’d want a user to be able to add a reference to a production secret in a non-production config or project? Our Pull Requests feature is intended to allow users to propose changes to secrets in configs they don’t have access to, but there’s no real way to allow a user to add a reference to a secret in a project or config they have full access to without also letting them view the value after adding the reference.
If you have a day-to-day use case that requires this, it would be very helpful if you could explain a bit more about the workflow and why it’s needed.
Developers - for the projects they manage - should be free to add new ENV variables to the production configs, but things like database passwords are not managed by them and should not be accessible to them.
We are in a similar space to you @boedy . We have been working off a Teams account for almost a year, and are planning on moving to Enterprise in the not-too-distant future.
The way we will be doing this is as follows:
We create developer, test, and production environments for each team
The teams can manage and see developer configuration secrets, but they can’t access or edit test and production configuration secrets.
Our delivery team will script the creation of secrets for teams for their test and production environments using a service token specific for the delivery team. This way our CI/CD pipeline can access the secrets for the test and production environments, but the team members can’t.
Any common secrets are put in the Common project and are accessed within other projects via ${common.configuration.secret_name} templating.
The templating concept works great. We have numerous centralized resources that are referenced in all our projects, and it makes it easy to rotate them since they are only stored in the Common project.
One pattern for this would be to have one project for configuration and another for credentials. For example, if you had a service named “widgets”, you might have a project named widgets-configuration and another named widgets-credentials. You could then provide all your engineers with full access to the configuration project and then limit them to dev on the credentials project (or even block access entirely). You could then use cross-project secret referencing to pull in whichever secrets you need to your deployment config (wherever you end up having that). Using this setup would give you a little more access control over the different types of secrets for your projects.
