Адзін лабараторны сервер, тры ролі даверу, адна зона адмовы

Усё працуе, пакуль раннер зборкі не запатрабуе той жа хост-сокет, які выкарыстоўвае госць VPN, і тады ўжо ніхто не можа патлумачыць, чаму задача можа чытаць ключы шлюза. Усё было ўсталявана на адной машыне, бо так змясцілася, і кожнаму госцю далі шырокі доступ, бо гэта быў найхутчэйшы спосаб прымусіць яго працаваць. Вынік — хост, мяжа даверу якога гэта кабель сілкавання. Падзел роляў патрабуе менш працы, чым здаецца, і пачынаецца з іх назваў.

Тры ролі, якія зараз дзеляць усё

Уваход VPN, набор прыватных сэрвісаў і раннер зборкі хочуць рознага. Першаму патрэбны публічны порт і вузкая сетка з прыватнага боку. Другому патрэбна пастаяннае сховішча і сакрэты праграмы. Трэці выконвае код, які напісаў хтосьці іншы.

Менавіта тое, што ўсе трое атрымліваюць аднолькавы доступ, робіць сімптом заблытаным, бо тады любы з іх можа паўплываць на іншых. Задача зборкі, якая можа дасягнуць сокета гіпервізара, — гэта задача, якая можа спыніць VPN. Госць сэрвісаў з маршрутам у сетку кіравання можа змяніць канфігурацыю камутатара. Правы — гэта і ёсць праблема, а спіс працэсаў — толькі месца, дзе яна праяўляецца. Калі спачатку назваць ролі, кожнае права атрымае месца, дзе жыць.

Схема ніжэй — гэта адпраўны пункт для такога падзелу, а не абяцанне высокай даступнасці. Стаўцеся да яе як да гіпотэзы, якую трэба праверыць, а не як да гатовага дызайну.

Падзяліце тры ролі, а не тры працэсы

Тры госці на адным хосце даюць тры наборы правоў і тры сеткавыя пазіцыі. Яны не даюць трох зон адмовы, і дызайн павінен сказаць гэта ўголас.

Падзел дапамагае, толькі калі кампраметацыя аднаго госця не дае астатнім правоў аўтаматычна, а гэта налада гіпервізара, а не пагадненне аб назвах. Назваць ВМ шлюзам не перашкодзіць іншаму госцю дасягнуць хоста. Чытайце канфігурацыю віртуальнага камутатара замест імя хоста, а затым пацвердзіце, што кожны госць сядзіць там, дзе вы думаеце.

host
├─ vpn-gw      10.60.10.2/24   public 51820/udp only
├─ services    10.60.0.10/24   no route to the management network
└─ ci-runner   10.60.20.2/24   outbound only, no host socket

Запішыце тапалогію, а затым праверце яе інструментамі, якія ёй валодаюць. Госць, які з'явіўся на няправільным мосце, — гэта знаходка, а не дробязь. Выпраўце сетку, перш чым мяняць любую канфігурацыю сэрвісу.

Дайце госцю VPN адкрываць толькі тыя дзверы, якімі ён валодае

Апублікуйце порт тунеля на маршрутызатары і больш нічога. Порты кіравання гасцямі належаць шляху кіравання, а не інтэрнэту, і ўласны інтэрфейс гіпервізара таксама належыць туды.

Сетка з прыватнага боку павінна дасягаць сэрвісаў, патрэбных аддаленым карыстальнікам, і спыняцца там. Аўтэнтыфікацыя праграм застаецца ўключанай, бо тунель — гэта транспарт, а не ўваход. Трымайце табліцу маршрутызацыі госця VPN дастаткова малой, каб апісаць яе адным сказам. Калі вы не можаце апісаць яе так проста, мяжа ўжо размытая.

virsh net-list --all
virsh net-dumpxml lab-private
sudo nft list ruleset | grep -n -E '51820|10.60'

Усё, што слухае на хосце і не патрэбна для кіравання, не павінна слухаць зусім. Гэта ўключае API гіпервізара, які лёгка пакінуць адкрытым на публічным інтэрфейсе.

Задачам зборкі патрэбная іншая мяжа

Задача CI выконвае каманды, якія кантралюе рэпазіторый, таму яе давер залежыць ад таго, хто можа адпраўляць код. Shell-выканаўца запускае гэтыя каманды ад імя карыстальніка раннера на хосце, і гэта самая шырокая даступная мяжа.

Выканаўцы кантэйнераў вужэйшыя, а прывілеяваны кантэйнер не з вузкіх. Трымайце раннер у асобным госці з уласным сеткавым ахопам і дайце яму толькі доступ да артэфактаў і разгортвання, патрэбны задачам. Аднаразовыя працоўныя памяньшаюць захаваны стан; яны не памяньшаюць дасяжнасць або выкрыццё сакрэтаў. І тое, і другое ўсё яшчэ патрабуе яўных абмежаванняў.

Госць сэрвісаў валодае данымі, таму менавіта яго план рэзервовага капіявання павінен працаваць. Трымайце рэпазіторыі, загрузкі і базу даных у адным раскладзе. Праверце аднаўленне замест чытання статусу задачы.

Плануйце адмову, якую дзеляць усе трое

Адзін хост — адна зона адмовы. Перазагрузка выдаляе тунель і кожны прыватны сэрвіс у адзін і той жа момант, і менавіта тады шлях унутр важны найбольш.

Захавайце доступ да кансолі, які не залежыць ад госця VPN: фізічная кансоль, інтэрфейс кіравання па-за асноўным каналам або кансоль правайдэра. Здымак, захаваны на тым жа дыску, не з'яўляецца незалежнай копіяй, як і рэзервовая копія, што выконваецца ўнутры госця, які яна абараняе. Затым праверце халодны запуск як паслядоўнасць, а не як спіс: хост, віртуальныя сеткі, шлях тунеля і адна названая праграма пад звычайным уліковым запісам.

virsh list --all
systemctl is-active libvirtd
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://10.60.0.10/
ss -ltnp | grep -E ':51820|:443'

Парадак запуску працэсаў нічога не даказвае пра маршруты і DNS, таму правярайце шлях, а не станы юнітаў. Менавіта шлях і патрэбны аддаленаму карыстальніку.