Как я сдавал 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$. Я купил курс и экзамен вместе за 199$ на традиционной Cyber Monday распродаже от 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, то исправление манифестов не представляет большого труда. Нужно только помнить о том, что если после исправление манифеста, компонент, например kube-apiserver, в течение минуты не запускается, то нужно идти и смотреть логи (/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 (PSP). Нужно помнить, что PSP в большинстве случаев носит запрещающий характер, т.е. может отклонять поды с небезопасными настройками, но также иногда может вносить изменения в настройки подов, например принудительно запускать поды с AppArmor профилями и управлять дефолтными настройками securityContext, например defaultAllowPrivilegeEscalation и defaultAddCapabilities.
      Помимо этого, чтобы воспользоваться PodSecurityPolicy нужно дать соответствующему сервисаккаунту право use на эту PSP через роль. Очень легко об этом забыть на экзамене.

    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.

    Комментарии 13

      0

      Вот бы найти, если такой существует, список экзаменов и сертификаций по "всему этому IT". В том числе и как эти, CKA и CKS, а также Оракловые по Java и т.п.

        +1

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

          0
          по инфобезу есть достаточно хороший роадмап

          pauljerimy.com/security-certification-roadmap
          0

          Как справлялись с тормозами web терминала? Я, помню, тратил до 10% времени на навигацию и исправление опечаток, даже с учетом, что с vim «на ты».

            0
            Терминал слегка подтормаживал, но не критично. Больше всего заставило понервничать то, что терминал отказался грузиться в Хроме и пришлось срочно по совету проктора ставить Вивальди и логиниться в экзамен уже в нем. К счастью, время экзамена начало тикать только когда загрузился терминал.
              0
              Я сдавал в хроме, все было нормально.
            +2
            По поводу курсов от Linux Foundation. Года 3 назад я сдал LfCS на 96% в рамках очень интересного предложения от MS (сертификация по Azure и Linux). Готовился по сторонним ресурсам. Потом на Black Friday тоже купил комплект экзамен+курс LFCE за гуманную цену и был глубочайше разочарован качеством курса. Курс был ни о чем и даже близко не соответствовал реальному экзамену. Проблема была еще в том, что они как раз недавно поменяли содержимое, добавив туда кучу докера (с ним у меня не было проблем), LXC в особо нестандартных формах (я таких извращений никогда не встречал в реальной жизни) и кучу HA-proxy и иже с ним. В итоге я готовился по немного устаревшим курсам Linux Foundation, но всё равно успешно всё завалил, что достаточно честно) Всё же уровень экзамена достаточно высок и для его сдачи ты должен открыть глаз утром и на память починить упавший ha-proxy или иной другой просто по описанию «где-то там есть какой-то прокси, он вроде сломался, но непонятно где и как».Такого опыта у меня не было, а курсы его тогда не покрывали… Я набрал в итоге около 47% ибо потратил кучу времени просто на то, чтобы в командах lxc указывать его нестандартные расположения. На хосте крутилось 2 инстанса, обычный без машин и хитро раскиданный по фс. К этому меня жизнь не готовила)
              +1
              Экзамены у LF интереснее их курсов, это факт.
              0

              Спасибо, очень полезно. Особенно спасибо за ссылку на курс Udemy. А вы к CKA готовились по курсу Linux Foundation или какой-то другой курс покупали?

                0
                К CKA я, можно сказать, не готовился, кубера на работе с головой хватает. Курс от LF просмотрел, но не увидел в нем ничего полезного для себя. Так себе курс, мягко говоря.
                  +1
                  Для CKA и CKAD я купил с Udemy курсы от Mumshad Mannambeth (кстати до 27 янв. можно купить за 13 евро каждый)
                  www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests
                  www.udemy.com/course/certified-kubernetes-application-developer

                  плюс есть тестовые экзамены. Качество достаточно хорошее.
                    0
                    Спасибо, по отзывам вроде гуд
                      0

                      хорошие курсы от Мумшада! Рекомендую!
                      Удивлен, что они все еще на скидке

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

                Самое читаемое