Телеграмм чат группы devsecops

Size: a a a

DevSecOps - русскоговорящее сообщество

2019 February 12

Сергей in DevSecOps - русскоговорящее сообщество

This attack is only possible with privileged containers since it requires root
privilege on the host to overwrite the runC binary. Unprivileged containers
with a non-identity ID mapping do not have the permission to write to the host
binary and therefore are unaffected by this attack.

источник

10:40пожаловаться #1

Сергей in DevSecOps - русскоговорящее сообщество

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

источник

10:41пожаловаться #2

Andrey Abakumov in DevSecOps - русскоговорящее сообщество

не дефолтный

источник

10:41пожаловаться #3

Andrey Abakumov in DevSecOps - русскоговорящее сообщество

уязвимость не так опасна

источник

10:41пожаловаться #4

buggy c0d3r in DevSecOps - русскоговорящее сообщество

Andrey Abakumov

уязвимость не так опасна

Но и забивать не стоит. Думаю найдется те, у кого внетри сервис бегает с UID 0

источник

10:51пожаловаться #5

buggy c0d3r in DevSecOps - русскоговорящее сообщество

Я часто встречаю отношение к Докеру и Куберу, как к панацее "Все же изолировано, типо"

источник

10:51пожаловаться #6

buggy c0d3r in DevSecOps - русскоговорящее сообщество

И если на проде еще как-то соблюдаются нормальные практики, то на тесте или стейджинге иногда просто адовый цирк с конями происходит

источник

10:53пожаловаться #7

Roman Rusakov in DevSecOps - русскоговорящее сообщество

поясните ломаку как злонамереный контейнер попасть должен на хост?

источник

15:12пожаловаться #8

buggy c0d3r in DevSecOps - русскоговорящее сообщество

вы утянули с публичной репы чью-то убогую сборку, например

источник

15:18пожаловаться #9

Roman Rusakov in DevSecOps - русскоговорящее сообщество

ясно

источник

15:19пожаловаться #10

buggy c0d3r in DevSecOps - русскоговорящее сообщество

https://hub.docker.com/r/chrisfosterelli/rootplease/

источник

15:21пожаловаться #11

buggy c0d3r in DevSecOps - русскоговорящее сообщество

Вообще здесь где-то была ссылка на выступление про типовые атаки на Докер

источник

15:22пожаловаться #12

Konstantin Sverdlov in DevSecOps - русскоговорящее сообщество

buggy c0d3r

Все уже обновились?

сегодня ночью на centos прилетел этот апдейт и после установки контейнеры не смогли запуститься (в docker-compose прописано restart: always). Ошибок разных в логе полно. После ребута сервака тоже не сразу запустились, сначала была ошибка ”Cannot start service <имя сервиса>: id already in use”. Но после некоторой паузы однако контейнеры поднялись. Docker пока только начинаем использовать, набиваем шишки. Пора уже отключить автоматическую установку апдейтов на docker

источник

15:59пожаловаться #13

buggy c0d3r in DevSecOps - русскоговорящее сообщество

Konstantin Sverdlov

Возможно вам вто это поможет https://t.me/devopslibrary/238

DevOps&SRE Library

Отличная серия постов в блоге компании Gruntwork про некоторые важные аспекты обслуживания кластеров Kubernetes.

Zero Downtime Server Updates For Your Kubernetes Cluster:
https://blog.gruntwork.io/zero-downtime-server-updates-for-your-kubernetes-cluster-902009df5b33

Gracefully Shutting Down Pods in a Kubernetes Cluster:
https://blog.gruntwork.io/gracefully-shutting-down-pods-in-a-kubernetes-cluster-328aecec90d

Delaying Shutdown to Wait for Pod Deletion Propagation:
https://blog.gruntwork.io/delaying-shutdown-to-wait-for-pod-deletion-propagation-445f779a8304

Avoiding Outages in your Kubernetes Cluster using PodDisruptionBudgets:
https://blog.gruntwork.io/avoiding-outages-in-your-kubernetes-cluster-using-poddisruptionbudgets-ef6a4baa5085

источник

17:28пожаловаться #14

Roman Rusakov in DevSecOps - русскоговорящее сообщество

народ я знаю у кого то есть уже

источник