8

I am playing around with an Http Triggered Azure Functions in a Docker container. Up to now all tutorials and guides I found on setting this up configure the Azure Function with the authLevel" set to anonymous.

After reading this blog carefully it seems possible (although tricky) to also configure other authentication levels. Unfortunately the promised follow up blogpost has not (yet) been written.

Can anyone help me clarify on how I would go about and set this up?

Maurits van Beusekom
  • 5,579
  • 3
  • 21
  • 35
  • They seem to have a backlog item and an open issue for that on Github https://github.com/Azure/azure-functions-core-tools/issues/29 – Sebastian Achatz Nov 04 '18 at 10:45
  • Thanks for your feedback, although it is not quite the same situation. When running in a Docker container the authorization part works. When I configure the Http trigger with `authLevel` set to `function` and call the function I receive a 401 error. Meaning I need to supply the right key but how do I get access to the key is the question. The same goes for the Admin API. It is there but I cannot get to it because I don’t know how to get the OAuth token. – Maurits van Beusekom Nov 04 '18 at 10:55
  • Sorry than I missed the point in your questions. So you want to set/get the function key right? – Sebastian Achatz Nov 04 '18 at 17:42
  • The secrets should reside in a json file in the file system beside the function in the container. There is a post addressing a secret rotation topic mentioning the details. http://fabriccontroller.net/azure-functions-reset-the-secret-of-your-httptrigger-functions/ – Sebastian Achatz Nov 04 '18 at 17:52
  • @SebastianAchatz, again thanks for the reply. When published to Azure I indeed see the mentioned json files. However they only contain a timestamp (most likely when they were created). In my docker container these json files are missing, and probable could add one if I'd only knew what exactly to put in to them (I am guessing only a timestamp won't cut it, even if so the key will be an encrypted representation of the timestamp and I don't know which encryption technique is used). So this definitely gave me some extra insight but doesn't solve my problem yet. – Maurits van Beusekom Nov 05 '18 at 09:39
  • @MauritsvanBeusekom Locally in a docker container, even though the authorization works but we don't have any key to access just like the github issue says. After we publish the container to Azure, we can get function keys in portal directly. – Jerry Liu Nov 06 '18 at 09:28
  • @JerryLiu thank you very much for this reply. If I understand correctly you are saying this is not supported at the moment. I have also left a comment at the github issue to indicate that there are more use-cases for this scenario then mentioned in the original issue. – Maurits van Beusekom Nov 06 '18 at 09:46
  • @MauritsvanBeusekom It seems this feature is not urgent and won't be added in short term, perhaps it's time to contact the blog author to teach us how to achieve that tricky magic. – Jerry Liu Nov 12 '18 at 08:53

2 Answers2

14

To control the master key the Function host uses on startup - instead of generating random keys - prepare our own host_secrets.json file like

{
    "masterKey": {
        "name": "master",
        "value": "asGmO6TCW/t42krL9CljNod3uG9aji4mJsQ7==",
        "encrypted": false
    },
    "functionKeys": [{
        "name": "default",
        "value": "asGmO6TCW/t42krL9CljNod3uG9aji4mJsQ7==",
        "encrypted": false
    }]
}

and then feed this file into the designated secrets folder of the Function host (Dockerfile):

for V1 Functions (assuming your runtime root is C:\WebHost):

...
ADD host_secrets.json C:\\WebHost\\SiteExtensions\\Functions\\App_Data\\Secrets\\host.json
...

for V2 Functions (assuming your runtime root is C:\runtime):

...
ADD host_secret.json C:\\runtime\\Secrets\\host.json

USER ContainerAdministrator
RUN icacls "c:\runtime\secrets" /t /grant Users:M
USER ContainerUser

ENV AzureWebJobsSecretStorageType=files
...

The function keys can be used to call protected functions like .../api/myfunction?code=asGmO6TCW/t42krL9CljNod3uG9aji4mJsQ7==.

The master key can be used to call Functions Admin API and Key management API.

In my blog I describe the whole journey of bringing V1 and later V2 Functions runtime into Docker containers and host those in Service Fabric.

for V3 Functions on Windows:

ENV FUNCTIONS_SECRETS_PATH=C:\Secrets
ENV AzureWebJobsSecretStorageType=Files
ADD host_secrets.json C:\\Secrets\\host.json

for V3 Functions on Linux:

RUN mkdir /etc/secrets/
ENV FUNCTIONS_SECRETS_PATH=/etc/secrets
ENV AzureWebJobsSecretStorageType=Files
ADD host_secrets.json /etc/secrets/host.json
Kai Walter
  • 3,485
  • 2
  • 32
  • 62
  • Could you put the information in the answer itself, and not just referencing your own blog? – Kzryzstof Mar 08 '19 at 17:20
  • Thanks for the answer, giving +1. Is there any MS documentation related to host_secret.json anywhere? – OSP Jun 24 '19 at 13:18
  • @OSP I guess not as this file is only internal to the Functions host – Kai Walter Jun 25 '19 at 05:15
  • Sorry, how do you apply this to Linux containers? – Panzercrisis Aug 26 '21 at 19:40
  • 1
    @Panzercrisis I attached 2 samples how we now do it for V3 on Windows and Linux – Kai Walter Aug 27 '21 at 05:09
  • If we force a host.json file with Master keys in the container, then a release in production will have the same master secrets as a developpement or uat releases. For me this is a very High security risk. Either the developpers have access to master keys or the dev, uat and production container images should be compiled with different host.json files. And in this case this is a risk that what is tested is completely different that what is running in live production environment. – neothoms Jul 26 '22 at 08:27
-1

I found a solution for me, even though this post is out of date. My goal was to run a Http Trigger Azure Function in Docker container with function authLevel. For this I use the following Docker Image: Azure Functions Python from Docker hub.

I pushed my created container to an Azure Container Registry after my repository was ready there. I wanted to run my container serverless via Azure Function. So I had followed the following post and created a new Azure Functions in my Azure Portal.

Thus, the container content corresponds to an Azure Function Image and the operation of the container itself is implemented through Azure by an Azure Function. This way may not always be popular, but offers advantages to host a container there. The container can be easily selected from the Azure Container Registry via Deployment Center.

To make the container image accessible via function authLevel, the Azure Function ~3 cannot create a host key as this is managed within the container. So I proceeded as follows:

  1. Customizing my function.json
"authLevel": "function",
"type": "httpTrigger",
  1. Providing a storage account so that the Azure Function can obtain configurations there. Create there a new container.
azure-webjobs-secrets
  1. Create a directory inside the container with the name of your Azure Function.
my-function-name
  1. A host.json can now be stored in the directory. This contains the master key.
{
    "masterKey": 
    {
        "name": "master",
        "value": "myprivatekey",
        "encrypted": false   
    },   
    "functionKeys": [] 
}
  1. Now the Azure Function has to be configured to get access to the storage account. The following values must be added to the configuration.
AzureWebJobsStorage = *Storage Account Connection String*
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING = *Storage Account Connection String*
WEBSITE_CONTENTSHARE = *my-function-name*

From now on, the stored Azure Function master key is available. The container API is thus configured via authLevel function and only accessible with the corresponding key.

URL: https://my-function-name.azurewebsites.net/api/helloworld

HEADER: x-functions-key: myprivatekey

cognophile
  • 802
  • 11
  • 25
Brenners Daniel
  • 389
  • 5
  • 15