Setting secrets when hosting Functions runtime in a container
Tags: azurefunctions, container, docker, kubernetes
Published: 2019-09-20 09:04:28

---
title: Setting secrets when hosting Functions runtime in a container
published: true
description: When hosting Functions runtime in a container, you cannot let the runtime choose the function keys for you - otherwise you end up in different keys for the various container instances you host the Functions in. With the new environment variable FUNCTIONS_SECRETS_PATH this is now easier to achieve.
tags: #azurefunctions #container #docker #kubernetes
---

Functions runtime v2 makes it is pretty easy to leverage one of the pre-canned [images](https://hub.docker.com/_/microsoft-azure-functions-base), pack up your Functions app into an image and host it on Docker, Kubernetes or - as in [my case - on Service Fabric](https://dev.to/kaiwalter/azure-functions-on-service-fabric-40n8).

However when calling HTTP triggered functions protected with `AuthorizationLevel.Function` or `AuthorizationLevel.Admin` as well as calling one of the [administration endpoints](https://github.com/Azure/azure-functions-host/wiki/Admin-API) you need to know the respective keys. In a container CI/CD scenario it maybe required that you preset the keys to make health check & administrative calls to the host or to wire up Functions with some API gateway etc.

But if keys are not provided to the Functions host, it will just generate new ones - which would result in different keys, when the same Functions host is operated on multiple container instances. Without going into the running container it would not be possible to determine these codes for later use.

# How to provide secrets?

First element is a `host.json` file which sets the required keys - one master key, one default function key and, if required, separate keys for each function.

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

2nd is to place this file in a folder so that it can be picked up by the Functions host.

Before [Functions host release 2.0.12701](https://github.com/Azure/azure-functions-host/releases/tag/v2.0.12701), in the `Dockerfile` 

- `host.json` had to be copied to `runtime\secrets` folder
- write access to the folder had to be granted, so that the Functions host could modify the file
- the host had to be configured to use secrets from file system

```
ADD Secrets\\host.json C:\\runtime\\Secrets\\host.json
USER ContainerAdministrator
RUN icacls "c:\runtime\secrets" /t /grant Users:M
USER ContainerUser
ENV AzureWebJobsSecretStorageType=files
```

With release _2.0.12701_ this can be achieved by simply putting the file in a regular folder and setting the environment variable `FUNCTIONS_SECRETS_PATH` w/o the need to mess around with ACLS:

```
ADD Secrets\\host.json C:\\Secrets\\host.json
ENV FUNCTIONS_SECRETS_PATH=C:\Secrets
ENV AzureWebJobsSecretStorageType=files
```

# Additional bonus

The new release also now lets logs to be put in a folder of your choice - instead in one of the sub-folders of the runtime:

```
ENV FUNCTIONS_LOG_PATH=C:\Logs
```