Reputation: 5989
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?
Upvotes: 11
Views: 4518
Reputation: 419
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:
function.json
"authLevel": "function",
"type": "httpTrigger",
azure-webjobs-secrets
my-function-name
host.json
can now be stored in the directory. This contains the master key.{
"masterKey":
{
"name": "master",
"value": "myprivatekey",
"encrypted": false
},
"functionKeys": []
}
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
Upvotes: -1
Reputation: 4001
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
Upvotes: 15