 On today's Visual Studio Toolbox, you'll see how to keep your secrets secret. You really need to watch this one. Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me today are Andrew Chung and Alicia Chan. Hi, guys. Hi. PM's in Visual Studio Land, and we're going to be talking about secrets management. Now, you might think, well, that's an odd topic. It's the world of open source. There are no secrets anymore. But in fact, your code can contain all kinds of secrets like connection strings and passwords and app IDs that you get if you're putting your app in Azure or et cetera. You probably have those in a config file, thinking, oh, well, it's easy to do. Then if you're not diligent about it, that stuff's now at risk. You put something in a GitHub repo, there's robots that parse through the repos, looking for stuff like this. Next thing, you're in the news because someone just spent $50,000 of your money doing Bitcoin mining or something like that. Absolutely. This is serious problem. So we're going to talk today about some things we can do to prevent that. Absolutely. We're going to go through some of the scenarios you just covered, where we are storing connection strings today in various configuration files, how we can look to mitigate that better if you're working locally and then as you work with Azure components, how you can interact with the Azure Key Vault and store your secrets there. Cool. So I've got a demo pretty much kicked off and ready to go. Okay. The main thing about this is just, it's an ASP.NET Core application. A lot of these features are actually already in Visual Studio 2017. Yeah. Look, there's a great squiggly that now shows up basically which is an awfully polite way of saying, maybe you shouldn't do that. Exactly. I might have gone for a different way of doing it, like a big red-flashing hammer hitting somebody on the head. But. Yeah. We'll work on the sound file for Alarms Blair and all that fun stuff. But yeah. So I've got here just a new web application. The only thing I've changed is that this page itself, where I've added in a couple of secrets to show that it is reading off of the app settings file. This is a common place where people store their connection strings today. Then I've got an index HTML file, which just we'll call out the values that we're looking at. So right now, if I go ahead and run this. I notice there was also a warning down in the errors letting you know as well. Yeah. We will be covering all of the squiggly lines and warnings very shortly. Okay. Cool. Yeah. So right now, what you see here is the two secrets that we just covered, which is right here in the app settings JSON file. Today, as I said, if you write your secret in here, app setting secret, app setting nested secrets, these are the values that are getting read. Okay. In Visual Studio 2017, if you're working locally, you may not want to connect to any Azure components, really any Cloud components first, you want to make sure your app works as is. One place we've inserted to try to mitigate secrets is this feature called managed user secrets. What this is is a local JSON file. When did that show up? So this shows up here moving too quickly. You right-click on the project. Right. But when was that added? This was added actually, I don't know exactly which version it was, but it was in 2017. Okay. Yeah. This is a local secrets JSON file. What this means is that if you do share your application, this file will not get carried forward. Okay. Yeah. So this is very important, obviously if you're working locally, you've got your own hashes, keys and everything you don't want that shared with the team. Okay. So this has a secret JSON secret, where if I run it once again, you've got a glimpse of that earlier, but you'll see in the third secret, this is the value that's being called out. Okay. So today, updating secrets is fairly simple. If I go into here and just change the secret. Did you show us manage user secrets? Yes. Okay. So what happens when you do that? That's what this does. It opens up a secrets JSON file. Oh, okay. Yeah. So this is another place where you can store secrets. Okay. This is a safer place if you're working locally. Okay. Yeah. If you ever want to update your secrets name, you can just go right in here and say updated. Pardon my typing. Secret. Is that a.NET Core only feature? Does it work with full framework? Great question. So right now, it's a.NET Core only feature. Okay. Actually, in 15.8, which will be released in a couple of weeks, we're going to introduce this feature over to the.NET projects as well. Okay. You enter it the same way. You would right-click on this. You would see the manage user secrets. This doesn't change at all. The only change is that instead of a JSON file, it'll be called secrets.xml. Okay. It's still a local file. It will not carry over. You publish your application. Okay. Cool. Then show me how you reference the contents of that. Sure. So right now, I've just got a basic reference here where I'm just tagging in. I've got the secret name and then I'm just calling the actual secret. Okay. Cool. Alicia will actually speak to how we look into the secrets at runtime. Okay. Cool. So did you want to cover a little bit about detecting secrets? Yeah. All right. So I'm going to take us back to our app settings.json file where people normally have secrets. So the secrets that we looked up before, we just made up some stuff with different values. Right. This one that we're looking at here is, say you've got an application and you're connecting it to something real like Azure Storage. So this is more so the format of what a real secret might look like. So what we're adding in here is that we've got this Google line saying, hey, you really shouldn't have these credentials in your code like this. We've got this warning for you as well. So if you're looking through your different files, you can be like, it's in this file, this line. Then you could go into the settings and change that to an error if you didn't want it to just be a warning. Right. We're still working on that feature. Oh, okay. Yeah. That's something to come for the feature. That'd be a good feature to have. Yeah. Okay. Okay. So I'm going to hover over this. So what we also added in here is kind of this quick action suggestion for this specific type of warning. So looks like we found a storage key in here. So I'm going to click on the slide bulb to see what options we have. I don't know why my other option isn't here. So part of the reason right now it only shows the moving to local secrets.json is that there should be another option to move to Key Vault as well. In this case, we haven't walked through how to set up the Key Vault yet and we'll do this actually right now. All right. Cool. So. So actually do that. Move the secret to the local secrets.json and show us what happens. Yeah. Sure. So this is similar to the manage user secrets thing that we showed you earlier. This is a different entry point to it. So if we were to move the secret to the local secrets.json, then what happens is we're removing the sensitive part of the secret out of your code. And we're kind of leaving behind a comment here to tell you, hey, like we moved it to secrets.json, and then you can access it through manage user secrets. We also have an info bar here. So if you want another entry point to get to your manage user secrets, you can also click here. Okay. Yeah. Cool. Okay. I guess we can show the Key Vault scenario as well. And then, so before we do that, so now what you've done is you've taken plain text and you've moved it from one place to another. So you then wouldn't check secrets.json into GitHub. So no one could get it that way. Then when you build the application that gets built in as part of the executable or the binaries and then you're covered, right? Is that basically, so at runtime, this is not just part of the applications code. For your local application, absolutely. Okay. Cool. Yeah. So that was for if you're doing a local application. So say you want to go beyond that. You want to be able to share this application with other people and still have it work. So we're going to add in a Key Vault so that we can store secrets in a different way that allows for this to be more versatile. So if you go to Connected Services, you can add in a Key Vault and it's really easy. So you go through this menu. This was a feature that was introduced in 15.7, so it was our last release. Okay. All right. So this obviously assumes you have an Azure subscription. Correct. I'm signed in with my Azure subscription right now. And then presumably what you're doing here, let's say someone doesn't have Azure, they're not doing Cloud Development, but they want to be able to store their keys in Azure. I'm going to assume that the cost of this is fairly low since you're just storing tech somewhere, right? Much lower than losing that Bitcoin. Exactly. Probably a lot less than that $50,000 we talked about. Yeah. Okay. Well, it's actually just a few cents, I believe it's three cents per transaction. Okay. Yeah. And you can also review that here if you want to check right before you make this. That's a pretty good deal compared to the cost of this deal, yeah. All right. Cool. So yeah, we take you to here. You just got to pick your subscription and we'll go ahead and make a new Key Vault for you by default or you could pick through existing ones that you might have. Okay. Yeah. If you hit the Edit button, that's where you can get into some of the advanced options where you start understanding both the resource group, what type of pricing tiers, and where you want your Key Vault to live. But for the most part, if you're just getting started for the first time, we've removed a lot of those hurdles. So Key Vault has different pricing tiers? Yes. That's interesting. Okay. All right. Okay. With those, then we can move on and add our Key Vault. Awesome. You may have noticed a bunch of text there. What we're doing through connected services when you hit that Add button, it's not magic. All that we're doing is looking for the NuGet package, we're installing it, and then we're adding the environment variables into Launch Settings to reference the actual Key Vault. Okay. Yeah. Cool. If you hit the output window down at the bottom there as well. That's just a normal Azure resource. You can go to the portal and take a look at it and see it. Exactly. So once you've added it, like you can see here, there's three settings on the right side where you can start it'll get you right into the Key Vault that you've just hooked up. Then presumably if you change these settings, you could do it through the portal. So these are actually links out to the portal. Right. Okay. Yeah. Yeah. Excellent. All right. Cool. So now we've got this Key Vault linked up. So I'm going to go back to our app settings, and I'm going to undo the move of our secret. So I can show you what it would be like if you were to move it to Key Vault. Okay. Cool. So let's go back to here and our quick actions just have to give it a second. Yeah. So you'll still see the squiggly line, you'll still see the error because we just undid our move over into the secrets.json file. So we're going to revisit our quick actions here, and you'll see that now that we have a Key Vault hooked up. Okay. That's the option. Yeah. So say I want to move my secret to Azure Key Vault now instead of secrets.json. That Key Vault is set up at the project level or at the Visual Studio level. That's correct. You can have one Key Vault per project. Okay. And you're thinking about whether you'd have a Key Vault for cross projects. Is it a Visual Studio setting? Yeah. So when user needs? Absolutely. So the connected services portion that we showed earlier, you can configure the same Key Vault across multiple projects if you want. Okay. Cool. So let's move our secret to Azure Key Vault. So since you've got a Key Vault configured, we just confirm that you want to move the secret into this Key Vault. So let's click okay, and then we'll wait. Cool. So we've got this notification that our secret has been moved to Azure Key Vault and we can access it through connected services, which is that page that we showed you earlier. Okay. So let's look back at our source code real quick. So once again, we've removed the sensitive portion out of your code into Key Vault, and left behind a comment of what happened to it, telling you that you can access it and find it in Azure Key Vault. Okay. And then where is, so somewhere is stored what Key Vault to work on, and then are the credentials cached? Do I have to sign in to Azure, the app to signs in to Azure on my behalf at right time? So when you set up your Key Vault for the project, it's using your credentials, and automatically grants your Key Vault that you've just created, user access. So every project that your user is tied to will have access to that Key Vault. It'll look slightly different when we talk about publishing the app into Azure, at which point the access will be granted at an application level. Okay. Yeah. All right. So I'm going to visit our connected services page, so that we can go to the portal because I want to show you guys that the secret was actually moved into the portal. So if you go to this option, manage secrets stored in this Key Vault, it'll bring us to the Key Vault to the page where your secrets are all listed out. All right. Cool. So if you'll look here, you've got a list of secrets. Yeah. And so you can go through and click and confirm that the value is indeed what it was supposed to be. And then I also want to go back and rerun the app again, since now your secret is not in the code anymore, but the app should still run. Okay. And then again, if you're running offline, if you don't have access to the Cloud, then the secret can't be retrieved. Absolutely. Okay. In which case you'll get an error. Right. While you're running this, it might be good just to, we've covered about moving secrets into various places. So, Alicia, can you tell us a little bit about how, at runtime, we read our secrets and which one's the most important one? Yeah, definitely. So for these secrets, since we've got the Key Vault hooked up through connected services, what Visual Studio does is it will look for the secrets in different places based on a precedence that it's got set. So Key Vault is the most secure one, so it'll look there first to see if it can find your secret there. And if not, it'll look through environment variables that you have. And then if not that, then it'll look through secrets.json. And then finally, apps.json. Okay. So you would do Key Vault because it's most secure. Yep. You can also have the secrets.json, which is less secure. Yep. Which then does that defeat the purpose? No, actually, if you have the same secret. Yeah. If you have the same key with different values in various places, the Key Vault one is the one that will be used because it's the most secure. Okay. And then you would just hope that if you change the secret in one place, you got to change it in all. Right. Which is why when we move the secret over, we actually remove the actual secret and leave a comment to let you know, hey, your secret's gone to this new magical place. Okay. Cool. All right. Let's revisit our web app. And you'll see that it is still running, even though it's now reading the secret out of Key Vault and not out of app setting.json anymore. Cool. Yeah. And so these features, we're looking to ship them kind of in the next month or so. So it'd be great to be on the lookout for those and they'll be inside the CD for VS extension. All of the new stuff with the quick action and detection. Oh, okay. So that stuff's coming in 15.8. Is that right? Okay. That's the squiggly line, the warnings that show up as warnings right now. Okay. Cool. And the action of actually moving the secret over into secrets.json or the Key Vault. Okay. And then the ability to do something similar for WinForms, WPF, UWP, non.NET Core apps, I guess, MVC, ASP, anything not.NET Core. Yeah. Probably could have set it that way to begin with instead of going through the whole list. That's coming. Oh, that's a great question. So right now you can actually hook up the Key Vault to .NET projects as well. Okay. Yeah. It's not only limited to .NET Core. Got it. And then we'll look to roll the extension out as the Key Vault supports gets rolled out to the various project types. Okay. Yeah. Okay. So it is coming soon. We don't have an exact data right now. All right. Cool. Cool. Awesome. Cool. One last thing that we wanted to show you is so far we've been working locally. Right. And it's great, right? Like, you know, in your basement, your coding, you can see that your secrets are now working. Yes. Well, when it comes time for your application to be published out to Azure, we've got a feature coming out in 15.8, which will be in a few weeks, where if I go through the publish flow, this will look the same for any application you work through. So you're just publishing your application into Azure. It's moving the bits over at this point. And this is for both .NET Core and .NET Framework apps that are being hosted in Azure? That's right. Okay. Cool. So once you've published your application, what you'll see is there's a little warning here that tells you, hey, your application relies on secrets. Your local app has been configured to handle secrets. However, your published app right now, you can tell, has no Key Vault associated with it. So it's just letting you know that if you do proceed of this application. Why is that? Why wouldn't it default to using the same Key Vault? Great question, because so this is an app that we're publishing out to the cloud. And we would like to give the users a choice of which Key Vault to use. By default, if they go through Visual Studio, they'll be able to associate the same Key Vault that we've been using already. However, like if you work in a large corporation where you have a separate ops team that manages all of these connections, especially as you go out to various test environments and production environments, you may not want to hook up your test Key Vault with your production Key Vault. Okay. So at this point, assuming that I want to hook up the same Key Vault, all I have to do is click Add Key Vault and it'll already say, hey, your existing Key Vault with your local project can be connected to your published application. And if I hit Yes, what this does is it adds the environment variables, the same one we added earlier into our local application out to the published application. And so you'll see this Key Vault has been set up. And then how would I choose a different one? You would have to go out to the Azure portal and you'd be able to change your environment variables to reference different Key Vaults. So I just actually published that, hit that locally what I wanted to show was the published application. So let me just stop this since we know the local application works and we'll play with the published application. Okay, so before you configured it now you're actually doing the publishing. Okay. Correct, all right. And so when we see the published applications there'll be one slight difference. I'm gonna be curious as to whether or not you can pick that out. All right. There's a missing value. All right. Secret JSON My Secret, which is the one that was stored in the separate file. Right, when we were working locally. Because oddly enough Azure doesn't have the ability to tunnel back into your computer and read things off the hard drive yet. Right, so that's where you can kind of see the value of both sides of the effects. Okay, cool, awesome. Great. So again to review the stuff you showed is coming in 15.8, all of it coming in 15.8? Yeah, let's actually kind of quickly go through the process. What we talked about today was working with secrets. In today's world you can store your secrets in app settings which is a very common place where developers store their secrets. What's already been released is the ability to right click on your solution and this is for both .NET Core as well as .NET applications. Okay. And manage user secrets which will lead you to this local secrets.json file. Or secrets.xml. Exactly. So that's in there today. That's in there today. Right, one part that we visited was Alicia talked about moving your secret over into the Key Vault or the local secrets.json file. That's going to be available within the next month through the CD4VS extension. Okay. Okay. Adding a Key Vault through connected services exists today. Okay. Right, so that whole process we clicked through onto connected services, being able to play with a Key Vault that exists today. The part that will be coming up in a few weeks in 15.8 is as you're publishing, getting that warning that shows, hey, your Key Vault has not been added. Do you want to proceed with it and having the same Key Vault tied to your published application? That will be in a few weeks. Cool. Yeah. So very, very easy tools, very cool stuff. Makes it dramatically less likely that you accidentally give your secrets away and seems pretty straightforward to manage. That's cool stuff. Yeah, thank you. Yeah. If you're going to look at that, if you're not doing it, you really need to highly recommend it. And hope you enjoyed that. We will see you next time on Visual Studio Toolbox.