Статья подготовлена для студентов курса «Инфраструктурная платформа на основе Kubernetes» в образовательном проекте OTUS.
Продолжаем обзор выступления Дмитрия Лазаренко, руководителя 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