☸️ Изучаем Kubernetes: 5 лучших практик безопасности |

Если вы не будете следовать этим рекомендациям по безопасности развертывания Kubernetes, ваши контейнеры, лежащие в их основе технологии и ваши данные могут оказаться под угрозой.

Любой, кто следил за Kubernetes и контейнерами за последние несколько лет, знает, что безопасность стала центральной точкой отказа для этой технологии.

Проблемы безопасности могут возникать практически из любой точки – от образов контейнеров, механизмов исполнения, плохо защищенных сетей и т. д.

Поэтому для любого бизнеса, стремящегося принять контейнерную технологию, важность безопасности нельзя переоценить.

Недавно компания Portshift выпустила список лучших практик для решения проблем безопасности, связанных с платформой K8s.

Давайте посмотрим на эти советы по безопасности.

Содержание

1. Авторизация
2. Политики безопасности подов
3. Защищать производственную среду
4. Защита пайплайнов CI / CD
5. Добавьте service mesh как дополнительный уровень безопасности сети

1. Авторизация

Авторизация, пожалуй, одна из самых недооцененных проблем в Kubernetes.

Почему?

Это не всегда просто преодолеть, потому что вам приходится иметь дело с авторизацией на нескольких уровнях.

Учтите это: у вас есть авторизация из образов, файлов конфигурации, сторонних приложений и сервисов, различных разработчиков и / или пользователей … список возможных авторизаций можно продолжать и продолжать.

Вот почему прваа в Kubernetes обрабатываются с помощью управления доступом на основе ролей (RBAC).

Этот механизм дает вам мощный, детальный контроль над авторизацией и доступом.

RBAC API объявляет четыре типа верхнего уровня:

Role может использоваться только для предоставления доступа к ресурсам в одном пространстве имен;
ClusterRole добавляет ресурсы области кластера, конечные точки, не связанные с ресурсами, и ресурсы пространства имен по типу роли;
RoleBinding предоставляет разрешения, определенные в Role, пользователю или группе пользователей;
ClusterRoleBinding – то же самое, что и RoleBinding, но для всего кластера.

Крайне важно, чтобы каждый администратор K8 понимал авторизацию RBAC.

Для получения дополнительной информации обязательно ознакомьтесь с официальной документацией RBAC.

Список лучших практик Portshift также включает метод авторизации RBAC, но предупреждает, что он включает несколько операционных ограничений.

2. Политики безопасности подов

Следующая лучшая практика – безопасность пода.

Под – это объект, который содержит набор из одного или нескольких контейнеров.

Согласно рекомендациям Portshift, «важно контролировать конфигурации развертывания. Политики безопасности пода Kubernetes – это ресурсы уровня кластера, которые позволяют пользователям безопасно развертывать свои поды, контролируя их привилегии, доступ к томам и классические параметры безопасности Linux, такие как seccomp и профили SELinux. “

Примечание. Политика безопасности пода контролирует важные аспекты спецификации. Объект PodSecurityPolicy определяет набор условий, которые должен выполнить pod, чтобы быть принятым в систему; если пк не может достичь такого состояния, он не будет принят. Политики безопасности Pod позволяют администратору контролировать такие вещи как:

Запуск привилегированных контейнеров
Использование пространств имен хоста
Использование типа томов
Использование файловой системы хоста
Требование использования доступной только для чтения корневой файловой системы
Идентификаторы контейнера пользователя и группы
Ограничить эскалацию привилегиями root

Это довольно чувствительные аспекты ваших подов, и вам нужно внимательно следить не только за тем, как вы устанавливаете свои политики безопасности для них, но и у кого есть к ним доступ.

3. Защищать производственную среду

Безопасность вашего развертывания в Kubernetes настолько же надежна, насколько и производственная среда, в которой оно развернуто; это должно быть само собой разумеющимся, но это упускается из виду.

Portshift говорит об этой проблеме:

По мере того, как компании перемещают все больше развертываний в производство, эта миграция увеличивает объем уязвимых рабочих нагрузок во время их выполнения. Эту проблему можно решить, применяя описанные выше решения, а также следя за тем, чтобы ваша организация поддерживала здоровую культуру DevOps / DevSecOps

Ваша производственная среда должна быть безопасной.

Начиная с ваших сетей до среды разработки, включая ноутбуки разработчиков, серверы и, как указывал Portshift состоит ваша культура DevOps.

Если ваши разработчики не работают в защищенной среде, вероятность того, что ваши развертывания в Kubernetes могут быть скомпрометированы, возрастет.

4. Защита пайплайнов CI / CD

Непрерывная интеграция / непрерывная доставка (CI / CD) позволяет выполнять предварительные развертывания, тестирование и развертывание рабочих нагрузок; это также позволяет автоматизировать многие задачи развертывания.

Чтобы реализовать это, вы будете использовать ряд сторонних инструментов, таких как Helm и Flagger.

Чтобы ваши развертывания в Kubernetes обладали даже минимальным уровнем безопасности, вы должны заблокировать все в своих конвейерах CI / CD.

Вы обязательно должны применять строгие меры безопасности в этом пайплайне и каждой части программного обеспечения или службы, которая к нему относится; в противном случае, согласно Portshift, «злоумышленники могут получить доступ, когда эти образы развернуты, и использовать эти уязвимости в производственных средах K8. Проверка кода образов и конфигураций развертывания на этапе CI / CD может решить эту проблему».

Именно эта часть Kubernetes может нарушить требования безопасности.

☸️ Учебное пособие по Ingress для начинающих в Kubernetes

Если вы не уверены в том, как определенный инструмент обращается к вашему пайплайну CI/CD и как он обрабатывает такие вещи, как авторизация, узнайте все, что только можно узнать об этом.

Единственная точка отказа в вашем пайплайне CI / CD может иметь катастрофические последствия для безопасности ваших развертываний в Kubernetes в целом. включая рабочие стацни разработчиков, серверы и, как указал Portshift, вашу культуру DevOps.

5. Добавьте service mesh как дополнительный уровень безопасности сети

Безопасность сети имеет решающее значение для ваших сущностей в Kubernetes и не должна быть упущена из виду.

service mesh повышает безопасность сети, добавляя выделенный уровень инфраструктуры, чтобы упростить обмен данными между сервисами между микро-сервисами и сбалансировать межсервисный трафик на основе определенных политик.

На этот вопрос Portshift говорит так:

«service mesh также предлагает ряд преимуществ безопасности, надежности и контроля, которые могут помочь управлять кластерным трафиком и повысить стабильность сети, что улучшается моделью безопасности с нулевым доверием».

В настоящее время Istio – ваш лучший выбор инструента service mesh .

☸️ Что такое Kubernetes Service Mesh и Istio

Istio помогает вам интеллектуально контролировать поток трафика и вызовов API между сервисами, автоматически защищать ваши сервисы с помощью управляемой авторизации, применять политики и наблюдать за происходящим с помощью автоматической трассировки, мониторинга и ведения журналов.

Это еще один слой, который вы добавляете в уже сложную структуру, поэтому, прежде чем использовать Istio, убедитесь, что вы понимаете его.

см. также: