2

SQL azure connection strings always include a password (as Azure SQL Server doesn't support OS authentication) which makes it unsafe to keep them in web.config files. A typical recommendation you can find on the net is to move them to cloud configuration settings which means declaring a setting in ServiceDefinition/WebRole/ConfigurationSettings section of ServiceDefinition.csdef file so that you can edit them in the portal:

enter image description here

The problem with this approach is whenever you re-deploy your site the settings you set in the portal get overriden with what values are in ServiceConfiguration.*.cscfg. Of course, you can put your connection strings to the file but that's pointless as you still keep the secrets in a source control.

Azure Key Vault could be a good solution here but I'd like to explore other options before going this route. What would you recommend?

UserControl
  • 14,766
  • 20
  • 100
  • 187
  • 1
    Even with Key Vault wouldn't you need a service principal in Azure AD, and then have the client id and secret in your configuration? ;) – juunas Nov 20 '16 at 16:56
  • True. But in this case that would be the only secret needed and we can put into a deployment rule in CI to avoid storing it in source control. Fair compromise I guess. – UserControl Nov 20 '16 at 17:13
  • In web app you use App Service -> Application settings -> Connection strings. If your question specific to web role please specify it in tags / in question. – Lanorkin Nov 21 '16 at 07:37
  • Have a look at this https://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure – Bruce Chen Nov 22 '16 at 04:59

2 Answers2

2

Create managed identities for your service and use key vault to add the access policy to key vault. No need to store client secret and all the configuration is stored in secured way.

Andrew
  • 307
  • 7
  • 13
Anand Sambamoorthy
  • 36
  • 2
1

As Lanorkin said, If we define the connection string in Azure web app. It will not be overrode when re-deploy. However, the behavior is totally different in Azure cloud service. It will be override when redeploy. I think you could submit a new feature at Azure feedback forum for this issue. At currently, if you do not want to store the connection string in source control, Key Vault may be a choice.

Jambor - MSFT
  • 3,175
  • 1
  • 13
  • 16