Насколько kubectl более безопасен, чем S SH Daemon / доступ в контейнеры?

Question

Различные рекомендации по безопасности Kubernetes говорят вам избегать S SH в контейнеры и предлагают вместо этого использовать kubectl. В качестве главной причины указана возможность перехода к базовым ресурсам хоста через S SH в контейнеры. Итак, у меня есть следующие специфические c запросы:

1. Какие функции kubectl не позволяют получить доступ к ресурсам хоста и почему s sh имеет больший риск доступа к ресурсам хоста по сравнению с kubectl ? Насколько безопаснее kubectl?

2. Может ли S SH пропускать политики безопасности Pod и пути доступа / монтирования на базовом хосте, которые ограничены в политике безопасности pod?

3. Если S SH в контейнеры неизбежен, как обезопасить его наилучшим образом?

Answer 1

Только потому, что вы должны запустить сервер ssh в вашем контейнере; таким образом, дополнительный процесс, выполняющийся в вашем контейнере и должен управлять ключами, является достаточной причиной, чтобы не хотеть S SH в контейнер.

Итак, это один недостаток. Еще один будет go с вариантом использования, и это риск. Почему вы хотите S SH в контейнер? Одна причина, которую я вижу, заключается в том, что вы хотите сделать это с внешнего хоста (без установки kubectl и аутентификации по api-server). Таким образом, вы должны предоставить конечную точку внешнему миру или, по крайней мере, вашей сети.

Answer 2

Если причина в том, что «вы можете сбежать через одного, а не другого», то я думаю, что это исходит от кого-то, кто не понимает задействованных механизмов безопасности. Существуют и другие причины, по которым kubectl exec предпочтительнее S SH, такие как ведение журнала аудита, интегрированного со всем остальным Kubernetes, и простое аннулирование доступа, но их можно получить и с S SH. Это просто больше работы

1. kubectl работает на стороне клиента. Если бы в нем были функции, которые мешали бы вам сбежать, вы могли бы просто их пропатчить.

2. Нет, они находятся на модуле и обрабатываются базовым ядром. S SH даст вам только оболочку в контейнере, как kubectl exec.

3. Используйте публичные c -ключевую аутентификацию, убедитесь, что у вас есть стратегия для обеспечения Ваше программное обеспечение в контейнере обновлено. Подумайте, как вы собираетесь управлять файлом authorized_keys и отзывом там скомпрометированных ключей S SH. Подумайте, следует ли заблокировать доступ к порту, на котором запущен S SH, с помощью правил брандмауэра.