Мы живем в мире, где трудно представить какую-либо корпоративную службу, не являющуюся многопользовательской системой. От вашего уровня IaaS до реестров контейнеров, компаниям нравится легко интегрировать пользователей и команды, применять политики доступа и квоты, используя при этом как можно меньше экземпляров службы. Почему ваше предложение FaaS (функция как услуга) должно отличаться?
С последним выпуском Dispatch — бессерверной среды с открытым исходным кодом — мы ближе, чем когда-либо, к тому, чтобы помочь вам создать многопользовательскую FaaS. В этом сообщении блога мы рассмотрим, как создавать различные клиенты в Dispatch, добавлять в него пользователей и запускать функции. Мы также обсудим некоторые недостатки и то, как мы планируем их устранять в будущем. Для простоты предположим, что Dispatch настроен с OpenFaaS в качестве механизма FaaS и использует Google Identity Platform в качестве провайдера OpenID Connect.
Но прежде чем мы поговорим о мультиарендности, важно понять аутентификацию и авторизацию в Dispatch, поскольку они формируют основные принципы, на которых может быть построена мультиарендность.
Аутентификация
Dispatch не управляет вашими учетными записями пользователей
Dispatch не управляет учетными записями пользователей самостоятельно, другими словами, нет понятия добавления учетных записей с определенным именем пользователя/паролем в Dispatch с помощью вызова API. Это потому что:
- В команде редко бывают только Алиса и Боб или только администратор/пользователь root в корпоративной системе. Обычно существует пользовательский каталог с аутентификацией LDAP или другими решениями для управления идентификацией. Службе сложно (и подвержено ошибкам) управлять большими наборами пользователей и поддерживать их синхронизацию с каталогами.
- Снижение доверия к приложениям, в которых хранятся ваши корпоративные учетные данные. Насколько знакома эта подсказка «Пожалуйста, введите имя пользователя/пароль AD» на внутреннем сервисном портале? Тем не менее, мы понятия не имеем, как наши учетные данные хранятся и управляются.
- И, наконец, единый вход останется, независимо от того, хотите ли вы, чтобы вас перебрасывали на несколько порталов через перенаправления, или нет.
Следовательно, Dispatch не управляет учетными записями пользователей и не хранит учетные данные, но хорошо интегрируется с провайдерами OpenID Connect, такими как Google Identity Platform, vIDM, Auth0 или Dex, которые обеспечивают аутентификацию сеанса по устоявшемуся стандарту.
Но подождите, а как насчет учетных записей автоматизации или интеграции, работающих в небраузерной среде? Для таких нужд в Dispatch есть понятие служебные аккаунты. Это локально управляемые учетные записи, защищенные ключами RSA.
Авторизация
На основе правил
Авторизация в Dispatch обеспечивается политиками, описывающими права доступа пользователя/группы. Прежде чем пользователь сможет войти в Dispatch, нам необходимо создать политики, которые предоставляют привилегии для одного или нескольких ресурсов, таких как функции, изображения и т. д. В пределах одного арендатора пользователи могут иметь разные привилегии в зависимости от их функциональной роли. Как правило, у администратора есть доступ к добавлению базовых образов и образов — это безопасные образы контейнеров со средой выполнения и зависимостями, необходимыми для выполнения функции. Разработчик, напротив, может создавать функции на основе образа, предоставленного администратором. С другой стороны, учетная запись службы, используемая для мониторинга использования ресурсов, может иметь права только на чтение. Вы поняли!
Пример политики в Dispatch, описанный в формате JSON:
[
{
"createdTime": 1530561893,
"global": true,
"id": "f8d0b220-26b0-4de8-b281-1066156690a6",
"kind": "Policy",
"modifiedTime": 1530561893,
"name": "default-policy",
"rules": [
{
"actions": [
"*"
],
"resources": [
"images,base-images"
],
"subjects": [
"[email protected]"
]
}
],
"status": "READY"
}
]
Мульти аренды
Хорошо, давайте перейдем к сути этого блога. Клиенты в Dispatch называются Организациями. Вы можете создавать организации и настраивать политики в каждой из них для подключенных пользователей/команд. В этом примере мы создадим организации, представляющие две вымышленные команды frontend и backend типичного продукта. Затем мы добавим административные политики, пользовательские политики, а затем позволим пользователям создавать и запускать функции.
Создание новой организации
После установки диспетчера на основе шагов, подробно описанных здесь, вы теперь вошли в Dispatch под организацией по умолчанию dispatch с пользователем, который имеет привилегии бога или, другими словами, супер -admin пользователя. Вы можете использовать эту учетную запись для настройки других организаций и политик.
Убедитесь, что у вас есть необходимые привилегии, перечислив существующие организации:
$ dispatch iam get organizations
NAME | CREATED DATE
----------------------------------------
dispatch | Mon Jul 2 13:04:50 PDT 2018
Теперь создайте две новые организации frontend-team и backend-team с помощью:
$ dispatch iam create organization frontend-team Created organization: frontend-team $ dispatch iam create organization backend-team Created organization: backend-team
Добавление политик администратора
Теперь мы добавляем две политики, предоставляющие права администратора определенным пользователям команд. Поскольку мы настроили Google Identity Platform в качестве поставщика подключения OpenID, мы используем адрес электронной почты, связанный с пользователями-администраторами, при настройке политики.
Обратите внимание на использование флага--organization для обозначения арендатора, для которого должна быть создана политика. Это работает, поскольку мы вошли в систему как пользователь супер-администратора, который имеет привилегии во всех организациях.
$ dispatch iam create policy frontend-admin \ --subject [email protected] \ --action "*" --resource "*" \ --organization frontend-team Created policy: frontend-admin $ dispatch iam create policy backend-admin \ --subject [email protected] \ --action "*" --resource "*" \ --organization backend-team Created policy: backend-admin
Войдите как администратор интерфейса
Давайте выйдем из системы как суперадминистратор и войдем в систему как администратор команды внешнего интерфейса.
$ dispatch logout You have successfully logged out $ dispatch login --organization frontend-team
Поскольку мы настроили Google Identity Platform в качестве поставщика OpenID Connect, команда dispatch login откроет браузер по умолчанию и предложит пользователю войти в свою учетную запись Google. В этом случае, поскольку мы входим в систему как администратор интерфейса, давайте выберем соответствующую учетную запись.
После ввода учетных данных для учетной записи frontend admin вы заметите некоторые перенаправления, связанные с предоставлением кода авторизации OAuth2, а затем в браузере появится следующее сообщение:
На этом этапе ваш интерфейс командной строки получил файл cookie для сеанса, и вы вошли в систему как администратор внешнего интерфейса в организации группа внешнего интерфейса.
Создавайте базовые образы и образы для использования членами команды. Как упоминалось выше, эти образы представляют собой безопасные образы контейнеров, которые обеспечивают среду выполнения и зависимости для кода вашей функции.
$ dispatch create seed-images Created BaseImage: nodejs-base Created BaseImage: python3-base Created BaseImage: powershell-base Created BaseImage: java-base Created Image: nodejs Created Image: python3 Created Image: powershell Created Image: java
Добавить пользовательские политики для группы внешнего интерфейса
Следующие команды добавляют политики для разработчиков фронтенд-команды, ограничивая их доступ к созданию и выполнению функций. Поскольку изображения необходимы для создания функций, мы предоставляем пользователям доступ для чтения к изображениям.
# Allow CRUD on functions and related resources $ dispatch iam create policy dev-policy-crud \ --subject [email protected] \ --subject [email protected] \ --action "*" \ --resource function,runs,secret,api Created policy: dev-policy-crud # Read-Only access on Image resources $ dispatch iam create policy dev-policy-read \ --subject [email protected] \ --subject [email protected] \ --action get \ --resource image,baseimage Created policy: dev-policy-read
Войдите как разработчик внешнего интерфейса
$ dispatch logout You have successfully logged out $ dispatch login --organization frontend-team
Создайте функцию в качестве разработчика внешнего интерфейса
$ cat > /tmp/node-hello.js <<EOF
module.exports = function (context, params) {
let name = "Noone";
if (params.name) {
name = params.name;
}
let place = "Nowhere";
if (params.place) {
place = params.place;
}
return {myField: 'Hello, ' + name + ' from ' + place + ' - Yours, nodejs!'}
};
EOF
$ dispatch create function --image=nodejs node-hello-js /tmp/node-hello.js
Created function: node-hello-js
Создайте API для функции nodejs
Dispatch имеет встроенный шлюз API (работает на Kong), который поддерживает создание API, которые затем указывают на вашу функцию.
$ dispatch create api frontend-hello-js node-hello-js --path /hello --cors Created api: frontend-hello-js
Выполнение функции через API
После создания API вы можете получить к нему доступ через шлюз API Dispatch. Для этого блога шлюз API был настроен на использование хоста orgdemo.dispatchframework.io. Следовательно, ко всем путям API можно получить доступ по адресу https://orgdemo.dispatchframework.io/<org_name/<path>.. Таким образом, к созданному выше API можно получить доступ по следующему URL-адресу:
$ curl https://orgdemo.dispatchframework.io/frontend-team/hello {"myField":"Hello, Noone from Nowhere - Yours, nodejs!"}
Повторите шаги для Backend Team.
Давайте выполним те же действия, что и раньше, для бэкэнд-команды. Для краткости не будем подробно останавливаться на каждом шаге.
############################ # Login as Backend Admin ############################ $ dispatch login --organization backend-team # Choose the `Backend Admin`Account in the Google Authentication Prompt # Allow CRUD on functions and related resources $ dispatch iam create policy dev-policy-crud \ --subject [email protected] \ --subject [email protected] \ --action "*" \ --resource function,runs,secret,api Created policy: dev-policy-crud # Read-Only access on Image resources $ dispatch iam create policy dev-policy-read \ --subject [email protected] \ --subject [email protected] \ --action get \ --resource image,baseimage Created policy: dev-policy-read $ dispatch logout You have successfully logged out ############################ # Login as Backend Developer ############################ $ dispatch login --organization backend-team # Choose the `Backend Developer` Account in the Google Authentication Prompt ################################################### # Create a Python Function as the Backend Developer ################################################### $ cat > /tmp/python_hello.py <<EOF def handle(ctx, payload): name = "Noone" place = "Nowhere" if payload: name = payload.get("name", name) place = payload.get("place", place) return {"myField": "Hello, %s from %s - Yours, python3!" % (name, place)} EOF $ dispatch create function --image=python3 python-hello /tmp/python_hello.py ####################################### # Create an API for the python function ####################################### $ dispatch create api backend-hello-python python-hello --path /hello Created api: backend-hello-python
Выполнение функции Backend Team через API
$ curl https://orgdemo.dispatchframework.io/backend-team/hello {"myField":"Hello, Noone from Nowhere - Yours, python3!"}
Будущая работа
Мы на доске зарисовываем проекты (и рисуем…), чтобы во многих отношениях улучшить работу с несколькими арендаторами. Вот некоторые из задач, находящихся в стадии разработки:
- Группы LDAP/группы OIDC заявляют о поддержке
- Поддержка определения ролей в политиках
- Автоматизируйте создание SSL-сертификата для каждой организации для конечных точек API.
- Поддержка реестров образов для каждой организации
Вывод
Благодаря последней версии Dispatch теперь можно создать многопользовательскую услугу FaaS на вашем предприятии, а также привлечь к работе ваши команды и разработчиков. Разве это не FaaScinating?
