Вивчаємо (відсутню) безпеку типових установок Docker та Kubernetes

Вивчаємо (відсутню) безпеку типових установок Docker та Kubernetes
Я працюю в IT понад 20 років, але якось руки не доходили до контейнерів. Теоретично я розумів, як вони влаштовані і як працюють. Але оскільки я ніколи з ними не стикався на практиці — я не був упевнений у тому, як саме крутяться-крутяться у них шестерні під капотом.

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

Для швидкого старту я записався на курси Black Hat 2020 під назвою «З бруду в князі: проникнення та захист оточень Docker Swarm та Kubernetes».

Курс, який проводили Sheila A. Berta та Sol Ozzan, відразу ж почався з опису того, як працюють контейнери Docker, а також який шлях вони проходять при розгортанні Kubernetes. Це було повністю практичне заняття — студенти мали попередньо перед заняттями встановити Docker і microk8s на свої машини — чудовий спосіб побачити взаємодію інструментів між собою, знайти слабкі місця і, що найважливіше, спробувати їх блокувати.

На жаль хоч курси і обіцяли стати «князем» через два дні, я відчував, що все тільки починається, і мені ще доведеться багато чого навчитися.

Вивчаємо (відсутню) безпеку типових установок Docker та Kubernetes

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

Нижче наведено деякі мої висновки з погляду червоної та синьої команди.

Червона команда

Більшість вмісту контейнерів запускається під root: це означає, що якщо компрометувати контейнер, ви отримаєте повний доступ до контейнера. Це робить наступні кроки значно легшими.

Встановлення docker.sock всередині контейнера небезпечнеЯкщо ви отримали root всередині контейнера, а також встановили Docker всередині контейнера, що має сокет Docker (/var/run/docker.sock), у вас є потенційна можливість дослідження цілого кластера, включаючи доступ до будь-якого іншого контейнера. Такий доступ неможливо запобігти ні ізоляцією мереж, ні іншими способами.

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

Docker API може видати купу інформації: Docker API, при налаштуванні за замовчуванням, працює без авторизації та може видавати купу інформації. Використовуючи Shodan, можна легко знайти список відкритих портів, потім отримати детальну інформацію про кластер — і перейти до його повного захоплення. TrendMicro написали про це найцікавішу статтю.

Синя команда

Не запускайте вміст контейнерів під root: незважаючи на те, що під root запускати простіше, ви не повинні робити цього. Замість цього запускайте програми зі скинутими правами, відобразивши uid або за допомогою —user при роботі з CLI, або вказуючи USER в Dockerfile.

Не дозволяйте встановлення програм у контейнерах: майже кожна атака починається з встановлення чогось Починаючи з nmap і закінчуючи ifconfig і самим Docker (всередині контейнера), установка чогось у контейнері була звичайною справою. З цієї ж причини завжди потрібно блокувати всі порти, що не використовуються. Це також допомагає запобігти передачі керуючих команд під час зараження вашої машини. Крім запобігання інсталяції програм, варто переконатися в тому, що в самому контейнері встановлено мінімальну кількість додатків, необхідну для виконання завдання.

Захищайте docker.sock: його треба захищати, оскільки через цей сокет обробляється зв'язок між контейнером та кластером. Оскільки я не хочу вникати в деталі цієї статті, почитайте замітку від Docker, Що може статися, а також як це все заблокувати.

Використовуйте секрети Docker замість змінних оточення: Секрети є приблизно з 2017 року. Хоча це і небезпечно, але все ж таки краще, ніж змінні оточення для передачі секретних даних у контейнер.

Якщо стаття викликала у вас інтерес до контейнерів - можна досить легко встановити Docker або microk8s (невелика версія Kubernetes). Тут є інструкції зі встановлення Docker для Linux та MacOS, а тут — інструкції з встановлення microk8s для Windows, Linux та MacOS.

Після встановлення можна пройти це посібник зі швидкого старту від Docker, подібний варіант пропонується та для microk8s.

Якщо є бажання чи необхідність пройти комплексний курс з Docker, в якому спікери-практики розбирають усі його інструменти: від основних абстракцій до параметрів мережі, нюансів роботи з різними ОС та мовами програмування, то спробуйте.Відеокурс з Docker». Ви познайомитеся з технологією та зрозумієте, де і як краще використовувати Docker. А заразом отримаєте best practice кейси — краще навчатися в безпеці та за допомогою практиків на історіях про граблі, ніж особисто на самих граблях із шипованими ручками.

Джерело: habr.com

Додати коментар або відгук