Keys / Secrets need to be stored in KeyVault

[cleemullins]

Describe the bug

Keys, related to my publishing profile, are stored in appsettings.json. These keys are unencrypted. This is unexpected, as I expected them to be stored in Key Vault.

[Note: I had a bunch of screen shots around this, but they're not useful so I deleted them]

There is a .gitignore file, that prevents this file from being checked in:

Version

Version: 1.4.0-nightly.237101.f01cb52 Electron: 8.2.4 Chrome: 80.0.3987.165 NodeJS: 12.13.0 V8: 8.0.426.27-electron.0

Expected behavior

The Azure Key Management Doc is clear: https://docs.microsoft.com/en-us/azure/architecture/framework/security/design-storage-keys

Store all application keys and secrets in managed key vault service such as Azure Key Vault. Data encryption keys are often encrypted with a key encryption key in Azure Key Vault to further limit access.

Make sure that no keys and secrets for any environment types (Dev/Test, or production) are stored in application configuration files or CI/CD pipelines. Developers can use Visual Studio Connected Services or local-only files to access credentials.

[cwhitten]

This was pulled out of BUILD scope for the adaptive runtime. Transferring to components project

[tracyboehrer]

@cwhitten Why would this be in Components? This is driven by Composer. Unless there is also some discussion about moving provisioning and publishing out of Composer.

[cwhitten]

@darrenj & @garypretty can comment, but it was offered to decorate sensitive fields in appsettings with the keyvault alias, and we told not to because of changes needed in the runtime to properly consume the fields. The old runtime template had this working, by the way.

[tracyboehrer]

@darrenj & @garypretty What am I missing? Runtime doesn't even read (or write) those profile values in appsettings. Honestly, appsettings isn't the right place for the publishing profile to begin with. It has nothing to do with the running bot or runtime.

[cwhitten]

Let me clarify - the MSAppId and AppPassword are fields in appsettings that the runtime reads from. You're right in that the publishing profile is not needed by the runtime.

The same goes for db connection strings, luis prediction key, and a few others I believe.

[tracyboehrer]

Now I'm with you.

Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Chris Whitten @.> Sent: Wednesday, April 21, 2021 5:31:08 PM To: microsoft/botframework-components @.> Cc: Tracy Boehrer @.>; Comment @.> Subject: Re: [microsoft/botframework-components] Keys / Secrets need to be stored in KeyVault (#958)

Let me clarify - the MSAppId and AppPassword are fields in appsettings that the runtime reads from. You're right in that the publishing profile is not needed by the runtime.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fbotframework-components%2Fissues%2F958%23issuecomment-824404675&data=04%7C01%7Ctracy.boehrer%40microsoft.com%7C694a30f999574789deb108d905152929%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637546410712903227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C4NoP1TwYx4U9Odt6PZaJR8KjuMujTHDxB6v3Qa6EAg%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAH2HBQO2V7YCEGUZJ7IIF3TJ5G2ZANCNFSM43LGU3DA&data=04%7C01%7Ctracy.boehrer%40microsoft.com%7C694a30f999574789deb108d905152929%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637546410712913182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Q%2B50sY5jHx4lLk2UNcfEFl47EWIaYCxolRnqUQU8j5w%3D&reserved=0.

[peterinnesmsft]

@cwhitten @tracyboehrer I think there is some confusion around Key Vault support in the runtime, and it sounds like that got miscommunicated to you Chris.

Chris, you are absolutely right - you should be able to store secrets in application settings using the Key Vault references as described here: https://docs.microsoft.com/en-us/azure/app-service/app-service-key-vault-references. This is a capability that is offered up by App Service, and is not tied to the runtime implementation.

To my understanding, I believe that all that is required here is to ensure that there is an AKV resource that is granted access to your compute hosting your bot through a valid MSI. If that's in place, then App Service I believe under-the-hood does variable substitution, so as long as it can suitably detect the application settings and the resources are granted access, it should be able to fill them in.

---

However, the catch with this is that it is entirely dependent on being deployed to App Service (and by extension, Functions). If you chose to use a different compute offering, such as Service Fabric, AKS, etc., then you would not be able to use this particular syntax. This is where the the Azure Key Vault configuration provider comes in, as documented here: https://docs.microsoft.com/en-us/aspnet/core/security/key-vault-configuration?view=aspnetcore-3.1 This would be a runtime change, and is most likely what was being referred to.

I don't know that there has been any particular validation of App Service support for AKV configuration references, so I think this is something we should try and verify separately to adding AKV as an explicit configuration source.

[cwhitten]

Makes sense @peterinnesmsft. Our thinking has been to revisit this post BUILD, and make sure KV is plumbed through the stack in a sane way for customers.

I also realize that I transferred the wrong key vault github issue here, and may have avoided the confusion altogether had I moved the correct one.