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

Безопасность в 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 комментариев
Для комментирования необходимо авторизоваться
Популярное
Сегодня тут пусто