Http Trigger Функция Azure в Docker с неанонимным authLevel

Я играю с функциями Azure, запускаемыми по HTTP, в контейнере Docker. До сих пор все учебники и руководства, которые я нашел по настройке, настраивают функцию Azure с authLevel", установленным на anonymous.

После внимательного прочтения этого блога кажется возможным (хотя и сложно) также настройте другие уровни аутентификации. К сожалению, обещанный пост в блоге (еще) не был написан.

Может ли кто-нибудь помочь мне прояснить, как я буду это делать и настраивать?


docker azure-functions azure-functions-runtime
person Maurits van Beusekom    schedule 02.11.2018    source источник
comment
Кажется, у них есть элемент невыполненной работы и открытая проблема для этого на Github github .com / Azure / azure-functions-core-tools / issues / 29   -  person Sebastian Achatz    schedule 04.11.2018
comment
Спасибо за ваш отзыв, хотя это не совсем то же самое. При запуске в контейнере Docker часть авторизации работает. Когда я настраиваю триггер Http с authLevel, установленным на function, и вызываю функцию, я получаю ошибку 401. Это означает, что мне нужно предоставить правильный ключ, но вопрос в том, как получить доступ к нему. То же самое и с Admin API. Он есть, но я не могу до него добраться, потому что не знаю, как получить токен OAuth.   -  person Maurits van Beusekom    schedule 04.11.2018
comment
Извините, чем я упустил суть ваших вопросов. Итак, вы хотите правильно установить / получить функциональную клавишу?   -  person Sebastian Achatz    schedule 04.11.2018
comment
Секреты должны находиться в файле json в файловой системе рядом с функцией в контейнере. Есть сообщение, посвященное теме секретной ротации, в которой упоминаются подробности. fabriccontroller.net/   -  person Sebastian Achatz    schedule 04.11.2018
comment
@SebastianAchatz, еще раз спасибо за ответ. При публикации в Azure я действительно вижу упомянутые файлы json. Однако они содержат только метку времени (скорее всего, когда они были созданы). В моем докер-контейнере эти json-файлы отсутствуют, и, вероятно, я мог бы добавить один, если бы я только знал, что именно в них вставить (я предполагаю, что только временная метка не сократит его, даже если так ключ будет зашифрованным представление метки времени, и я не знаю, какой метод шифрования используется). Так что это определенно дало мне дополнительную информацию, но еще не решило мою проблему.   -  person Maurits van Beusekom    schedule 05.11.2018
comment
@MauritsvanBeusekom Локально в контейнере докеров, хотя авторизация работает, но у нас нет ключа для доступа, как говорится в проблеме с github. После публикации контейнера в Azure мы можем напрямую получать функциональные ключи на портале.   -  person Jerry Liu    schedule 06.11.2018
comment
@JerryLiu большое спасибо за этот ответ. Если я правильно понимаю, вы говорите, что в настоящее время это не поддерживается. Я также оставил комментарий к проблеме github, чтобы указать, что для этого сценария существует больше вариантов использования, чем указано в исходной проблеме.   -  person Maurits van Beusekom    schedule 06.11.2018
comment
@MauritsvanBeusekom Кажется, эта функция не срочна и не будет добавлена ​​в ближайшее время, возможно, пришло время связаться с автором блога, чтобы научить нас, как достичь этой сложной магии.   -  person Jerry Liu    schedule 12.11.2018

Ответы (2)


arrow_upward
6
arrow_downward

Для управления главным ключом, который хост функции использует при запуске - вместо генерации случайных ключей - подготовьте наш собственный host_secrets.json файл, например

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

а затем загрузите этот файл в назначенную папку секретов хоста функций (Dockerfile):

для функций V1 (предполагается, что корневой каталог среды выполнения - C: \ WebHost):

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

для функций V2 (предполагается, что корневой каталог среды выполнения - 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
...

Функциональные клавиши могут использоваться для вызова защищенных функций, таких как .../api/myfunction?code=asGmO6TCW/t42krL9CljNod3uG9aji4mJsQ7==.

Главный ключ можно использовать для вызова функций Admin API и API управления ключами.

В моем блоге я описываю весь путь внедрения среды выполнения функций V1 и более поздних версий в Docker контейнеров и размещать их в Service Fabric.

person Kai Walter    schedule 08.03.2019
comment
Не могли бы вы поместить информацию в сам ответ, а не просто сослаться на собственный блог? - person Kzrystof; 08.03.2019
comment
Спасибо за ответ, поставил +1. Есть ли где-нибудь документация MS, связанная с host_secret.json? - person OSP; 24.06.2019
comment
@OSP Я думаю, нет, поскольку этот файл является внутренним только для хоста функций - person Kai Walter; 25.06.2019

arrow_upward
0
arrow_downward

Я нашел для себя решение, хотя этот пост уже устарел. Моей целью было запустить функцию Http Trigger Azure в контейнере Docker с помощью function authLevel. Для этого я использую следующий образ Docker: Python для функций Azure из Docker центр.

Я отправил созданный контейнер в Реестр контейнеров Azure после того, как там был готов мой репозиторий. Я хотел запустить свой контейнер без сервера с помощью функции Azure. Итак, я следил за следующий пост и создал новые функции Azure на моем портале Azure.

Таким образом, содержимое контейнера соответствует образу функции Azure, а работа самого контейнера реализуется через Azure с помощью функции Azure. Этот способ не всегда может быть популярным, но дает преимущества для размещения там контейнера. Контейнер можно легко выбрать из реестра контейнеров Azure с помощью Центр развертывания.

Чтобы сделать образ контейнера доступным с помощью function authLevel, функция Azure ~ 3 не может создать ключ узла, поскольку он управляется внутри контейнера. Итак, я поступил следующим образом:

  1. Настройка моего function.json
  "authLevel": "function",
  "type": "httpTrigger",
  1. Предоставление учетной записи хранения, чтобы функция Azure могла получать в ней конфигурации. Создайте там новый контейнер.

лазурные веб-работы-секреты

  1. Создайте каталог внутри контейнера с именем вашей функции Azure.

мое-имя-функции

  1. host.json теперь можно сохранить в каталоге. Он содержит главный ключ.

{masterKey: {имя: мастер, значение: myprivatekey, encrypted: false}, functionKeys: []}

  1. Теперь необходимо настроить функцию Azure, чтобы получить доступ к учетной записи хранения. В конфигурацию необходимо добавить следующие значения.

AzureWebJobsStorage = Строка подключения учетной записи хранения

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING = Строка подключения к учетной записи хранения

WEBSITE_CONTENTSHARE = ​​имя-моей-функции

С этого момента сохраненный главный ключ функции Azure доступен. Таким образом, API контейнера настраивается с помощью функции authLevel и доступен только с помощью соответствующего ключа.

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

ЗАГОЛОВОК: x-functions-key = myprivatekey

person Brenner's Daniel    schedule 15.02.2021