RFC: When Using Azure Env Vars, Allow Edit? about dnn.keymaster

[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?

[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]

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

[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

[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