Haproxy — программирование и конфигурирование средствами Lua
Сервер Haproxy имеет встроенные средства для выполнения скриптов Lua.Язык программирования Lua для расширения возможностей различных серверов используется очень широко. Например, на Lua можно программировать для серверов Redis, Nginx (nginx-extras, openresty), Envoy. Это вполне закономерно, так как язык программирования Lua как раз и был разработан для удобства встраивания в приложения в качестве скриптового языка.В этом сообщении я рассмотрю варианты использования Lua для расширения возможностей Haproxy.Согласно документации, скрипты Lua на сервере Haproxy могут выполняться в шести контекстах:
- body context (контекст времени загрузки конфигурации сервера Haproxy, когда выполняются скрипты, заданные директивой lua-load);
- init context (контекст функций, которые вызываются сразу после загрузки конфигурации, и зарегистрированы системной функции core.register_init (function);
- task context (контекст функций, выполняемых по расписанию и зарегистрированных системной функцией core.register_task (function));
- action context (контекст функций, зарегистрированных системной функцией сore.register_action (function));
- sample-fetch context (контекст функций, зарегистрированных системной функцией сore.register_fetches (function));
- converter context (контекст функций, зарегистрированных системной функцией сore.register_converters (function)).
Фактически есть еще один контекст выполнения, который не указан в документации:
- service context (контекст функций, зарегистрированных системной функцией сore.register_service (function));
Начнем с самой простой конфигурации сервера Haproxy. Конфигурация состоит из двух секций frontend — то есть то, к чему обращается клиент с запросом, и backend — то, куда проксируется запрос клиента через сервер Haproxy:
frontend jwt
mode http
bind *:80
use_backend backend_app
backend backend_app
mode http
server app1 app:3000
Теперь все запросы, приходящие на порт 80 Haproxy будут перенаправлены на порт 3000 сервера app.
Services
Services — это функции, определенные в скриптах Lua, которые формируют ответ без обращения к бэкенду. Эти функции регистрируются вызовом системной функции сore.register_service (function)).Определим простейший Service в файле guarde.lua:
function _M.hello_world(applet)
applet:set_status(200)
local response = string.format([[Hello World!
]], message);
applet:add_header("content-type", "text/html");
applet:add_header("content-length", string.len(response))
applet:start_response()
applet:send(response)
end
И зарегистрируем ее как Service в файле register.lua:
package.path = package.path .. "./?.lua;/usr/local/etc/haproxy/?.lua"
local guard = require("guard")
core.register_service("hello-world", "http", guard.hello_world);
Параметр «http» является триггером, который допускает использование Service только в контексте http запроса (mode http).Дополним конфигурацию сервера Haproxy:
global
lua-load /usr/local/etc/haproxy/register.lua
frontend jwt
mode http
bind *:80
use_backend backend_app
http-request use-service lua.hello-world if { path /hello_world }
backend backend_app
mode http
server app1 app:3000
Теперь, обратившись к серверу Haproxy с запросом /hello_world, клиент получит не ответ с проксируемого сервера, а ответ сервиса lua.hello-world.В качестве параметра функции передается контекст запроса в параметре applet. Нет возможности передать дополнительные параметры файле конфигурации.
Actions
Actions — действия, выполняемые после получения запроса от клиента или после получения ответа от проксируемого сервера. Actions могут выполнять асинхронные операции (например запросы к базе данных) и не имеют возвращаемого значения. С сервером Actions общаются путем установки переменных контекста запроса. Контекст запроса предается в качестве параметра при вызове Action. Традиционно имя этого параметра txn. Передать дополнительные параметры из файла конфигурации Haproxy в Action нельзя. Создадим Action, который будет проверять наличие авторизации Bearer в запросе:
function _M.validate_token_action(txn)
local auth_header = core.tokenize(txn.sf:hdr("Authorization"), " ")
if auth_header[1] ~= "Bearer" or not auth_header[2] then
return txn:set_var("txn.not_authorized", true);
end
local claim = jwt.decode(auth_header[2],{alg="RS256",keys={public=public_key}});
if not claim then
return txn:set_var("txn.not_authorized", true);
end
if claim.exp < os.time() then
return txn:set_var("txn.authentication_timeout", true);
end
txn:set_var("txn.jwt_authorized", true);
end
Зарегистрируем этот Action:
core.register_action("validate-token", { "http-req" }, guard.validate_token_action);
Параметр { «http-req» } является триггером, который позволяет использовать этот Action только в контексте http и только на этапе запроса клиента (и запрещает использовать на этапе ответа проксируемого сервера).В конфигурации Haproxy, Action регистрируется в секции http-request:
frontend jwt
mode http
bind *:80
http-request use-service lua.hello-world if { path /hello_world }
http-request lua.validate-token if { path -m beg /api/ }
На основании значения переменных, установленных в Action, формируются ACL (Access Control Lists) — ключевой элемент в конфигурациях Haproxy:
acl jwt_authorized var(txn.jwt_authorized) -m bool
use_backend app if jwt_authorized { path -m beg /api/ }
Полный листинг конфигурации сервера Haproxy для Action validate-token:
global
lua-load /usr/local/etc/haproxy/register.lua
frontend jwt
mode http
bind *:80
http-request use-service lua.hello-world if { path /hello_world }
http-request lua.validate-token if { path -m beg /api }
acl bad_request var(txn.bad_request) -m bool
acl not_authorized var(txn.not_authorized) -m bool
acl authentication_timeout var(txn.authentication_timeout) -m bool
acl too_many_request var(txn.too_many_request) -m bool
acl jwt_authorized var(txn.jwt_authorized) -m bool
http-request deny deny_status 400 if bad_request { path -m beg /api/ }
http-request deny deny_status 401 if !jwt_authorized { path -m beg /api/ } || not_authorized { path -m beg /api/ }
http-request return status 419 content-type text/html string "Authentication Timeout" if authentication_timeout { path -m beg /api/ }
http-request deny deny_status 429 if too_many_request { path -m beg /api/ }
http-request deny deny_status 429 if too_many_request { path -m beg /auth/ }
use_backend app if { path /hello }
use_backend app if { path /auth/login }
use_backend app if jwt_authorized { path -m beg /api/ }
backend app
mode http
server app1 app:3000
Fetches
Fetches — это значения которые вычисляются в процессе запроса. Они могут быть только синхронными, и принимают параметры, заданные в конфигурации Haproxy. Например, та же самая проверка авторизации может быть выполнена как Fetch:
function _M.validate_token_fetch(txn)
local auth_header = core.tokenize(txn.sf:hdr("Authorization"), " ")
if auth_header[1] ~= "Bearer" or not auth_header[2] then
return "not_authorized";
end
local claim = jwt.decode(auth_header[2],{alg="RS256",keys={public=public_key}});
if not claim then
return "not_authorized";
end
if claim.exp < os.time() then
return "authentication_timeout";
end
return "jwt_authorized:" .. claim.jti;
end
core.register_fetches("validate-token", _M.validate_token_fetch);
Установка ACL по значениям из Fetches задается так:
http-request set-var(txn.validate_token) lua.validate-token()
acl bad_request var(txn.validate_token) == "bad_request" -m bool
acl not_authorized var(txn.validate_token) == "not_authorized" -m bool
acl authentication_timeout var(txn.validate_token) == "authentication_timeout" -m bool
acl too_many_request var(txn.validate_token) == "too_many_request" -m bool
acl jwt_authorized var(txn.validate_token) -m beg "jwt_authorized"
Converters
Converters в качестве параметра принимают строку и возвращают значение. Converters, также как и Fetches, могут быть только синхронными и принимают параметры, задаваемые в конфигурации Haproxy. В конфигурации Haproxy Converters отделяются от значения, к которому они применяются, запятой.Создадим Converter, который будет заголовок Authorization преобразовывать в строку:
function _M.validate_token_converter(auth_header_string)
local auth_header = core.tokenize(auth_header_string, " ")
if auth_header[1] ~= "Bearer" or not auth_header[2] then
return "not_authorized";
end
local claim = jwt.decode(auth_header[2],{alg="RS256",keys={public=public_key}});
if not claim then
return "not_authorized";
end
if claim.exp < os.time() then
return "authentication_timeout";
end
return "jwt_authorized";
end
core.register_converters("validate-token-converter", _M.validate_token_converter);
В файле конфигурации использование конвертера задается следующим образом:
http-request set-var(txn.validate_token) hdr(authorization),lua.validate-token-converter
К значениею заголовка Authorization, который извлекается системным Fetch hdr () применяется Converter lua.validate-token-converter.
Stick Table
Stick Table — это хранилище пар ключ-значение, которое оптимизировано для учета количества запросов в единицу времени, и служит, прежде всего, для защиты серверов от атак DDoS или брутфорса (напрмер перебора паролей или выкачки запросами REST больших объемов данных). В сочетании с такими средствами как Fetches и Converters, эти таблицы могут подсчитывать количество запросов, например, с определенным сессионным cookie или jti, не давая тем самым использовать одну авторизацию для организации распределенной атаки с сотен тысяч устройств. К положительным сторонам Stick Table относится скорость работы и простота конфигурирования. К отрицательным — ограниченное количество регистров для учета значений (всего восемь регистров), потребление памяти, потеря данных после перегрузки сервера Haproxy. Рассмотрим как задаются правила в Stick Table:
stick-table type string size 100k expire 30s store http_req_rate(10s)
http-request track-sc1 lua.validate-token()
http-request deny deny_status 429 if { sc_http_req_rate(1) gt 3 }
Строка 1. Создается таблица. В качестве ключа используется значение типа строка. Максимальный размер таблицы 100k. Срок хранения ключа 30 секунд. В качестве значения будут накапливаться количество запросов за последние 10 секунд с одинаковым значением ключа типа строка. Строка 2. Задается, что значение ключа определяется из Fetch lua.validate-token (), и будет использоваться регистр 1, в котором будут накапливаться значения (track-sc1)Строка 3. Если количество запросов с ключом, заданными в строке 2, накопленных в регистре 1 (sc_http_req_rate (1)) превышает 3 — сервер отдает ответ со статусом 429.
Асинхронные Actions
Если есть необходимость использовать асинхронный код (например запросы в базу данных) — то Actions это единственный выбор. Любого разработчика будет волновать вопрос, насколько асинхронные запросы будут снижать призводительность работы сервера. Если сравнить в этом аспекте Haproxy c основными конкуретнтами Nginx/Openresty и Envoy, то расклад будет такой. Envoy разрешает выполнение асинхронного кода, но оно будет фактически блокировать работу сервера на время выполнения этого запроса, и поэтому не рекомендуется. Openresty, напротив, поощряет использование асинхронного кода, но только если используемые библиотеки были специально разработаны для Openresty. В этих библиотеках на время выполнение асинхроных операций происходит высвобождение ресурсов, примерно как это делает Nodejs, реализующий свою главную фичу — NIO (не блокирующий ввод-вывод). Именно из-за особенностей архитектуры этого решения, Openresty работет на версии Lua 5.1 и не переходит на более высокие версии Lua 5.2 или 5.3. Haproxy, в отличие от Openresty, позволяет использовать библиотеки общего назначения Lua без ограничений по версиям. Но, в отличие от Envoy, асинхронные вызовы не блокируют работу сервера. По моим выборочным замерам призводиетельности некоторых запросов они, близки к тому что выдает на асинхронных запросах Openresty — хотя я, не претендую в этой оценке на полную объективность.Сейчас мы рассмотрим обращение к серверу Redis. В предыдущем разделе мы рассмтривали посчет количества запросов с определенным ключом при помощи Stick Table. Они работают очень быстро, но не без недостатков. Судя по «поведению» реального севрера, срок хранения ключа «продлевается» при каждом новом запросе. Это приводит к тому, что стчетчик не «сбрасывается» по окончании заданного срока и запросы начинают отвергаться все на 100%. Для того чтобы трафик возобновился, нужно чтобы на время действия ключа полностью прекратились запросы с этим ключом. Обычно это не то поведение, которое ожидается. Реализуем счетичики запросов на Redis, и будем отвергать запросы после превышения заданного лимита за заданный период времени:
function _M.validate_body(txn, keys, ttl, count, ip)
local body = txn.f:req_body();
status, data = pcall(json.decode, body);
if not (status and type(data) == "table") then
return txn:set_var("txn.bad_request", true);
end
local redis_key = "validate:body"
for i, name in pairs(keys) do
if data[name] == nil or data[name] == "" then
return txn:set_var("txn.bad_request", true);
end
redis_key = redis_key .. ":" .. name .. ":" .. data[name]
end
if (ip) then
redis_key = redis_key .. ":ip:" .. ip
end
local test = _M.redis_incr(txn, redis_key, ttl, count);
end
function _M.redis_incr(txn, key, ttl, count)
local prefixed_key = "mobile:guard:" .. key
local tcp = core.tcp();
if tcp == nil then
return false;
end
tcp:settimeout(1);
if tcp:connect(redis_ip, redis_port) == nil then
return false;
end
local client = redis.connect({socket=tcp});
local status, result = pcall(client.set, client, prefixed_key, "0", "EX", ttl, "NX");
status, result = pcall(client.incrby, client, prefixed_key, 1);
tcp:close();
if tonumber(result) > count + 0.1 then
txn:set_var("txn.too_many_request", true)
return false;
else
return true;
end
end
core.register_action("validate-body", { "http-req" }, function(txn)
_M.validate_body(txn, {"name"}, 10, 2);
end);
Код, использованный в данном сообщении доступен в репозитарии. В частности, там есть файл docker-compose.yml, который поможет поднять необходимую для работы среду.apapacy@gmail.com5 декабря 2020 года
