Занятие №2

План:

1. Напомнить какие проблемы были рассмотрены на прошлом занятии
2. OWASP Top 10
3. Рассказать про плагины kubernetes
4. Рассказать о Policy Engines, сделать сравнительную характеристику.
5. Выбрать один из Engine и написать policy под уязвимые контейнеры.

## Рекап прошлого занятия

На занятии затрагивались:
- темы общих namespaces
- темы связанные с эксплойтами ядра
- темы связанные с доступом к API (Hot Pods)

## Проблемы безопасности k8s

Пример набор технологий, которые работают для обеспечения изоляции и безопасности:

https://owasp.org/www-project-kubernetes-top-ten/

Для k8s существует набор рисков, которые могут реализоваться за счет уязвимостей, которые находятся в 10ти категориях. Последний раз категории были пересмотрены в 2022 году. Описание и сам проект еще находится на этапе описания, поэтому можно заимствовать только данные, которые уже успели внести в список.

- [K01: Insecure Workload Configurations](https://owasp.org/www-project-kubernetes-top-ten/2022/en/src/K01-insecure-workload-configurations)
- [K02: Supply Chain Vulnerabilities](https://owasp.org/www-project-kubernetes-top-ten/2022/en/src/K02-supply-chain-vulnerabilities)
- [K03: Overly Permissive RBAC Configurations](https://owasp.org/www-project-kubernetes-top-ten/2022/en/src/K03-overly-permissive-rbac)
- [K04: Lack of Centralized Policy Enforcement](https://owasp.org/www-project-kubernetes-top-ten/2022/en/src/K04-policy-enforcement)
- [K05: Inadequate Logging and Monitoring](https://owasp.org/www-project-kubernetes-top-ten/2022/en/src/K05-inadequate-logging)
- [K06: Broken Authentication Mechanisms](https://owasp.org/www-project-kubernetes-top-ten/2022/en/src/K06-broken-authentication)
- [K07: Missing Network Segmentation Controls](https://owasp.org/www-project-kubernetes-top-ten/2022/en/src/K07-network-segmentation)
- [K08: Secrets Management Failures](https://owasp.org/www-project-kubernetes-top-ten/2022/en/src/K08-secrets-management)
- [K09: Misconfigured Cluster Components](https://owasp.org/www-project-kubernetes-top-ten/2022/en/src/K09-misconfigured-cluster-components)
- [K10: Outdated and Vulnerable Kubernetes Components](https://owasp.org/www-project-kubernetes-top-ten/2022/en/src/K10-vulnerable-components)

## Insecure Workload Configurations

Раздел, который вбирает в себя основные постулаты безопасности контейнеров любой среды.

Нельзя:
- запускать контейнер с рутом внутри
- запускать privileged контейнер
- давать полный доступ к файловой системе (по возможности использовать только fs для чтения)

## Supply Chain Attacks

Наиболее актуальный вектор для компрометации инфры с большим количество компонентов.

Как можно предотвратить:

- использовать Image integrity
- SBOM файлы
- Image Signing
- Image Composition
- Known Vulnerabilities
- Enforcing Policy
- не загружать:
- не просканированные image на уязвимости
- использовать запрещенные image не из доверенного хранилища/списка
- image, которые не содержат подтвержденные SBOM
- image, который располагается на недоверенном хранилище

## Overly permissive RBAC

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

Примеры:
- ClusterRoleBinding - дает возможность работать с правами cluster-admin.

Что можно сделать, чтобы предотвратить:

- Предотвратить полностью или ограничить прямой доступ к кластеру
- Не использовать Service Account Tokens за пределами кластера
- Избегать автоматического монтирования с дефолтными токенами сервис аккаунтов
- проводить проверку RBAC, которые включены в сторонние компоненты
- Использовать общие политики для детектирования и блокирования RBAC привелегии
- Использовать RoleBindings, чтобы уменьшить область применения привилегий в конкретном namespace или во всем кластере
- Следовать официальному набору практик [RBAC Good Practices](https://kubernetes.io/docs/concepts/security/rbac-good-practices/) в Kubernetes доках

## Lack of centralised Policy Enforcement

Так как k8s может использоваться для управления несколькими кластерами, то применение политики обязательно для всех. Однако, если будет пропущен хотя бы один кластер, то существует риск, что злоумышленник сможет подгрузить image из недоверенного реестра.

Исправление:
- пользоваться https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
- применять https://kubernetes.io/docs/concepts/security/pod-security-admission/
- использовать сторонний policy engine

## Inadequate Logging and Monitoring

Возникает если:
- эвенты, которые включают неудачные попытки аутентификации, доступ к секретным хранилищам, ручное удаление или модификация ресурсов не логируются
- Логи и трассировки не мониторятся на предмет подозрительной активности
- Пороги срабатывания алертов подобраны неверно
- Логи не сохраняются централизовано и не защищенно
- Система логирования отключена

Вообщем-то для функциональности кластеров это не играет роли. Но вот если произойдет инцидент - расследовать и предотвращать последствия будет в разы сложнее. Потому что если бы было, то инцидент можно было нейтрализовать еще в процессе реализации.

## Broken Authentication Mechanism

В Kubernetes можно использовать большое количество вариаций для аутентификации. Разделить аутентификацию можно на 2 части:

1. Аутентификация для пользователей
2. Аутентификация для сервисных учёток

Для первой группы:
- OIDC
- Certificates
- cloud IAM
- Service Account Tokens

Для второй группы:

- механизмы токенов - используется базовый вариант, который встроен в k8s

Как использовать каждый:

1. Избегать использования сертификатов как основного метода аутентификации. В k8s нет возможности отзывать и менять сертификаты. Поэтому в случае компрометации утекший серт становится практически вечным вариантом доступа в инфру.
2. Не создавать собственные механизмы аутентификации
3. Где возможно использовать 2й фактор
4. Не использовать сервисные аккаунты за пределами кластеров
5. Ограничивать срок действия токенов для пользователей (сервисные учетки имеют токены без лимита)

## Missing Network Segmentation Controls


k8s сеть плоская, поэтому проблемы контроля сетевого трафика являются достаточно актуальными. Что может в таком случае делать злоумышленник? Использовать маршрутизацию и функции сети для того чтобы атаковать остальные части кластера или запускать доступы в зависимости от доверия пользователям в отдельных частях системы.

Как можно решить проблемы:

1. Каждый раз запускать новый кластер, если системы не должны организовывать доступ друг к другу (**_Multi-Cluster_**)
2. Нативные политики. В k8s работают как файрволл и даюют возможность регламентировать какой pod куда может коннектиться. Если это не прописано в конфиге, то все pod могут обращаться друг к другу без ограничений (**_NetworkPolicies_**)
3. Использование CNI (Control Network Interface) - набор библиотек и плагинов для настройки доступа к сети. Применяется на уровне контейнеров
4. Использование Service Mesh - такие функции предлагают сторонние решения. У них есть кастомные правила мониторинга и работы сетью.

## Secrets Management Failures


Secret это отдельный объект в k8s, который может быть использован для доступа к различному функционалу как в самом k8s так и сервисы, которые хостятся внутри.

Главное хранилище k8s - etcd, он хранит информацию о всех конфигурациях. Поэтому даже доступ на чтение дает практически неограниченные возможности в последствии. Начиная с версии k8s 1.13 для бекапов и данных в etcd используется шифрование.

Чтобы предотвратить проблемы. Можно использовать сторонние сервисы для хранения секретов. Для примера - Vault.

## Misconfigured Cluster Component


Проблемы могут встретиться везде, так как в k8s очень много опций и настроек, поэтому ошибиться достаточно просто.

Где могут возникать проблемы:

- **kubelet** - агент, который работает в каждой ноде, для него могкт быть заданы параметры аутентификации, транспорт для сетевого взаимодействия и анонимный доступ
- **etcd** - база данных, котора сохраняет всё в виде - ключ:значение. Хранит данные по всем кластерам. Поэтому любой доступ сюда нужно ограничивать, если это возможно
- **kube-apiserver** - фронтенд для API, главная мисконфигурация тут это доступ из интернета. Так как фронтенд предназначен для управления и там достаточно часто находятся уязвимости.
-

Общие определения насчет того как должны работать микросервисы - https://kubernetes.io/blog/2023/01/20/security-behavior-analysis/

Матрица угроз - https://microsoft.github.io/Threat-Matrix-for-Kubernetes/
Набор материалов по уязвимостям - https://www.container-security.site

## Про плагины kubernetes

https://sysdig.com/blog/top-15-kubectl-plugins-for-security-engineers/

Плагин для k8s это дополнительная команда в оснастке kubectl. Позволяет автоматизировать постоянные операции или добавляет дополнительные функции.

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

Есть перечень плагинов, которые считаются наиболее полезными, разумеется, это не полный список:

- Stern plugin
- RBAC-tool
- Cilium Plugin
- Kube Policy Advisor
- Kubectl-ssm-secret
- Kubelogin
- Kubectl-whisper-secret
- Kubectl-capture
- Kubectl-trace
- Access-matrix
- Rolesumnager
- np-viewer
- ksniff
- Inspektor-Gadget

Все плагины можно менеджерить через менеджер плагинов, который сам ставится как плагин. Например - https://krew.sigs.k8s.io

На самом деле у менеджера плагинов есть 217 плагинов, которые он может предоставить.

ВАЖНО: Все плагины не проходят аудита, поэтому нужно внимательно изучать плагин перед тем как использовать.

## Security Contexts

Понятие в k8s, которое подразумевает, к какому именно объекту будут работать те или иные настройки. Если не задается явно, то k8S работает по правилам:

- настройка для Pod работает для всех его контейнеров
- настройка для контейнера может работать вне зависимости конфигураций pod

Примеры:


## Про митигации

https://www.chainguard.dev/unchained/introducing-wolfi-the-first-linux-un-distro - проект для создания дистролез
distroles создание - https://www.chainguard.dev/unchained/minimal-container-images-towards-a-more-secure-future

https://kubernetes.io/docs/reference/access-authn-authz/authentication/