Сервер 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([[<html><body>Hello World!</body></html>]], 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();
  local 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.com
5 декабря 2020 года

Haproxy — программирование и конфигурирование средствами Lua