05.12.2020 18:37
apapacy 1 2800 Источник

Сервер 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 года