How do I use Visual Studio user secrets and GitHub secrets, in the same project?
-
I've known about Visual Studio user secrets for a while but haven't used them. And I know that GitHub has secrets, which can be used in repos and I'm sure GH Actions, but again I haven't used them. That's all going to change very soon. I'd like to use VS user secrets for connection strings, API keys, etc. But when I commit to a GH repo, I'd like the GH action to use the GH secrets saved in that repo on GH. The only thing is, how do I do that? The syntax, I'm sure, isn't the same. How do I do what I want to do?
Rod
-
I've known about Visual Studio user secrets for a while but haven't used them. And I know that GitHub has secrets, which can be used in repos and I'm sure GH Actions, but again I haven't used them. That's all going to change very soon. I'd like to use VS user secrets for connection strings, API keys, etc. But when I commit to a GH repo, I'd like the GH action to use the GH secrets saved in that repo on GH. The only thing is, how do I do that? The syntax, I'm sure, isn't the same. How do I do what I want to do?
Rod
-
Microsoft has a paper on it, which also refers to github, at Safe storage of app secrets in development in ASP.NET Core | Microsoft Learn[^]
Thank you, Richard. I'm reading the document you linked to now. I'm about a third of the way through it. It speaks of ASP.NET Core, which in my case is fine, as this is a new app. However, we have hundreds of custom apps all written using old versions of the .NET Framework. Does that mean that Visual Studio user secrets will not work?
Rod
-
Thank you, Richard. I'm reading the document you linked to now. I'm about a third of the way through it. It speaks of ASP.NET Core, which in my case is fine, as this is a new app. However, we have hundreds of custom apps all written using old versions of the .NET Framework. Does that mean that Visual Studio user secrets will not work?
Rod
-
I've finished reading the document and I did see that "*Migrating User Secrets from ASP.NET Framework to ASP.NET Core*". Unfortunately, that won't work for me. I wish we were allowed to update code, but the motto where I work is, "If the code isn't broken beyond repair, do NOT modify it!! And NEVER, EVER update or upgrade it!!!" I have no choice but to work on old code using whatever .NET Framework it was originally written in. And some of those dates back to .NET Framework 1.1.
Rod
-
Microsoft has a paper on it, which also refers to github, at Safe storage of app secrets in development in ASP.NET Core | Microsoft Learn[^]
Another issue I'm unclear on, in reference to that "Safe storage" document, is the use of environmental variables for safely storing secrets. The document brings up environmental variables, saying that is a safe way to use secrets securely, then drops talking about environmental variables. Please excuse my abysmal ignorance on how to use environmental variables on a development machine, on the deployed server and an Azure App Service. How does that work?
Rod
-
Another issue I'm unclear on, in reference to that "Safe storage" document, is the use of environmental variables for safely storing secrets. The document brings up environmental variables, saying that is a safe way to use secrets securely, then drops talking about environmental variables. Please excuse my abysmal ignorance on how to use environmental variables on a development machine, on the deployed server and an Azure App Service. How does that work?
Rod
-
I've known about Visual Studio user secrets for a while but haven't used them. And I know that GitHub has secrets, which can be used in repos and I'm sure GH Actions, but again I haven't used them. That's all going to change very soon. I'd like to use VS user secrets for connection strings, API keys, etc. But when I commit to a GH repo, I'd like the GH action to use the GH secrets saved in that repo on GH. The only thing is, how do I do that? The syntax, I'm sure, isn't the same. How do I do what I want to do?
Rod
Rod at work wrote:
The only thing is, how do I do that
By providing a key that only shows up on a developer machine. Such as a specific single env variable. It only exists on dev machines. The code uses different code based on whether that exists or not. The env variable does not provide security information itself. It just exists. That allows for no security problems because if it starts existing on a prod box nothing will work. This solves your github problem.
Rod at work wrote:
However, we have hundreds of custom apps...And NEVER, EVER update or upgrade it!!!
(From other posts) Which is exactly correct. If you bring an app forward then that tech debt activity should make NO functional changes except those necessary to bring it forward. These days one can often make that case to do that for existing code both for obsolesce and security reasons. But besides that presumably those apps are already managing secret information via some mechanism and you should not attempt to use another idiom unless there is a real need. It does not add value to have multiple idioms that one must know to provide maintenance and just to do development.
-
Rod at work wrote:
The only thing is, how do I do that
By providing a key that only shows up on a developer machine. Such as a specific single env variable. It only exists on dev machines. The code uses different code based on whether that exists or not. The env variable does not provide security information itself. It just exists. That allows for no security problems because if it starts existing on a prod box nothing will work. This solves your github problem.
Rod at work wrote:
However, we have hundreds of custom apps...And NEVER, EVER update or upgrade it!!!
(From other posts) Which is exactly correct. If you bring an app forward then that tech debt activity should make NO functional changes except those necessary to bring it forward. These days one can often make that case to do that for existing code both for obsolesce and security reasons. But besides that presumably those apps are already managing secret information via some mechanism and you should not attempt to use another idiom unless there is a real need. It does not add value to have multiple idioms that one must know to provide maintenance and just to do development.
I'm going to consider what you've said here concerning environmental variables. You've given me some things to think about. I did want to respond to your suggestion of not changing the idiom for how we handle secrets to another idiom. In this case I believe we will have to when migrating to repos in GitHub. As I understand GH Advanced Security, it will run a check on attempted commits to see if secrets are in the proposed commit. If secrets are there, then the commit/push will be rejected. Secrets are in all our source code. (If I've misunderstood how GH Advanced Security works, with respect to secrets, then please forgive and correct me.)
Rod
-
I'm going to consider what you've said here concerning environmental variables. You've given me some things to think about. I did want to respond to your suggestion of not changing the idiom for how we handle secrets to another idiom. In this case I believe we will have to when migrating to repos in GitHub. As I understand GH Advanced Security, it will run a check on attempted commits to see if secrets are in the proposed commit. If secrets are there, then the commit/push will be rejected. Secrets are in all our source code. (If I've misunderstood how GH Advanced Security works, with respect to secrets, then please forgive and correct me.)
Rod
Rod at work wrote:
Secrets are in all our source code.
Well that is a problem! Perhaps you should find a solution for the older apps first. Updating only that part. Only then, and to be a consistent, new apps would use it in the same way. Not to give away a secret though - I doubt github can find all secrets. So you can probably find a way to obfuscate in the code. But that should be a stopgap.