podman-remote, о котором я мечтал

nponeccop — 26.01.2022

Я тут в своё время, когда был ещё только докер и кубер под стол пешком ходил, был очень недоволен дизайном докера. Типичное предлагаемое решение состояло поместить «в инет» приватный реестр имиджей, туда пушить из CD, и оттуда пуллить на узлы.

Говно в этой архитектуре состоит из 5 частей (п.3 впрочем скоро прикрыли):

1. Прикрытие жопы реестру и докерам выполняется говнокодом на го, который заведомо дырявый по сравнению со зрелыми TLS- или SSH-серверами.
2. Реестр — это дополнительная поверхность атаки, в общем случае не нужная.
3. Завладение реестром позволяет завладеть всеми серверами кластера (но потом для этого придумали подписывать имиджи оффлайн ключами).
4. Докер-демоны, слушающие на каждом узле — это тоже дополнительная поверхность атаки по сравнению с классическим LAMP.
5. Общая идея в том, что control plane нашего кластера активна 24/7 (и доступна для атаки), тогда как для многих реальных применений она нужна только в момент деплоя новой версии. То есть, отказываясь от «активной control plane» мы опять же сужаем поверхность атаки.

Там ещё отдельно были идеи про входящие порты — ну то есть был вариант сделать дизайн, при котором у нас есть «координатор», активный и доступный для взлома 24/7, но он полностью untrusted — все данные на нём подписаны оффлайн-ключами и ключами узлов, и завладение координатором позволит только устроить системе DoS. Но это так совсем уже мои мечты были.

В-общем, чтобы не юзать все эти реестры, докеры и etcd, а также чтобы удовлеворить нужное на тот момент требование работы на CentOS 6, я сделал систему из говна и палок, работающую без реестра и докеров, слушающих на портах.

На сервере были два баш-скрипта:

— runch, аналог runc, стандартный OCI Runtime (но под версию 0.4 стандарта), пускающий бандл в чруте. Парсинг config.json на баше, используя jshon (аналог jq) — это смешно, но учитывая что я срезал углы и парсил только uid, gid и cmd, не проблематично.

—  forever, аналог conmon

На клиенте был vzmaster, аналог podman-remote. Который работал.. через Ansible, который в свою очередь работал через ssh и sftp. Реально были vzmaster-{push,start,kill}.yaml, а vzmaster был над ними обёрткой на баше.

 Юзер лепил OCI Bundle, паковал его в тарболл (формат OCI-имиджей тогда ещё не был стандартизирован) и аплоадил на сервер через Ansible. Ансибл показал себя замечательно со многих сторон:

— возможность надёжно выполнить одно и то же действие для нескольких машин (реально я hosts редактировал, если надо было менять только на части узлов — например, были специализированные узлы)

— как это по-русски.. очень робустные имплементации аплоада там и распаковки, с идемпотентностью и шлюхами

— ансибл использовался и для добавления свежего узла, поскольку мог прямо на сырой сервер, от которого есть только ip и рутовый пароль из письма активации от говнохостера, накатить «систему».

Всё это безобразие позволило в 200 строк на баше и 100 на YAML замутить прилично функционала.

Так вот, это была призказка, а сказка в том, что podman и podman-remote удовлетворяют требованиям по дизайну и безопасности. И можно будет, наконец, выкинуть самоделки и заменить на компоненты, поддерживаемые третьими лицами.

Оставить комментарий

Популярные посты:

constantinus

Круглые переходы для воздуховодов: надёжные решения для эффективной вентиляции

everstti_rymin

Наша праздничная художественная галерея

poltora_bobra

Какой должен быть срок декретного отпуска

colonelcassad

Надо больше дронов. Войска ждут

padolski

Тайны восприятия: как ожидания перекраивают реальность через пение птиц и

a_nalgin

О тяжёлом поражении на Сумщине Теперь только сапёрные лопатки?

kukmor

Доброе утро! Красноярское море. Енисей

inna1903gr

История о

reineke_fuchs

Еще ко дню рождения того, о ком мы не говорим

• Архив