The local.settings.json file for Azure function is created with the property IsEncrypted set to false.
{
"IsEncrypted":false,
"Values" : {
}
}
What does this setting mean and how is it used?
This setting represents whether the values in local.settings.json are encrypted using a local machine key. It's used with func settings encrypt/decrypt/add command of Azure Function Core Tools, hence manually change true/false is meaningless.
Usually we don't need to care about this setting and it's false by default. We can encrypt the settings file once we need to transfer it through internet and want to enforce the security. Because the file can only be decrypted at the machine where we encrypt it.
Here's the doc.
Related
I've been working with functions with Azure, I've built a very simple Http Function locally by following the example linked here, the only difference is I've defined a User table instead of a Todo table
Everything works as expected locally, I'm able to post and get.
However, when deploying the function and trying to make a POST request I see the following within the logs:
Executed 'User' (Failed, Id=5df9dffe-eedf-4b11-aa10-54fda00992b0, Duration=1ms)System.ArgumentNullException : Value cannot be null. (Parameter 'connectionString')
I've checked the SQL Server to ensure it's accessible by other Azure Services just encase that was causing a problem, but I can confirm it's set to allow.
I have found this question, I've gone through the steps and checked against mine and I can confirm my Function App configuration does have the AzureWebJobsStorage connection string.
I'm not 100% sure why this would be happening due to my lack of knowledge of functions at the moment, have anyone else experience this? if so how did you resolve it?
Update
After further testing, it seems the error is coming from my Startup class,
class Startup : FunctionsStartup
{
public override void Configure(IFunctionsHostBuilder builder)
{
string connectionString = Environment.GetEnvironmentVariable("SqlConnectionString");
builder.Services.AddDbContext<ApplicationDbContext>(
options => SqlServerDbContextOptionsExtensions.UseSqlServer(options, connectionString));
}
}
Upon deployment, connectionString variable is null.... not sure why though.
Yes, you can not get it because you didn't set it in the configuration settings.
If you want to use the Connection Strings section.
Add the "ConnectionStrings":{} section to your local.settings.json file then add your connection string
{
...
"ConnectionStrings": {
"MyConnectionString": ""
}
}
Then you need to set the connection string in the Settings section of the Function App in the Azure Portal.
The scroll down to the Connection Section
And add a new connection string. Make sure it has the same name as you connection in the local.settings.json file.
Your question isn't 100% clear if this is happening locally (as you refer to local.settings.json) or when deploying. If this occurs when deploying, changing your local.settings.json file will not help, unfortunately.
You will need to add the Application Setting within the Azure Portal (located under Settings -> Configuration -> Application Settings -> New application setting).
You will need to save the application setting, and then restart the Azure Function instance for the changes to reflect.
Check out https://learn.microsoft.com/en-us/azure/azure-functions/functions-how-to-use-azure-function-app-settings?tabs=portal
I've got an azure app service that I've set up like this:
But when I call IConfiguration.GetConnectionString("db") I get null back.
I've read articles like this https://mderriey.com/2018/08/21/azure-app-service-connection-strings-and-asp-net-core/ which say "it just works", but they're all several years old. I assume something's changed, but what?
Enumerating over all settings in my IConfiguration object I've got no connection strings. I do in development, where my appsettings.development.json has a connectionStrings: { db: "" } defined.
I can see and read the ENV variable: POSTGRESQLCONNSTR_db from within code, and it's value is correct (what I've set via the Azure portal).
Should I expect to be able to do IConfiguration.GetConnectionString("db")? Or am I expected to switch between reading env variables in prod vs dev.
Do I need to include some nuget package to make IConfiguration work under Azure with these ENV variables and their mad prefixes?
My startup.cs basically looks like:
public Startup(IConfiguration configuration)
{
this.Configuration = configuration;
}
public IConfiguration Configuration { get; }
Nothing else in there of interest to this question.
The POSTGRESQLCONNSTR_ prefix isn't supported by the environment variables configuration provider. The docs shows this, in an indirect fashion, where it states that the following prefixes are supported:
CUSTOMCONNSTR_
MYSQLCONNSTR_
SQLAZURECONNSTR_
SQLCONNSTR_
It's also apparent in the source code for the provider.
There are a couple of options for working around this:
Change the Type to Custom in the Connection strings section of the Azure portal.
Change to an Application setting of ConectionStrings:db in the Azure portal.
This is being tracked on GitHub: https://github.com/dotnet/runtime/issues/36123.
I got confused as well, so here it is:
You have two options to specify Connection String locally:
launchSettings.json (environmentVariables section)
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"SQLAZURECONNSTR_SomeConnectionString": "DefaultEndpointsProtocol=blah"
}
appSettings.json
"ConnectionStrings": {
"SomeConnectionString": "DefaultEndpointsProtocol=blah"
}
Having either way will allow you to get the connection string setting by calling:
IConfiguration.GetConnectionString("SomeConnectionString")
Function call above will also work when deployed to Azure, as it is using EnvironmentVariables configuration provider to read settings.
Instead of getting the config from the interface
IConfiguration.GetConnectionString("db")
try to get it from
Configuration.GetConnectionString("db")
And in production you have an empty string in production.appsetting.json and add the value in azure(appservice) configuration directly under connectionstrings(this will override the json setting file). And no nugets are needed for reading from appsettings
I want to know why there isn't an easy way to load your security keys from the AppSettings.json instead of loading them off the file system as XML?
Here is the example from the Microsoft documentation.
services.AddDataProtection()
.PersistKeysToFileSystem("{PATH TO COMMON KEY RING FOLDER}")
.SetApplicationName("SharedCookieApp");
services.ConfigureApplicationCookie(options => {
options.Cookie.Name = ".AspNet.SharedCookie";
options.Cookie.Path = "/";
});
I'm just wondering why there isn't something like the following.
services.AddDataProtection()
.PersistKeysToAppSetings("EncryptionKeys")
.SetApplicationName("SharedCookieApp");
services.ConfigureApplicationCookie(options => {
options.Cookie.Name = ".AspNet.SharedCookie";
options.Cookie.Path = "/";
});
I don't understand why storing keys in an XML file would be any different than storing them in your AppSettigs.json. Now I know the format is different, however it's no more or less secure? correct?
I just want to be sure I'm not missing something.
Assumptions:
AppSettings.json is just as secure as some other XML file on disk
Azure AppSettings are securely stored and can only be access by permitted accounts
Azure AppSettings values would override any uploaded "developer" values
Developers will not store their production keys in source, surely right? :)
I know this would not work for expiring / recycling keys
"It's complicated"
We create keys on demand.
We create multiple keys, just before a key expires, we create a new one.
We need keys to be synchronized between applications.
We need keys to be encrypted where possible.
AppSettings does not give us any of those things, applications can't update their own settings files so that rules out 1 and 2, web sites don't copy a changed app settings file between instances which rules out 3, and you can't encrypt things in app settings which rules out 4.
The format isn't the problem, you could write your own encryption wrapper to cope with #4, but the rest is still necessary, so now you have to change how settings works so they're read/write (and safely read write), and then persuade web hosts to support synchronization of your custom settings file between instances.
I have an Azure function, and I'm using the DI system in order to register some types; for example:
public class Startup : FunctionsStartup
{
public override void Configure(IFunctionsHostBuilder builder)
{
builder.Services
.AddTransient<IMyInterface, MyClass>()
. . . etc
However, I also was to register some data from my environment settings. Inside the function itself, I can get the ExecutionContext, and so I can do this:
IConfiguration config = new ConfigurationBuilder()
.SetBasePath(context.FunctionAppDirectory)
.AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)
.AddEnvironmentVariables()
.Build();
However, in the FunctionsStartup, I don't have access to the ExecutionContext. Is there a way that I can either get the ExecutionContext from the FunctionsStartup class or, alternatively, another way to determine the current running directory, so that I can set the base path?
While the checked answer to this question is correct, I thought it lacked some depth as to why. The first thing you should know is that under the covers an Azure Function uses the same ConfigurationBuilder as found in an ASP.NET Core application but with a different set of providers. Unlike ASP.NET Core which is extremely well documented (https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/) this is not the case for Azure Functions.
To understand this set of providers you can place the following line of code in the Configure(IFunctionsHostBuilder builder) method of your FunctionStartup class,
var configuration = builder.Services.BuildServiceProvider().GetService<IConfiguration>();
place a debug break point after the command, execute your function in debug mode and do a Quick Watch… on the configuration variable (right click the variable name to select Quick Watch…).
The result of this dive into the code execution is the following list of providers.
Microsoft.Extensions.Configuration.ChainedConfigurationProvider
MemoryConfigurationProvider
HostJsonFileConfigurationProvider
JsonConfigurationProvider for 'appsettings.json' (Optional)
EnvironmentVariablesConfigurationProvider
MemoryConfigurationProvider
The ChainedConfigurationProvider adds an existing IConfiguration as a source. In the default configuration case, adds the host configuration and setting it as the first source for the app configuration.
The first MemoryConfigurationProvider adds the key/value {[AzureWebJobsConfigurationSection, AzureFunctionsJobHost]}. At least it does this in the Development environment. At the time I am writing this I can find no documentation on the purpose of this MemoryConfigurationProvider or AzureWebJobsConfigurationSection.
The HostJsonFileConfigurationProvider is another one of those under the covers undocumented providers, however in looking at documentation on host.json (https://learn.microsoft.com/en-us/azure/azure-functions/functions-host-json) it appears to be responsible for pulling this metadata.
The JsonConfigurationProvider for appsettings.json appears to be an obvious correlation to ASP.NET Core’s use of appsettings.json except for one thing which is it does not work. After some investigation I found that the Source FileProvider Root was not set to the applications root folder where the file is located but instead some obscure AppData folder (C:\Users%USERNANE%\AppData\Local\AzureFunctionsTools\Releases\3.15.0\cli_x64). Go fish.
The EnvironmentVariablesConfigurationProvider loads the environment variable key-value pairs.
The second MemoryConfigurationProvider adds the key/value {[AzureFunctionsJobHost:logging:console:isEnabled, false]}. At least it does this in the Development environment. Again, at the time I am writing this I can find no documentation on the purpose of this MemoryConfigurationProvider or AzureFunctionsJobHost.
Now the interesting thing that needs to be pointed out is that no where in the configuration is any mention of local.settings.json. That’s because local.settings.json is NOT part of the ConfigurationBuilder process. Instead local.settings.json is part of Azure Functions Core Tools which lets you develop and test your functions on your local computer (https://learn.microsoft.com/en-us/azure/azure-functions/functions-run-local). The Azure Function Core Tools only focus on specific sections and key/values like IsEncrypted, the Values and ConnectionString sections, etc. as defined in the documentation (https://learn.microsoft.com/en-us/azure/azure-functions/functions-run-local#local-settings-file). What happens to these key/values is also unique. For example, key/values in the Values section are inserted into the environment as variables. Most developers don’t even notice that local.settings.json is by default set to be ignored by Git which also makes it problematic should you remove the repository from you development environment only to restore it in the future. Something that ASP.NET Core has fixed with app secrets (https://learn.microsoft.com/en-us/aspnet/core/security/app-secrets).
So, what happens if we create our own configuration with ConfigurationBuilder as suggested in the original question
IConfiguration config = new ConfigurationBuilder()
.SetBasePath(context.FunctionAppDirectory)
.AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)
.AddEnvironmentVariables()
.Build();
or using the example shown in one of the other answers?
ExecutionContextOptions executionContextOptions = builder.Services.BuildServiceProvider().GetService<IOptions<ExecutionContextOptions>>().Value;
IConfigurationBuilder configurationBuilder = new ConfigurationBuilder()
.SetBasePath(executionContextOptions.AppDirectory)
.AddEnvironmentVariables()
.AddJsonFile("appsettings.json", false)
.AddJsonFile("local.settings.json", true)
.AddUserSecrets(Assembly.GetExecutingAssembly(), true);
The following are just a few of the issues with both examples.
The second example is incorrectly ordered as AddEnvironmentVariables should come last.
Neither of the examples mentions the need for the following line of code.
List item
builder.Services.AddSingleton<IConfiguration>(configurationBuilder.Build());
Without this line the configuration only exist in the Configure(IFunctionsHostBuilder builder) method of your FunctionStartup class. However, with the line you replace the configuration your Azure Function build under the covers. This is not necessarily a good thing as you have no way of replacing providers like HostJsonFileConfigurationProvider.
Reading the local.settings.json file (.AddJsonFile("appsettings.json")) will NOT place the key/value pairs in the Values section into the configuration as individual key/value pairs as expected, but instead group them under the Values section. In other word, if for example you want to access {["AzureWebJobsStorage": ""]} in Values you might use the command configuration.GetValue("Values:AzureWebJobsStorage"). The problem is that Azure is expecting to access it by the key name "AzureWebJobsStorage". Even more interesting is the fact that since local.settings.json was never part of the ConfigurationBuilder process this is redundant as Azure Functions Core Tools has already placed these values into the environment. The only thing this will do is allow you to access sections and key/values not defined as part of local.settings.json (https://learn.microsoft.com/en-us/azure/azure-functions/functions-run-local#local-settings-file). But why would you want to pull configuration values out of a file that will not be copied into your production code?
All of this brings us to a better way to affect changes to the configuration without destroying the default configuration build by Azure Function which is to override the ConfigureAppConfiguration method in your FunctionStartup class (https://learn.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection#customizing-configuration-sources).
The following example takes the one provided in the documentation a step further by adding user secrets.
public override void ConfigureAppConfiguration(IFunctionsConfigurationBuilder builder)
{
FunctionsHostBuilderContext context = builder.GetContext();
builder.ConfigurationBuilder
.SetBasePath(context.ApplicationRootPath)
.AddJsonFile("appsettings.json", optional: true, reloadOnChange: false)
.AddJsonFile($"appsettings.{context.EnvironmentName}.json", optional: true, reloadOnChange: false)
.AddUserSecrets(Assembly.GetExecutingAssembly(), true, true)
.AddEnvironmentVariables();
}
By default, configuration files such as appsettings.json are not automatically copied to the Azure Function output folder. Be sure to review the documentation (https://learn.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection#customizing-configuration-sources) for modifications to your .csproj file. Also note that due to the way the method appends the existing providers it is necessary to always end with .AddEnvironmentVariables().
You don't need any Configuration object in Azure Functions (v2). All the app settings get injected as Environment variables. So you can do just a simple Environment.GetEnvironmentVariable()
When running locally the local.settings.json gets read in the same way.
see here: https://learn.microsoft.com/en-us/sandbox/functions-recipes/environment-variables?tabs=csharp
There's a solid way to do this, answered here:
Get root directory of Azure Function App v2
The fact that Function Apps use environment variables as the typical way to get configuration is, while true, not optimal IMO. The ability to acquire an appsettings.json file in addition to items that deserve to be environment variables has its place.
The number of env vars being set via the DevOps task: "Azure App Service Deploy" option "Application and Configuration Settings" > "App settings" gets completely out of hand.
This is my implementation of it at the time of this writing:
ExecutionContextOptions executionContextOptions = builder.Services.BuildServiceProvider().GetService<IOptions<ExecutionContextOptions>>().Value;
IConfigurationBuilder configurationBuilder = new ConfigurationBuilder()
.SetBasePath(executionContextOptions.AppDirectory)
.AddEnvironmentVariables()
.AddJsonFile("appsettings.json", false)
.AddJsonFile("local.settings.json", true)
.AddUserSecrets(Assembly.GetExecutingAssembly(), true);
This allows me to leverage my release process variables to do environment specific "JSON variable substitution" for the bulk of my configuration, which lives in a nicely structured appsettings.json that is set to Copy Always. Notice that the loading of appsettings.json is set to not optional (the false setting), while I have local settings and secrets set to optional to accommodate local development.
appsettings.json can then be formatted nice and structured like this. Release variables named properly, e.g. "MyConfig.Setting" will replace the value properly if you set your release to do JSON variable substitution.
{
"Environment": "dev",
"APPINSIGHTS_INSTRUMENTATIONKEY": "<guid>",
"MyConfig": {
"Setting": "foo-bar-baz"
}
}
While local.settings.json remains in the flat style:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "DefaultEndpointsProtocol=https;AccountName=<accountname>;AccountKey=<accountkey>;EndpointSuffix=core.windows.net",
"Strickland:Propane:Config": "Dammit, Bobby!"
}
}
In addition, I set some App settings (env vars) to Azure KeyVault References in the release process, as well as the minimum settings that are required for Azure Function runtime to start properly and communicate properly with app insights live metrics.
Hope this helps someone who, like me, hates the ever-growing mass of -Variable.Name "$(ReleaseVariableName)" items in App settings. :)
Unfortunately, at present there is no standard way to get the local running directory. It would be best if ExecutionContext or something similar exposed this.
In the absence of a standard way, I am using AzureWebJobsScriptRoot environment variable to get the current working directory, but it only works locally. In azure environment, I am using Environment.GetEnvironmentVariable("HOME")}\\site\\wwwroot.
I posted a code for this in response to a similar question here:
Azure Functions, how to have multiple .json config files
There is also a similar solution at this github issue.
You might want to use GetContext().ApplicationRootPath, for example:
[assembly:FunctionsStartup(typeof(SampleFunction.FunctionsAppStartup))]
namespace SampleFunction
{
public class FunctionsAppStartup : FunctionsStartup
{
public override void Configure(IFunctionsHostBuilder builder)
{
string appRootPath = builder.GetContext().ApplicationRootPath;
// ...
}
}
}
I have a WebJob that needs to create a JWT token to talk with an external service. The following code works when I run the WebJob on my local machine:
public static string SignES256(byte[] p8Certificate, object header, object payload)
{
var headerString = JsonConvert.SerializeObject(header);
var payloadString = JsonConvert.SerializeObject(payload);
CngKey key = CngKey.Import(p8Certificate, CngKeyBlobFormat.Pkcs8PrivateBlob);
using (ECDsaCng dsa = new ECDsaCng(key))
{
dsa.HashAlgorithm = CngAlgorithm.Sha256;
var unsignedJwtData = Base64UrlEncoder.Encode(Encoding.UTF8.GetBytes(headerString)) + "." + Base64UrlEncoder.Encode(Encoding.UTF8.GetBytes(payloadString));
var signature = dsa.SignData(Encoding.UTF8.GetBytes(unsignedJwtData));
return unsignedJwtData + "." + Base64UrlEncoder.Encode(signature);
}
}
However, when I deploy my WebJob to Azure, I get the following exception:
Microsoft.Azure.WebJobs.Host.FunctionInvocationException: Exception while executing function: NotificationFunctions.QueueOperation ---> System.Security.Cryptography.CryptographicException: The system cannot find the file specified. at System.Security.Cryptography.NCryptNative.ImportKey(SafeNCryptProviderHandle provider, Byte[] keyBlob, String format) at System.Security.Cryptography.CngKey.Import(Byte[] keyBlob, CngKeyBlobFormat format, CngProvider provider)
It says it can't find a specified file, but the parameters I am passing in are not looking at a file location, they are in memory. From what I have gathered, there may be some kind of cryptography setting I need to enable to be able to use the CngKey.Import method, but I can't find any settings in the Azure portal to configure related to this.
I have also tried using JwtSecurityTokenHandler, but it doesn't seem to handle the ES256 hashing algorithm I need to use (even though it is referenced in the JwtAlgorithms class as ECDSA_SHA256).
Any suggestions would be appreciated!
UPDATE
It appears that CngKey.Import may actually be trying to store the certificate somewhere that is not accessible on Azure. I don't need it stored, so if there is a better way to access the certificate in memory or convert it to a different kind of certificate that would be easier to use that would work.
UPDATE 2
This issue might be related to Azure Web Apps IIS setting not loading the user profile as mentioned here. I have enabled this by setting WEBSITE_LOAD_USER_PROFILE = 1 in the Azure portal app settings. I have tried with this update when running the code both via the WebJob and the Web App in Azure but I still receive the same error.
I used a decompiler to take a look under the hood at what the CngKey.Import method was actually doing. It looks like it tries to insert the certificate I am using into the "Microsoft Software Key Storage Provider". I don't actually need this, just need to read the value of the certificate but it doesn't look like that is possible.
Once I realized a certificate is getting inserted into a store somewhere one the machine, I started thinking about how bad of a think that would be from a security standpoint if your Azure Web App was running in a shared environment, like it does for the Free and Shared tiers. Sure enough, my VM was on the Shared tier. Scaling it up to the Basic tier resolved this issue.