Developer level connection strings/credentials should be generated

[fgheysels]

Some files in this repository contain secrets. I don't think you want to expose sa db - passwords to the whole world.

For instance here and here. (You should also not add an appsettings.development.json file in source-control).

Make use of docker secrets to inject secrets in a container; do not expose connectionstrings via the git repository!

[showengineer]

More secrets can be found here and here

[ijansch]

Thanks for keeping an eye on this! The docker setup is intended to be a standalone server for development purposes, so making sure the components can talk to each other is intentional. In production setups such secrets will be provided through configuration management.

I’ll ask the team to verify, just in case, and add comments where applicable.

[ryanbnl]

The passwords in docker, the appsettings.Development.json and in the angular environments are all development settings. The production settings are stored in another system which the developers don't have access to :)

[ryanbnl]

I can't speak for the other developers but my local settings are totally different from the settings we've provided for the docker deployment.

[fgheysels]

To be blunt, I think it is a very bad practice to put things like connectionstrings (even if they're development settings) in a git repo.

I believe this has just been done for ease of use, so that every developer is directly up to speed without having to setup some kind of configuration, but there are better ways to tackle this imo. Secrets can be stored by the ASP.NET SecretManager or in a centralized secure secret store. I think no shortcuts should be taken on security in favor of ease-of-use; especially for a government backed application who's source code is publicly available. But these are just my 2 cents :)

[Naamloos]

again? 😳

[showengineer]

To be blunt, I think it is a very bad practice to put things like connectionstrings (even if they're development settings) in a git repo.

I believe this has just been done for ease of use, so that every developer is directly up to speed without having to setup some kind of configuration, but there are better ways to tackle this imo. Secrets can be stored by the ASP.NET SecretManager or in a centralized secure secret store. I think no shortcuts should be taken on security in favor of ease-of-use; especially for a government backed application who's source code is publicly available. But these are just my 2 cents :)

To add to this. This is not the first time secrets are 'leaked' in this repo(#7) and there are more extreme cases where data was leaked in a git repo (ironically for a corona tracking app for the Dutch government). Even though the keys and secrets are not used in production, you don't want people to think you're handling keys/secrets like amateurs

[ijansch]

Comparing this to an actual data leak is apples and oranges, but point taken. The same fix as for #7 could probably be applied here. I’ll leave this open for now. Given that it’s a process improvement / best practice and not an actual leak, I’ll adjust the title to ‘developer level connection strings should be generated’. Agreed?

[hiddehs]

To be blunt, I think it is a very bad practice to put things like connectionstrings (even if they're development settings) in a git repo.

I believe this has just been done for ease of use, so that every developer is directly up to speed without having to setup some kind of configuration, but there are better ways to tackle this imo. Secrets can be stored by the ASP.NET SecretManager or in a centralized secure secret store. I think no shortcuts should be taken on security in favor of ease-of-use; especially for a government backed application who's source code is publicly available. But these are just my 2 cents :)

Agreed and we've clarified the README.md for local quickstart development docker usage only in the upcoming sync. But I love to see your contributions on this point, do not hesitate to make a PR to improve the local docker development secrets. Keep in mind that we still want to enable app developers and testers to quickly start the latest version of the Standalone Server via docker without having to fuzzle with all different configs.

[ryanbnl]

This was resolved a couple of months ago, so I'm closing the ticket.