Sharing my read-only Azure App Configuration Connection String in a public repo

user_5591761 0
Viewed 113

I'm developing an application and I want it to be open-source.

In production, the application is using the Azure Key Vault Service only to store the database connection string. The connection string is stored on an Environment variable of the production server. In local, I'm using an InMemory Database from EntityFramework. No sensitive data is accessible.

In production too, the application is using the Azure App Configuration Service. While being able to update the configuration of an already running application, it also allows me to centralize the configuration data of my application. In local, I'm using the Azure App Configuration Service too. The READ-ONLY connection string is stored in my User Secrets.

And that's the point I'm struggling with. Is it considered a bad practice to share the READ-ONLY App Configuration Connection String on a Github or something else public ? Even if I don't store any sensitive data ? The Key Vault Service is especially designed to safety store the sensitive data, so in theory the App Configuration Service doesn't have any sensitive data available.

But I can't find any relevant documentation on that topic, and the fact that every tutorials I can find are storing the connection string in the user secrets is warning me. How can I share my configuration in a safety way to make my project open-source ?

.net-core azure
1 Answers

From security perspective you are violating principle of least privilege, giving read access to public that they don't need.

This could raise several risks:

  • You or someone else maintaining the App Configuration might "forget" about public read access and put vulnerable data there
  • An attacker might exploit a security bug in App Configuration itself and escalate read-only permission to read-write, which would not happen if they didn't have read-only access in the first place

You might think that probability of that happening is marginal (which is probably the case), but it is there and in security we always stay on the safe side - that's why we have the principle mentioned and it is indeed generally considered bad practice to violate it.

Finally, we always need to choose between usability and security, so in the end you might willfully agree to slightly less security if this makes your life easier and potential trouble from the risks does not scare you.

In case you would like not to expose the connection string you can think about:

  • abstracting configuration fetching in a similar way you did for secrets, so that production app would use App Configuration while for local development you can use InMemory database
  • replacing connection string with Terraform script so that you or any other developer can spin up and populate a dedicated App Configuration instance for local development purposes
user_28900930
Related