...

суббота, 23 января 2021 г.

Как я сдавал Certified Kubernetes Security

Всем привет.

Хочу поделиться своим опытом успешной сдачи экзамена Certified Kubernetes Security (CKS) от Linux Foundation. Данный экзамен, как нетрудно догадаться, проверяет наши способности настраивать различные аспекты безопасности кластера Kubernetes и приложений, работающих в нем. Экзамен мне понравился, он рассматривает безопасность с различных точек зрения, а также использует очень полезные внешние инструменты, такие как Falco, Trivy, kube-bench, Open Policy Agent, gVisor и др. Сам экзамен мне показался умеренно сложным, в отличие от CKA, который больше ориентирован на новичков в Kubernetes.

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

На текущий момент существует всего два экзамена по безопасности Kubernetes - это, собственно, сам CKS, а также Red Hat Certified Specialist in Security: Containers and OpenShift, имеющий дело с безопасностью OpenShift. Эти два экзамена во многом пересекаются, однако по Опеншифту я считаю экзамен все же сложнее (его я благополучно завалил).

Экзамен отдельно стоит стоит 300$, официальный курс Kubernetes Security Fundamentals (LFS260) стоит 299$, можно купить курс и экзамен вместе за 499$. Я купил курс и экзамен вместе за 200$ на традиционной предновогодней распродаже от Linux Foundation.

Необходимым условием для сдачи CKS является наличие действующего сертификата CKA (Certified Kubernetes Administrator). Вы можете купить CKS, но не сможете назначить экзамен, пока не получите CKA. Звучит логично, поскольку экзамен CKS является гораздо более сложным чем CKA.

Но ближе к делу. Для подготовки я использовал два курса:

  1. Официальный курс от Linux Foundation: Kubernetes Security Fundamentals (LFS260). Не хочу ничего плохого говорить о Linux Foundation, но данный курс у них вышел неудачным. Нет внятного объяснения, как работает та или иная технология или фича, сначала несколько общих красивых слов о том, какая это крутая технология, а затем сразу какая-то невнятная лаба в PDF (вы что, серьезно?!), в которой также ничего толком не объясняется. Такое ощущение, что курс делали в последнюю минуту в большой спешке. Притом, что экзамен получился очень даже неплохим.

  2. Курс на Udemy за 3599 руб. Признаться, я сильно опасался покупая "кота в мешке", однако реальность превзошла все ожидания. Курс оказался не просто полезным, он полностью раскрыл все темы экзамены, смотрелся просто на одном дыхании. К курсу прилагаются также два тестовых экзамена на https://killer.sh. Это полноценные лабы очень похожие на то, что встретится на реальном экзамене, т.е. браузерный веб-терминал справа и задачи слева. Как уверяет автор курса, эти лабы являются на самом деле усложненной версией экзамена, т.е. если вы сделаете эти лабы, то экзамен вы точно сдадите. Как выяснилось, автор был совершенно прав.

Экзамен состоит из 15-20 вопросов, продолжительность экзамена ровно 2 часа т.е. в среднем 6-8 минут на каждый вопрос. Это довольно сжатые сроки. Лично я, имея много опыта с Kubernetes и просмотрев два курса и сделав два тестовых экзамена на killer.sh, уложился в 1 час 40 минут.

Проходной балл на экзамене 67%, что на мой взгляд довольно демократично. Экзамен легким не назовешь, но низкий проходной балл видимо призван сгладить этот "недостаток".

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

Теперь самое интересное - темы экзамена. Официальный список тем можно посмотреть на странице описания CKS. На всякий случай продублирую его здесь:

Список тем экзамена

Cluster Setup (10%)

  1. Use Network security policies to restrict cluster level access

  2. Use CIS benchmark to review the security configuration of Kubernetes components (etcd, kubelet, kubedns, kubeapi)

  3. Properly set up Ingress objects with security control

  4. Protect node metadata and endpoints

  5. Minimize use of, and access to, GUI elements

  6. Verify platform binaries before deploying

Cluster Hardening (15%)

  1. Restrict access to Kubernetes API

  2. Use Role Based Access Controls to minimize exposure

  3. Exercise caution in using service accounts e.g. disable defaults, minimize permissions on newly created ones

  4. Update Kubernetes frequently

System Hardening15%

  1. Minimize host OS footprint (reduce attack surface)

  2. Minimize IAM roles

  3. Minimize external access to the network

  4. Appropriately use kernel hardening tools such as AppArmor, seccomp

Minimize Microservice Vulnerabilities (20%)

  1. Setup appropriate OS level security domains e.g. using PSP, OPA, security contexts

  2. Manage Kubernetes secrets

  3. Use container runtime sandboxes in multi-tenant environments (e.g. gvisor, kata containers)

  4. Implement pod to pod encryption by use of mTLS

Supply Chain Security20%

  1. Minimize base image footprint

  2. Secure your supply chain: whitelist allowed registries, sign and validate images

  3. Use static analysis of user workloads (e.g.Kubernetes resources, Docker files)

  4. Scan images for known vulnerabilities

Monitoring, Logging and Runtime Security20%

  1. Perform behavioral analytics of syscall process and file activities at the host and container level to detect malicious activities

  2. Detect threats within physical infrastructure, apps, networks, data, users and workloads

  3. Detect all phases of attack regardless where it occurs and how it spreads

  4. Perform deep analytical investigation and identification of bad actors within environment

  5. Ensure immutability of containers at runtime

  6. Use Audit Logs to monitor access

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

Экзамен реально интересный и при подготовке я узнал много нового. Больше всего мне понравилась тулза под названием Falco от Sysdig. Эта тулза мониторит системные вызовы ядра Linux и поднимает алерты, если обнаруживает подозрительную активность. В комплекте с Falco идет множество полезных предустановленных правил, например:

  1. Запуск привилегированного контейнера или запуск контейнера с hostPID или hostNetwork

  2. Попытка контейнера примонтировать важные хостовые директории через hostPath

  3. Попытка повышения привилегий процессом в контейнере

  4. Попытка процессов читать или писать в важные системные файлы, например в каталоге /etc

  5. Попытка открыть сетевое соединение с IP-адресами не из разрешенного списка

  6. Установка пакетов в контейнере

и многие другие.

Помимо этого, Falco поддерживает мониторинг аудит логов Kubernetes, позволяя поднимать алерты в случае подозрительной активностей на уровне Kubernetes API, например:

  1. Создание привилегированного контейнера или запуск контейнера с hostPID или hostNetwork.

  2. Создание неймспейсов

  3. Запуск контейнера не из разрешенного списка имейджей

  4. Запуск подов в неймспейсе kube-system

  5. Создание ClusterRoleBinding с cluster-admin кластер ролью

и опять же многие другие.

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


Если мы хотим иметь больше контроля над изменениями в кластере Kubernetes, при этом стандартного RBAC нам недостаточно, то в курсе описывается еще один инструмент под названием Open Policy Agent (OPA). Этот инструмент позволяет отслеживать соответствие объектов в Kubernetes определенным политикам безопасности, которые описываются на языке описания политик Rego. В Kubernetes он ставится в виде validating admission webhook под названием OPA Gatekeeper. Сами политики описываются в виде Custom Resource Definition. Вот пример политики, которая требует при создании или изменении неймспейса обязательного наличия лейбла costcenter.

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        
        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-costcenter
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["costcenter"]

При попытке создания неймспейса без лейбла costcenter вылезет ошибка:

Error from server (you must provide labels: "costcenter"): error when creating "ns.yaml": admission webhook "validating-webhook.openpolicyagent.org" denied the request: you must provide labels: "costcenter"

Возможности OPA Gatekeeper постоянно расширяются, например он может работать в режиме аудита, т.е. лишь информировать об объектах Kubernetes, которые не соответствуют политике, но не запрещать их создание. Помимо этого, существует возможность переключить Gatekeeper в режим mutating webhook, т.е. автоматически приводить объекты в соответствие политике, например добавлять нужные лэйблы.

Кстати, у языка Rego есть собственный playground, в котором можно потестировать политики. Также, там есть ряд примеров политик для Kubernetes, что очень удобно.

Следующий инструмент, который показался мне полезным, это сканер уязвимостей контейнеров Trivy от Aquasecurity. В принципе, инструмент полезный, вроде как база уязвимостей у него шире, чем у того же Clair, но по большому счету все эти тулзы похожи.

Другие темы экзамена:

  1. Network Policy. Тут все довольно просто, однако нужно знать про один важный нюанс from и to селекторов. В целом проблем с сетевыми политиками возникнуть не должно.

  2. RBAC. Очень важно понимать разницу между Role и ClusterRole, RoleBinding и ClusterRoleBinding. Также надо помнить, что с ClusterRole можно создать ClusterRoleBinding, в этом случае эта роль будет действовать на всем кластере, а можно создать и простой RoleBinding, в таком случае ClusterRole будет действовать только в пределах одного неймспейса (самый частый пример, это кластерные роли admin, edit и view, которые можно давать юзерам на конкретные неймспейсы).
    В отличие от этого с Role можно создавать только RoleBinding, то есть простая роль всегда существует и ограничена неймспейсом, в котором она существует. Существование двух ролей с одним именем в двух разных неймспейсах совершенно легально, хотя вряд ли это можно назвать хорошей практикой.
    Также, очень важно понимать, для чего нужны сервисаккаунты, и как можно авторизовываться в кластере с их токеном ("Authorization: Bearer $TOKEN" и все такое).

  3. Аудит логи Kubernetes. Нужно уметь настраивать аудит логи как в связке с Falco, так и простое логирование в файл. Нужно уметь писать политику аудита, также иметь представление о флагах kube-apiserver, которые связаны с настройками аудит логов.

  4. Kube-bench. Нужно уметь пользоваться тулзой и исправлять найденные тулзой потенциальные бреши в безопасности кластера.

  5. Уметь работать с флагами запуска kube-apiserver, kube-scheduler, kube-controller-manager и kubelet. Поскольку в экзамене встречаются только кластеры, созданные с помощью kubeadm, то исправление манифестов не представляет большого труда. Нужно только помнить о том, что если после исправление манифеста, компонент в течение минуты не запускается, то нужно идти и смотреть логи (/var/log/pods/*), т.к. скорее всего допущена опечатка или ошибка в манифесте.

  6. Апгрейд kubeadm кластера.

  7. Статический анализ безопасности YAML-манифестов Kubernetes и Докерфайлов. Здесь нужно просто смотреть глазами и находить потенциально небезопасные участки кода, например запуск контейнера от рута, использование секретов, излишние привилегии и др.

  8. TLS-enabled Ingress.

  9. ImagePolicyWebhook.

  10. AppArmor. Нужно уметь включить профиль AppArmor на ноде и запустить под с данным профилем. Писать профили с нуля уметь не нужно (фух!)

  11. Seccomp. Требование те же, что и с AppArmor.

  12. Запускать поды с альтернативными RuntimeClass, типа gVisor. Знать, как их устанавливать, не нужно.

  13. PodSecurityPolicy. Нужно помнить, что PodSecurityPolicy частично носит запрещающий характер, т.е. может отклонять поды с небезопасными настройками, но также частично может вносить изменения в настройки подов, например принудительно запускать поды с AppArmor профилями и управлять дефолтными настройками, например defaultAllowPrivilegeEscalation и defaultAddCapabilities.

  14. Kubernetes Dashboard. Полезно изучить флаги запуска Kubernetes Dashboard, которые имеют отношение к безопасности, например режим авторизации в дашборде.

Во время экзамена можно открывать одну и только одну дополнительную вкладку браузера с документацией (кстати, у меня экзамен не запустился на Chrome, пришлось установить Vivaldi). Разрешены следующие ресурсы:

  1. https://kubernetes.io/docs

  2. https://github.com/kubernetes

  3. https://kubernetes.io/blog

  4. https://github.com/aquasecurity/trivy

  5. https://docs.sysdig.com

  6. https://falco.org/docs

  7. https://gitlab.com/apparmor/apparmor/-/wikis/Documentation

В принципе, этих ресурсов более чем достаточно. Большая часть всего необходимого всегда находится на https://kubernetes.io/docs.

Надеюсь, статья была полезной и поможет вам успешно получить сертификат Certified Kubernetes Security.

Let's block ads! (Why?)

на
Ярлыки: ,

Комментариев нет:

Отправить комментарий

Подписаться на: Комментарии к сообщению (Atom)