логи, ты уже нить потерял?

ты даже до сих пор не понимаешь, какого рода логи

Ладно, ты победил

видимо, и не знаешь, чем их генерить

просто запусти strace всей системы, оцени

докер говно и не пройдет сертификацию PCI DSS

пиши в stdout, а лохер будет сам их перенаправлять в нужное место через драйвер логирования

Да я то знаю как такое логировать, это Вадим с голосами в голове спорит

"такое" ? ну покажи-кась

пока что ты до сих пор демонстрируешь вопиющую некомпетентность, путая BSM audit и syslog

Ты абсолютно прав

Интересная ссылка. Но, как и исходная PCI DSS, весьма неконкретная. По сути, автор просто пробежался по оригинальному документу и взял: "вот здесь требуется firewall, а я допишу container firewall". И вот догадывайся, что он имел в виду: что контейнеры могут работать только на заранее предопределённых хостовых сетях (без оверлейных и других автоматически-управляемых) с вручную настроенными файрволами? Или есть, например, какие-то k8s операторы, которые могут это обеспечить так, что бы аудиторы не придрались?

Но меня в контексте докера волнует даже не это, а пункт 8) Identify and authenticate access to system components (PCI DSS 8.1-8.8).
Если докер демон в описываемой системе работает от обычного юзера, то имеющий доступ к сокету имеет доступ к контейнерам (может запустить любую команду в контексте контейнера). В принципе, это можно митигировать как раз сборкой образов с нуля с ревью юзерспейса, как обсуждали выше, - что бы не допустить юзерспейс бинарников, через которые имеющий доступ к сокету может получить что-то из контейнера. Если же докер демон в описываемой системе работает от рута (что может понадобиться, в частности, для автоматизации управления файрволами), то дополнительно к этому сам рут может получить все нужные юзерспейс компоненты (которых у него нет в хост системе) - и получить доступ к памяти процессов. Там есть какие-то минимальные ручки, но я пока не успел их изучить.

В любом случае, КМК тут это уже офтопик, хотя я понимаю, что тема интересна многим - как раз из-за того, что системные версии perl  из дистрибутивов часто нам не подходят...

> из-за того, что системные версии perl  из дистрибутивов часто нам не подходят

разве нам perlbrew не решает эту проблему без всяких б-гомерзких докеров?

Решает, но не в контексте вот таких ответственных окружений. Ты же не можешь там даже банальный gcc установить (для снижения поверхности потенциальной атаки). Ну а вот мой подход, которым я поделился выше, - это, по сути тот же perlbrew (а точнее, perl-build), но с пакетированием его выхлопа в виде пакетов дистрибутива.

ну пакеты - нормальный, классический подход

помню, в Деньги.Mail.Ru именно так и делали, и программистов на прод ессно не пускали, тем более докерами

Как связаны перл и ответственное окружение?

А зачем там gcc? Один раз собрал и копируй на сервера спокойно. Хотя тут уже начинают рулить пакеты :)

П. 8 емнип о авторизации доступа к компонентам системы, по системой имеется в виду сертифицируемый ПАК. Обычно достаточно какого-нибудь SSO и сервис-аккаунтов в нём

А не вот это всё, с доступом локальных юзеров к сокетам.

Не так страшен аудит, как тут напридумывали.

Есть ли отличия между этим?

my $q = new CGI;
my $q = CGI->new;

Или под капотом это одно и тоже просто разный синтаксис?