Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Питання про баланс безпеки, повторюванності та стабільності

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Docker-контейнер проектувався як, перш за все, стабільне і повторюване середовище, контейнер для програми.

Тобто, з цієї точки зору, варто писати

FROM ubuntu:bionic-20230412
RUN apt install pkg=ver

тоді ви завжди отримаєте дійсно той самий докер контейнер з одного і того-ж Dockerfile

але з точки зору безпеки

FROM ubuntu:bionic
RUN apt install pkg

дещо краще, бо ви отримаєте останню версію образа ОС зі всіма виправленнями безпеки, що з точки зору безпеки — краще, але з точки зору повторюванності контейнеру — гірше, бо будуть встановлені інші версії пакетів (більше того — кожного разу ви будете отримувати різні, в загальному випадку, контейнери з іншими бінарниками). Тобто ви порушуєте принцип повторюваності за рахунок підвищення безпеки.

Більше того, збірка

RUN apt install pkg

буде більш стабільною на етапі саме збірки контейнера, бо ubuntu полюбляють видаляти старі версії пакетів з репозиторію через деякий час після виходу виправлення. Тому

RUN apt install pkg=ver

може просто не спрацювати бо пакету вказаної версії просто немає в репозиторіях

Після збірки теж є питання до зберігання старих контейнерів в container registry. з одного боку зберігання старих контейнерів це проблема безпеки — бо є можливість, що їх використають для запуску і використають вразливість. З іншого боку видалення старих контейнерів означає, що ви не зможете зібрати чи запустити старий проект.

Якщо код основної програми розвивається і підтримується постійно, то код інфраструктури не часто потребує змін і якщо повну перевірку інфраструктури робити раз на пів року, то точно вийдуть і нові версії terraform/pulumi/terragrunt/powershell/python і якихось з модулів/провайдерів. Тож прийдеться постійно поновлювати код інфраструктури. Docker containers де всі пайплайни з перевірки та розгортання інфраструктури виконуються теж треба поновлювати.

Так ось, питання — як знайти баланс повторюванності контейнерів та процесу їх збірки, безпеки і часу зберігання у registry.

Накидайте, будь ласка, ідей з цього приводу. Бо потрібна загальна стратегія, яку треба затвердити і обгрунтувати всім учасникам процесу, бо замовник та OPS хочуть мати можливість відкотитись до будь-якої версії. Security хочуть бачити лише стабільні та безпечні образи в репозиторіях та registry, DEV, вочевидь, не мають можливості підтримувати всі виправлення у всіх версіях — та це й неможливо, бо код інфраструктури залежить від версій сторонніх апі чи утиліт.

Як це організовано у вас? Які строки зберігання? Чим обгрунтовані? Що ви обираєте — більш повторювані чи більш безпечні контейнери? Взагалі, буду вдячний за будь-які ідеї.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Security хочуть бачити лише стабільні та безпечні образи в репозиторіях та registry

Через достатню кількість часу будь-який образ стає небезпечним/нестабільним. Ви можете гарантувати безпеку лише найновішого образу. Всі, крім останнього, зберігаються лише для можливості відкату і не повинні бути сканованими знову.

Ві не стає ані більш небезпечним, ані більш нестабільним. За визначенням, бо він є незмінним. Просто вразливості стають відомими.

З цієї точки зору найновіший образ — не більш безпечний. Просто ви не знаєте ще про наявні вразливості.

Правильно. Це вам і потрібно донести команді безпеки)
Єдині гарантії — в образі, який ви зараз готуєте і ще не поклали в реєстр (це і мав на увазі під «найновіший») інструменти, які погодять команда безпеки, не знайдуть вразливостей.

Любая стратегия начинается с бюджетов. Например — если надо иметь откат, то придется держать снимки (релизы) всех версий пакетов которые использованы для билдов. Есть ли на это бюджет?

Бюджет доволі великий. Тобто він є, але питання безпеки важливіше.
З іншого боку, бюджет на кількість співробітників дає більші обмеження, бо це ж все треба підтримувати... Але і співробітників там не одиниці. За кількість співробітників можна поторгуватись. Але треба обгрунтування.

security хочуть щоб «червоних міток в пайплайнах перевірок не було взагалі». Але це малореально.

Це не один проект, а багато. Є такі проекти що задеплоїли інфру — і далі програмісти самі щось роблять, може раз на рік щось додати-підправити, а є такі що кожен день то передеплой, то копію, то зміни в архітектурі.

security хочуть щоб «червоних міток в пайплайнах перевірок не було взагалі». Але це малореально.

Вполне реально. В классических банках например — именно так.

тоді або дуже невеличка «історія відкатів», або дуже велика команда підтримки.
Якщо є інформація, чим керуються в обмеженні «історії відкатів» чи строку підтримки — буде цікаво почути аргументи.

За последние 3 года — срок исковой давности, чтоб в случае чего — показать судэкспертизе что и как было.

За деякими злочинами немає строку давнини.. ;)

Если тебя в таких обвинят — то никакие логи и точки возврата не помогут.

А ось це вже від бюджету залежить... ;)
І трохи везіння ;)

І, доречі, в банках я не працював, але працював з ними зі сторони — там паранойя і бюрократія та ще...

І ідіотизм «безпечників» — «якщо я чогось не розумію, то це працювати не буде», а не розуміють вони багато... Тут теж ані доводів, ані стратегій, просто «не повинно бути червоних міток» — як це забезпечити і як повʼязана конкретна «червона мітка» з конкретною загрозою — розуміння немає. Наприклад, сканер бачить проблему в сторонній бібліотеці, але ця, проблемна, функція з цієї бібліотеки не експортується і не використовується — тобто, проблеми немає, як такої, але — раз сканер знайшов — то проблема. Той факт, що сканер не знайшов у новому образі — це ще не означає, що там нічого немає (просто ще не знайшли, чи не занесли в БД сканера проблему) — теж не сприймається достатньо (тобто — «краще за все поновити на останні версії, бо там нічого немає, ніж на попередні з однією не пріоритетною вразливістю»)...

І ще раз: з одного боку — треба мати попередні версії, бо це можливість відкату, але попередні версії, це старі пакети, яки не проходять перевірку безпеки. Тобто питання не в бюджеті на зберігання, а в тому чи зберігати як є, і воно «небезпечне», видаляти — але тоді не буде можливості відкату, чи підтримувати, постійно поновлюючи збережені стейти проекту — але це ресурси на підтримку.

І бажано мати загальну стратегію на всі проекти. І обгрунтування. Бо без обгрунтування бюджету не буде (як і затвердження стратегії).

І мені цікаво як все це обгрунтовують інші. Будь які ідеї, може я щось упускаю.

Да, упущена важна штука — бюджет на консалтинг :)

Встречаются два экономиста и один другого спрашивает:
— Ты понимаешь что сейчас происходит?
Второй отвечает:
— Я щас тебе всё объясню!
Первый:
— Я тебе и сам объяснить могу! Ты понимаешь что происходит или нет?

В ентерпрайзі прийнято мати свій базовий імідж, який періодично перебудовується з публічного іміджа і проходить аудит безпеки, а ось поверх цього іміджа уже збирати контейнер з аппкою (вказувати для апп-докерфайла FROM myrepo.com/ubuntu-base:latest, а в разі потреби відкату можна використати старіший тег, типу myrepo.com/ubuntu-base:1.2.3), таким чином завжди можна перезібрати конкретну апку з будь-яким базовим іміджем.

Підписатись на коментарі