I know this topic has been covered quite a lot but I can't find an answer to my specific situation.
Currently, I'm using .gitignore
to exclude sensitive content and keeping it (config files, etc) seperately. As my codebase expands into more and more projects, this is becoming quite difficult to manage and I also have no real way to track changes or back up the files properly.
There are some tools for this problem, like git-secret
, Hashicorp Vault
and git-crypt
but none of these work with Windows, where I do all of my development (for various reasons).
Currently, I am the only developer working within my firm with no plans to expand. Source control (Gitlab) is mainly used for my own reference and ability to record changes. Would pushing a few connectionstrings or config files into source control be a huge problem or risk? That information is currently sitting in a network drive, unsecured (except for NTFS permissions)
I get the idea is that best practice is not to push this stuff to source control but I do have a privately hosted Gitlab instance which is not accesible outside of the local network – does this mean there is less risk?
Best Answer
Thinking about this holistically, there are several things to consider:
The first concern has to do with policy. If the software will be deployed to a separate network, you may run afoul of policy issues even if your configurations are encrypted.
Avoiding Sensitive information
Be specific about what is sensitive. For example, a server's domain name may not be sensitive, but it's IP address might be (or the association of the two). Typically usernames and passwords are sensitive, as well as clientId and secret keys (OAuth2).
Your best options are:
Some databases allow you to have a connection string where username and password are not part of the content. For example, you can run your app under a domain service account to connect to SQL Server using integrated security. Or you can use Oracle's Wallet to keep the username/password secret on the target machine. Some OAuth2 services allow you to use a .csv or .json file stored on the machine in a standard location.
In other words, do whatever you can to avoid keeping sensitive information where it doesn't belong. If you have to make alterations to your app to look in a location on disk to read the sensitive bits you can set that up once on each target server and just read it from your app.
Configuration Servers
Steeltoe has been porting certain Spring integration libraries to C#, and they even have support for Spring Cloud Config servers. The Spring Cloud Config server does require a Git repository on the deployment network, but does allow you to customize the config where it needs to be. If your application is complex enough (i.e. micro-services) then this would be something worth looking into to keep server names protected under the same environment the servers are located.
Bottom line
You just want to avoid the need for the sensitive information as much as possible, but maintain the non-sensitive configurations in source control. If you can't avoid the username/password in your config file (i.e. a different database that doesn't have an equivalent to integrated security) then load just that little bit from an external file.