MeetupStandup/6. For administrators

6.1 Docker
    https://blog.aquasec.com/docker-security-best-practices
    - Помните, что при использовании FROM наследуются все проблемы исходного имиджа
    - Нельзя хардкодить credentials внутри имиджей - для управления такими вещами следует использовать
    соответствующие решения
    - Следует помнить, что контейнеры - это не секьюрити-решение и все контейнеры и сам демон бегут
    от рута и соответственно, есть возможность повышения привилегий и выхода за пределы контейнера
    https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/ - хорошим вариантом
    будет настройка профиля AppArmor для защиты основной системы на уровне ядра.
    - Обратите внимание на сложность и большое количество абстракций
    - Проверяйте образы, скачанные с dockerhub, не доверяйте вслепую
    - Ограничивайте доступные ресурсы для контейнеров
    - Необходимо использовать SECCOMP для ограничения доступа
    - Необходимо периодически мониторить активность конетйнеров
    - Необходимы правила менеджмента жизненных циклов контейнеров
    - Контейнеры должны находиться на отдельном разделе
    - Необходима грамотная настройка сети для контейнеров
    - legacy registry и Userland Proxy должен быть отключен
    - В случае удаленного доступа необходимо использовать TLS для демона
    - Включите логгирование на уровне хотя бы INFO
    - Делайте HEALTHCHECK в контейнере
    - Запретите setuid и setgid в образах
    - COPY более безопасный, чем ADD
    - По возможности не используйте привилегированные контейнеры
    - Настройте container restart policy
    - Используйте отдельный network namespace для контейнеров
    - Не открывайте устройства с хоста напрямую в контейнер
    - Проверьте настройки cgroups

6.2 Kubernetes
    - K8s всегда должен быт обновлен до последней версии. Новые функции безопасности - а
    не только исправления ошибок - добавляются в каждое ежеквартальное обновление, и чтобы
    воспользоваться ими, мы важно использовать последнюю стабильную версию. Самое лучшее,
    что можно сделать, - это запустить последнюю версию с самыми последними исправлениями,
    особенно в свете открытия CVE-2018-1002105. Обновление и поддержка могут становиться все
    труднее по мере усложнения архитектуры кластера и при обновления возможны остановки подов и
    падения, поэтому планируйте обновление как минимум раз в квартал. Использование Kubernetes as
    a service может сделать обновление очень простым.
    - Необходимо использовать RBAC. Контролируйте, кто может получить доступ к API Kubernetes и какие
    разрешения они имеют с помощью управления доступом на основе ролей (RBAC). RBAC обычно включается
    по умолчанию в Kubernetes 1.6 и более поздних версиях (позже для некоторых управляемых провайдеров),
    но если вы обновились с тех пор и не изменили свою конфигурацию, вам нужно будет дважды проверить
    ваши настройки. Из-за способа объединения контроллеров авторизации Kubernetes необходимо включить
    RBAC и отключить устаревшее управление доступом на основе атрибутов (ABAC). После применения RBAC вам
    все равно нужно эффективно его использовать. Как правило, следует избегать общекластерных разрешений в
    пользу разрешений, специфичных для пространства имен. Избегайте предоставления кому-либо привилегий
    администратора кластера, даже для отладки - гораздо безопаснее предоставлять доступ только по мере
    необходимости в каждом конкретном случае. Вы можете просмотреть роли и роли кластера,
    используя `kubectl get clusterrolebinding` или` kubectl get rolebinding –all-namespaces`. Если вашему
    приложению необходим доступ к API Kubernetes, создайте учетные записи служб индивидуально и предоставьте
    им наименьший набор разрешений, необходимых для каждого сайта использования. Это лучше, чем предоставление
    слишком широких разрешений учетной записи по умолчанию для пространства имен. Большинству приложений вообще
    не нужен доступ к API; Для них можно установить «false» для automountServiceAccountToken.
    - Выносите чувствительные процессы в отдельный namespace, чтобы ограничить потенциальное влияние компрометации.
    Такой подход снижает риск доступа к чувствительному приложению через менее защищенное приложение, которое совместно
    использует среду выполнения контейнера или хост. Например, учетные данные Kubelet скомпрометированного узла обычно
    могут получить доступ к содержимому секретов, только если они используются подами, бегущими на данной ноде --
    если поды с чувствительными секретами бегут на разных нодах кластера, у злоумышленника будет больше возможностей украсть их.
    - Безопасно храните данные доступа. Чувствительные метаданные, такие как учетные данные администратора kubelet,
    могут быть украдены или использованы не по назначению для повышения привилегий в кластере. Например, в недавнем
    раскрытии информации о багах Shopify подробно рассказывалось о том, как пользователь смог повысить привилегии,
    вызвав на микросервисе утечку информации из службы метаданных облачного провайдера. Функция сокрытия метаданных
    в GKE изменяет механизм развертывания кластера, чтобы избежать этого, рекомендуется использовать его до тех пор,
    пока он не будет заменен постоянным решением. Подобные контрмеры могут быть необходимы в других средах
    - Создайте и настройте Network Policies. Сетевые политики позволяют вам контролировать доступ к сети внутрь и наружу для
    ммикросервисов. Чтобы использовать их, вам необходимо убедиться, что у вас есть сетевой провайдер, который поддерживает
    этот ресурс; с некоторыми управляемыми провайдерами Kubernetes, такими как Google Kubernetes Engine (GKE), вам нужно будет
    вручную включить данную функциюю. (Для включения сетевых политик в GKE потребуется небольшое обновление,
    если кластер уже создан). После того, как это будет сделано, начните с некоторой базовой сетевые политики по
    умолчанию, например блокировка трафика из других пространств имен по умолчанию.
    - Задайте Pod Security Policy для всего кластера. PSP устанавливает стандартные значения для микросервисов в кластере.
    Подумайте об определении политики и включении Pod Security Policy - инструкции могут отличаться в зависимости от
    вашего облачного провайдера или модели развертывания. Для начала можно отключить NET_RAW, чтобы заблокировать
    определенные классы сетевых спуфинговых атак.
    - Повысьте безопасность нод. Ограничте доступ к чувствительным портам, ткаим кака 10250 и 10255, минимизируйте
    доступ к машинам.
    - Включите журнал аудита. Многие облачные провайдеры предоставляют возможность настройк алертов при неудачных
    попытках входа, желательно их влючить.
    - Проведите бенчмарк. https://www.cisecurity.org/benchmark/kubernetes/
    - Даже если вы не используете Rancher, почитайте инструкцию по харденингу https://rancher.com/docs/rancher/v2.x/en/security/hardening-2.2/
    и бенчмаркингу https://releases.rancher.com/documents/security/latest/Rancher_Benchmark_Assessment.pdf