2015-10-30 3 views
3

TL; DR Kubernetes позволяет всем контейнерам получать доступ ко всем другим контейнерам всего кластера, это, по-видимому, значительно увеличивает риски безопасности. Как смягчить?Как улучшить безопасность Kubernetes, особенно inter-Pods?

В отличие от Docker, где один обычно только позволит сетевое соединение между контейнерами, которые должны взаимодействовать (через --link), каждый Pod на Kubernetes может получить доступ ко всем другим Бобы на этом кластера.

Это означает, что для стандартного Nginx + PHP/Python + MySQL/PostgreSQL, запущенного на Kubernetes, скомпрометированный Nginx сможет получить доступ к базе данных.

Люди использовали для запуска все те, что были на одной машине, но у этой машины были бы серьезные периодические обновления (больше, чем контейнеры) и SELinux/AppArmor для серьезных людей.

Можно немного снизить риски, если каждый проект (если у вас есть различные независимые веб-сайты, например) запускается каждый в своем кластере, но это кажется расточительным.

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

+0

звучит как работа для брандмауэра – hanshenrik

+0

@hanshenrik IP-адреса назначаются динамически Кубернете. Можно заставить данный IP-адрес, но это не предназначено для такого использования. Кроме того, большинство поставщиков облачных вычислений Кубернете не могут предоставить доступ к этому. – Wernight

+0

На стороне заметьте, что контейнеры Docker на одном и том же хосте могут обращаться друг к другу независимо от того, связаны ли они, если вы не запустите демон с -icc = false. –

ответ

1

В недалеком будущем мы представим элементы управления сетевой политикой в ​​Кубернете. На сегодняшний день это не интегрировано, но у нескольких поставщиков (например, Weave, Calico) есть механизмы политики, которые могут работать с Kubernetes.

+0

Я надеюсь, что это будет близко к способу 'docker-compose', в том смысле, что если не была выполнена команда' kubectl', которая говорит A ссылки на B, A не должно быть разрешено для доступа к B (например, если A имеет безопасность дефект). – Wernight

+0

@ tim-hockin, пока еще не «далекое будущее»? Было бы здорово получить обновление этого ответа и связать с любыми передовыми методами политики сети для Kubernetes. –

+0

Да. NetworkPolicy существует как бета-API, так как Kubernetes v1.3 –

1

Как говорит @ tim-hockin, мы планируем создать способ разделить сеть.

Но, ИМО, для систем с более подвижными частями (где Кубернете должен действительно светиться), я думаю, что лучше сосредоточиться на безопасности приложений.

Принимая ваш трехслойный пример, PHP-модуль должен иметь право говорить с базой данных, но Nginx pod не должен. Итак, если кто-то выясняет способ выполнения произвольной команды в модуле Nginx, они могут отправить запрос в базу данных Pod, но ее следует отклонить, поскольку она не авторизована.

Я предпочитаю подход приложений безопасности, так как:

  • Я не думаю, что --links подход будет хорошо масштабироваться до 10с различных microservices или более. Слишком сложно управлять всеми ссылками.
  • Я думаю, что по мере роста числа разработчиков в вашей организации вам понадобятся мелкозернистая безопасность на уровне приложений.

С точки зрения того, как докер композе, это выглядит как докер составляют в настоящее время работает только на отдельных машинах, в соответствии с этой страницы: https://github.com/docker/compose/blob/master/SWARM.md

+0

Я плохо понимаю проблему «масштаба». В мире Кубернеса да, это проблема, учитывая текущую конфигурацию, потому что ничто не говорит о том, что nginx ведет переговоры с php (а не MySQL) в конфигурации. В мире Docker (docker-compose and roo), однако, '--link' - это способ определения« сервисов »каким-то образом. Таким образом, не существует проблемы управления более сложной конфигурацией: если config говорит, что A разговаривает с B, система настраивает разрешенные каналы и только тогда (или так должна). Так что конфигурация - это закон. – Wernight

Смежные вопросы