8

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?

  • Why are you not able to use Hashicorp Vault on Windows? The official download page includes a binary for Windows: vaultproject.io/downloads.html – VaaChar Jul 5 '18 at 11:18
  • git-secret also supports Windows bash: github.com/sobolevn/git-secret/pull/123 – VaaChar Jul 5 '18 at 11:24
  • Oh cool that wasn't on the main git-secret website. I'll give it a go – Syntax Error Jul 5 '18 at 11:26
  • What specifically are you including in your configurations that is sensitive? If it's passwords, then you need to look at options to avoid needing passwords altogether. – Berin Loritsch Jul 5 '18 at 14:10
  • 1
    There's a story making the rounds about a guy who was billed $14k for AWS because he stored his keys in private version control, but posted it publicly on github for all of 10 minutes to share with a friend. – Karl Bielefeldt Jul 5 '18 at 17:15
5

Thinking about this holistically, there are several things to consider:

  • Is the GitLab server hosted in the same network as the target environment?
  • Do you have usernames and passwords in your config files?
  • Can you separate security config from the normal application configuration?

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:

  • Use connection strings that do not require username/password (see below)
  • Separate sensitive information out of the main Web.config
  • Use the file attribute in AppSettings to read an external config file

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.

2

The best place to store sensitive information is a purpose built store like Hashicorp Vault which does support Windows.

If (for whatever reasons) you are unable to use this you can also use git-secret which also supports Windows. Support for Windows was added to git-secret in this PR: https://github.com/sobolevn/git-secret/pull/123

git-crypt also has experimental support for Windows:

https://github.com/AGWA/git-crypt/wiki/Installation

https://stackoverflow.com/questions/43040370/how-to-install-git-crypt-in-windows

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.