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.
