Безопасность в Kubernetes: Host Level Security | OTUS
👋 Канал OTUS в Telegram!
Посты от приглашенных гостей из IT-тусовки, полезные статьи, подборки вакансий от партнеров ➞
Подробнее

Курсы

Программирование
Web-разработчик на Python Разработчик Python Разработчик на Spring Framework Разработчик Golang iOS Разработчик. Продвинутый курс v 2.0. PostgreSQL Разработчик игр на Unity React.js разработчик Архитектура и шаблоны проектирования Fullstack разработчик JavaScript Android-разработчик. Продвинутый курс Разработчик Java Разработчик Node.js Scala-разработчик Backend-разработка на Kotlin Python-разработчик. Базовый курс VOIP инженер Базы данных ReactJS/React Native-разработчик Cloud Solution Architecture CI/CD Интенсив «Оптимизация в Java»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Безопасность в Kubernetes: Host Level Security

DevOps_Deep_20.11-5020-842970.png

Продолжаем обзор выступления Дмитрия Лазаренко, руководителя PaaS-направления в Mail.Ru Cloud Solutions. В предыдущей статье мы говорили о Docker Image Security, сегодня раскроем тему очередного уровня безопасности в Kubernetes — Host Level Security.

Особенности безопасности на уровне хоста

Можно сказать, что здесь всё более-менее стандартно. Во-первых, банкам и госкомпаниями нужно использовать Hardened Operation System — то есть операционные системы, из которых вырезаны все ненужные пакеты, а настройки безопасности включены по максимуму. При этом нужно помнить, что Kubernetes может обновляться, а с ним может обновляться и операционная система — следовательно, настройки могут слететь. Также следует учесть, что в облаке можно делать обновления не патчингом операционной системы, а простой заменой Image целиком.

Во-вторых, существует базовая настройка безопасности Readonly root file system, которую мы включаем автоматом (корневая файловая система, исключающая загрузку вредоносных эксплойтов на хост-машину). Она по умолчанию доступна в: — CoreOS; — Google Container Optimized OS; — Fedora Atomic Host.

Fedora Atomic Host

Система построена на базе принципов Git: — каждое изменение в операционной системе является фактически отдельным коммитом; — любое обновление ОС = новая версия ОС; — в любой момент можно сделать полный транзакционный откат конфигурации; — в Atomic Host реализован механизм rpm-ostree.

No public IP!

Последний паттерн, который стоит обозначить, особенно, когда речь идёт о публичном облаке, — не «светите» IP-адреса ваших нод-машин (мастера, миньонов). Одно из решений заключается в том, чтобы все машины Kubernetes не содержали внешнего IP, а всегда находились в выделенной сетке. Доступ к ним лучше организовать через балансировщик, либо через специальный бастион нодов. Bastion nodes — это виртуальная машина, у которой уже есть внешний IP, например она содержит какой-либо VPN-сервер. И эта виртуалка находится в сети Kubernetes, а получить доступ к Kubernetes можно только через неё, безопасно авторизовавшись в VPN-сервере.

В следующий раз подробно обсудим очередной уровень безопасности — Container Runtime Security.

Читайте также: Безопасность в Kubernetes. Docker Image Security

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться
🎁 Дарим сертификаты на скидку!
Запишитесь на июньскую трансляцию интересного вам дня открытых дверей и участвуйте в Акции ➞