RFC: When Using Azure Env Vars, Allow Edit?

[SkyeHoefling]

Given the website is hosted by Azure you can specify app secrets in the App Settings feature. This will remove any hard coded secrets on disk.

For background if you are not using Azure Env Vars the secrets are stored in a file that contain the following important Vars

• Client ID
• Client Secret
• Secret Name
• Tenant I'd
• Key Vault URL

Question

If the website is configured as stated above should we allow the host user ability to override from the DNN Website?

My Argument

If the user chooses to manage their secrets from the Azure Env Vars I think they should be locked out from managing their secrets. It should only be managed from the Azure interface. This will increase the website security significantly as there will be no way to get the secrets without azure portal access.

[SkyeHoefling]

This will dictate some direction on the current intention of #10

[mitchelsellers]

This is a great idea, and from a security perspective would for sure be a much more secure implementation.

The only real "issue" if you will is that there are times where we DO need to see/configure secrets as a Host user that might not have access to Azure, at least initially. Think of a situation whereby a consultant is brought in to review the application for issues, they might need to see the credentials.

Additionally, the inclusion of AppSettings in the DNN environment is a bit "adhoc" as third-party extensions will often add items during module installation, upgrade, or otherwise. So it will be important to make sure that we don't restrict/limit/block that behavior, as the user might not actually know the purpose of the settings.

One possible option might be to support the configuration of an environment variable such as Restrict_App_Settings or otherwise, that would allow the Azure configuration to "tell" DNN that they shouldn't be able to edit secrets that are already defined in Azure?

[SkyeHoefling]

Thanks for your input on this and you raise some good points. I would like to clarify what I am proposing:

3 Concepts

• Key Master AppSettings
  • Maps to the web.config App Settings, these settings will always be available for edit and view as host user
• Key Master Secrets
  • This is a new concept with the key master as it is a place to store connection information to the Key Vault
• Azure AppSettings
  • This is specific to Azure Web Apps as a secure place to store information

My Proposal

To clarify my point, the Azure App Settings would be a place to store the Key Master Secrets. Not the Key Master App Settings

[david-poindexter]

While in principle this seems like a great approach and definitely more secure, I would be a bit concerned that this provides yet another way for providers to "hold sites hostage". We have had several scenarios where a provider would not provide the necessary credentials to diagnose a site, migrate it to another provider, etc. This can put clients in a very uncomfortable position. Adding this type of capability would simply provide another layer of this potentially happening.

That said, for above the board, ethical, honest hosting providers, this would be fantastic for great site security. I suppose this then becomes an education challenge. Clients need to know that providers could leverage this feature for both good and bad purposes.

I hope this helps. Great work on thinking this through and soliciting feedback!

[SkyeHoefling]

@nvisionative you bring up a very good ethical point. While the purpose of this technology is for security it can be used in a negative manner.

Maybe the compromise will be creating a setting to lock down the UI as @mitchelsellers recommended.

[david-poindexter]

I like that idea.

[mitchelsellers]

My comments stay the same, but I was blending AppSettings & KeyMaster Settings.

I agree with David, but it should be LESS of an issue on Azure, as the customer OWNS the Azure account, so providers cannot really hold them hostage....at least not for long

[SkyeHoefling]

@mitchelsellers thanks for the clarification