.NET Core - How To Manage User Secrets Within A Team

Question

The storage of secrets for .NET Core is well documented.

However, in the .NET Core world, I cannot find a good article on how such information is shared amongst a team.

Say, for example, we have a .NET Core Project that has information stored within secrets.jsonand there are 10 developers using that project.

Options I can think of:

1. Check something into source control - seems to defeat the point (apart from not accidentially publishing test settings to live).

2. Just talk between ourselves - has the feeling that if someone adds a secret and goes on holiday, other devs will waste time figuring out what's missing. It might also cause issue if two developers add something around the same time.

3. Ignore secrets.json and always use Azure KeyVault - even for dev. More complicated and I haven't seen this recommended anywhere, but it would also work for building on build servers. The downside is that the Vault could get cluttered with unused settings and it not be clear which need replicating in live.

There may be other options I've missed.

What is the best way to share/ synchronise secrets with other developers?

EDIT FOLLOWING ANSWER:

Going the KeyVault route will work. As stated, this requires additional setup (using certificates, for example). Further details in the Microsoft Docs.

Answer 1

Although this is biassed: go for 3, use the key vault.

---

Diclaimer

There are many blog-post and documentation on this subject, here I'll address a very narrow portion of the scope of the question.

An alternative recommendation would be or use methodology like GitOps/SOPS as described here

---

As for the Vault option, it has some benefits of which I will name some:

• secrets are stored in a central place, making governance and rotation easier
• secrets are not known to developers, or only at a need to know basis, which makes it more secure
• secrets, if implemented correctly, are no part of the version control, which also makes it more secure.

some con's

• it takes some time to set up properly
• it's less flexible, especially it the process isn't in place yet.
• secrets, if implemented correctly, are no part of the version control, which makes recovery harder.

To elaborate on that last one: there are scenario's where you need a "stable" and recoverable secret, e.g.: when a client needs to integrate in a specific manner, which require you to have control over a secret. Although security-wise this is not best practice, it is quite common. A GitOps/SOPS is more suited in that scenario.

---

In general, the more developers have access to the secrets, the more insecure it is.

Ideally, if you set it up correctly, you'll end up with the same way of dealing with this across all your environments (test, staging prod). In the end, the solution and process should be independent of the environment, to maximize production stability.

---

But as I said; this is biassed and opinion based.