Влияние контейнеров Docker на главный узел Kubernetes

В настоящее время я работаю с развертыванием Hyperledger Fabric v1.4 поверх k8s. Создаваемые контейнеры цепного кода в основном создаются контейнером, работающим в одноранговых модулях, и k8s как таковой не знает и не контролирует контейнеры цепного кода. В таком сценарии, когда есть контейнер Docker, работающий вместе с k8s, а k8s не знает конкретного контейнера докеров, возможно ли для контейнера Docker каким-либо образом получить доступ к главному API k8s и получить доступ ко всему k8s кластер следовательно?

Я намерен задать этот вопрос, чтобы выяснить, есть ли способ использовать контейнер, внешний по отношению к любым модулям в k8s, чтобы вызвать нежелательное воздействие на кластер k8s путем получения несанкционированного доступа к k8s. Контейнер цепного кода, о котором я говорил, создается с использованием доверенного образа шаблона, и единственный возможный вредоносный компонент в контейнере - это один скрипт golang, java или nodejs, предоставляемый пользователем. Итак, мой реальный вопрос: возможно ли с помощью этих пользовательских скриптов получить несанкционированный доступ к кластеру k8s? И я в первую очередь сосредотачиваюсь на службе менеджера k8s, такой как служба Azure Kubernetes.


person Community    schedule 24.06.2020    source источник


Ответы (1)


Ваш вопрос полностью изменил смысл, поэтому я постараюсь переписать ответ.

Вы должны помнить, что pod, на котором вы запускаете код, по умолчанию ограничивается только namespace, на котором он выполняется. Если бы вы не давали ему более высоких привилегий. Также код не запускается от имени пользователя root.

Вы можете прочитать о политиках безопасности Pod и Настроить контекст безопасности для модуля или контейнера.

TL; DR. Пока вы не даете ему никаких особых привилегий или прав, он должен быть справедливо сохранен для вашего кластера.

person Crou    schedule 24.06.2020
comment
Большое спасибо за подробный ответ @Crou !! Я обязательно изучу все эти ресурсы. Хотя просто продолжение. В этом вопросе я хотел выяснить, существует ли способ использовать внешний контейнер, чтобы вызвать нежелательное воздействие на кластер k8s путем получения несанкционированного доступа. Контейнер цепного кода, о котором я говорил, создается с помощью доверенного шаблона, и единственный вредоносный компонент - это один скрипт golang, java или nodejs, предоставляемый пользователем. Итак, мой реальный вопрос: возможно ли использование этих пользовательских скриптов для получения несанкционированного доступа к кластеру k8s? - person ; 24.06.2020
comment
@HardikGourisaria, я переписал ответ. Надеюсь, это предоставит более подробную информацию. - person Crou; 25.06.2020
comment
Я посмотрю @Crou. Большое спасибо, что нашли время ответить на мой вопрос. И искренние извинения за любое недоразумение. - person ; 26.06.2020
comment
На самом деле это не так. Fabric 1.4 требует доступа к фактическому демону Docker через запуск вашего модуля в привилегированном режиме, который существует за пределами пространств имен. Помимо общих мер безопасности (правильная настройка брандмауэров, проверка чейнкода), это то, что вы можете сделать, чтобы защитить себя. - person lindluni; 04.07.2020
comment
Fabric 2.0 представила внешние компоновщики, которые позволяют полностью отделить управление цепным кодом от однорангового узла и, таким образом, освободиться от требований демона докеров. Вы можете прочитать о новой модели здесь: hyperledger-fabric.readthedocs.io /en/release-2.0/ - person lindluni; 04.07.2020