How to deploy ASP.NET Core UserSecrets to production

Question

I followed the Safe storage of app secrets during development guide over on the asp.net docs during development but it does not describe how to use it when publishing to another machine for QA, Production, etc. What I figured it would do was insert them into the appsettings.json during publish but it does not. I ended up having to place my SendGrid keys and other sensitive information directly into the appsettings.json which really defeats the purpose of the app secrets.

Is using app secrets the best way or is there another way to store API keys and SQL user/passwords in my configs?

I guess you should create it again in every machine you want to run you project for the first time. — Fabricio Koch, Sep 23 '16 at 19:52
User secrets are only applied when a certain environmental variable is set to Development — Mitchell Skurnik, Sep 23 '16 at 20:05
From your link, _The Secret Manager tool does not encrypt the stored secrets and should not be treated as a trusted store. It is for development purposes only_. This is just to keep secrets from being committed within the code to your repo. In production set the secret values to the appsettings or env variables or any other config source. — Daniel J.G., Sep 23 '16 at 20:45
I have the same question. I just don't see the value of User Secrets if in the end you have to end up exposing the values where you store them for production. If it's only useful in development what the hec do you do once you get to production? — Sam, Sep 25 '20 at 13:57
@Sam for production you would usually do value replacement in your build or release pipeline. In azure devops they have places to store production values that get repleased in the release step of your pipeline. — Dblock247, Feb 19 '21 at 00:32
@Dblock247 I read this statement many times, but still not sure of how exactly to do this. Mind showing me the link to the docs that shows how to do this? — Farid, May 11 '21 at 09:13
@Farid you should only be using user secrets on your local machine. If you need different secret variables for different environments you should have them injected in during the build/release process. Azure pipelines works well for that. Do not save them in source control. I included a code snippet of how to use the user secrets. See my post below. — Dblock247, May 11 '21 at 11:34
@Farid are you using continuous integration? For example azure devops pipelines? My statement is referring to being able to replace variables in you appsettings file during your release phase. That does not involve you changing code. Look into continuous integration with azure pipelines. — Dblock247, May 11 '21 at 11:44

score 35 · Accepted Answer · answered Sep 23 '16 at 20:43

35

Don't use app secrets in production. Ever. As the article says DURING DEVELOPMENT.

How you publish secrets in production is up to your production environment. Linux, Windows and Azure all support environment variables - that's where your secrets should go, using whatever UI your hosting provider gives you.

The app settings documentation goes into this in greater detail

answered Sep 23 '16 at 20:43

blowdart

55,577
12
114
149

1

While not as easy as deploying a configuration file I do understand why you would use environmental variables instead. – Mitchell Skurnik Oct 03 '16 at 23:08
8

Environmental variables are a very poor source for storing secrets. A local admin has access to them and this is dangerous for many environments. If a Key Vault can be used, the secrets should at least be somehow encrypted. – kgiannakakis Jan 16 '21 at 11:53
7

Environment variable are not more secure that storing values in appsettings.json. a hacker who has access to your file system can access both easily. what is the point of storing values in Environmental variables then? – EKanadily May 13 '21 at 21:15
1

So what is it useful for in development?! I mean consider that the development machine is mine so what `app secrets` could do for me? – Ahmed Suror Oct 04 '21 at 00:53
3

@AhmedSuror I guess the only advantage I see is that it will help you protect them from accidental committing them into repository. – Lukasz Pomianowski Dec 21 '21 at 11:09
Shared windows hosting doesn't give you access to environment variables. – EKanadily May 07 '22 at 02:31

user1855805 · Answer 2 · 2018-09-21T09:35:20.170

Why "don't use app secrets in production". Is it encrypted secrets safe? It's very acceptable for app configuration, for example, your mentioned SendGrid for password recovery. Is it configuration secrets at all in server? Why do I prohibited? Just copy compiled from development to production and it works.

Startup.cs

    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
        var builder = new ConfigurationBuilder().AddUserSecrets<Startup>();
        Konfiguration = builder.Build();
    }

    public IConfiguration Configuration { get; }

    public IConfiguration Konfiguration { get; }

    public void ConfigureServices(IServiceCollection services)
           ....
        services.AddSingleton<IEmailSender, EmailSender>();
        services.Configure<AuthMessageSenderOptions>(Configuration);
        if (Configuration["SendGridKey"] != null)
            return;
        // linux'e secrets.json nenuskaitomas
        services.Configure<AuthMessageSenderOptions>(options => {
            options.SendGridKey = Konfiguration["SendGridKey"];
            options.SendGridUser = Konfiguration["SendGridUser"];
        });
    }

HomeController.cs

    private readonly IOptions<AuthMessageSenderOptions> _optionsAccessor;

    public HomeController(..., IOptions<AuthMessageSenderOptions> optionsAccessor)
    {
        ...
        _optionsAccessor = optionsAccessor;
    }

    public IActionResult Index(...)
    {
        if (_optionsAccessor.Value.SendGridUser != null)
            ModelState.AddModelError("", _optionsAccessor.Value.SendGridUser);
        ....

Go forward with "Enable account confirmation and password recovery" https://learn.microsoft.com/en-us/aspnet/core/security/authentication/accconfirm?view=aspnetcore-2.1&tabs=visual-studio#configure-email-provider

A link to a solution is welcome, but please ensure your answer is useful without it: [add context around the link](//meta.stackexchange.com/a/8259) so your fellow users will have some idea what it is and why it’s there, then quote the most relevant part of the page you're linking to in case the target page is unavailable. [Answers that are little more than a link may be deleted.](//stackoverflow.com/help/deleted-answers) — Filnor, Sep 21 '18 at 06:36
This answer is incorrect and should not follow. _"Just copy compiled from development to production and it works"_ is really dangerous, App Secrets are not encrypted. Read the accepted answer again. — Dush, Mar 02 '20 at 13:13
this does nothing to answer the users concenrs about encryption in production its a valid point. — c-sharp-and-swiftui-devni, Jan 07 '21 at 08:20

How to deploy ASP.NET Core UserSecrets to production

2 Answers2

Linked