Як захистити кластер. Kubernetes і безпека контейнерів

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Із кожним роком популярність Kubernetes і безпека аплікацій та контейнерів зростає дедалі швидше. Аби створити кращу інфраструктуру, ви можете використовувати такі речі, як сканування, обмеження доступу, налаштування мережі, поліпшення безпеки та сканування свого кластера на наявність потенційних вразливостей. У цій статті розглянемо загальні принципи роботи з Kubernetes, контейнери та безпеку, а також способи, які допоможуть захистити ваш кластер.

Мене звати Володимир Шинкар, я DevOps Engineering lead в Intellias, маю вісім років комерційного досвіду роботи. Протягом цього часу я успішно переносив, запускав та консультував понад 15 проєктів у різних сферах. Зараз беру активну участь у Center of Excellence та Technology Office в Intellias.

Отже, сьогодні поговоримо про наступне:

• Сканування контейнерів та подів на наявність вразливостей або неправильних конфігурацій.
• Запуск контейнерів та подів з не привілейованими можливостями.
• Розмежування мережі, щоб контролювати ризики, які можуть виникнути при скомпромтуванні.
• Використаня фаєрволу для обмеження трафіку та його шифрування для додаткового рівня конфіденційності.
• Використання автентифікацї та авторизації, щоб обмежити та контролювати адміністративний доступ до системи.
• Періодичний огляд всіх налаштувань Kubernetes та використання систем сканування вразливостей для попередження можливих атак.

Огляд

Вразливі ланки: існує декілька рівнів інфраструктури, і кожен із них має вразливе місце.

Наша мета — мінімізувати ділянки, вразливі до атаки.

Проаналізуємо наступне:

• Хмарні провайдери та сервери.
• Кластер Kubernetes.
• Контейнери (images та runtime).

Перший рівень — це кластерні сервери, на які припадає все ваше робоче навантаження. Наступними рівнями є кластер і контейнери.

Із чого розпочати? Переконайтеся, що ваш кластер розгорнутий у приватній мережі, а трафік надходить з load balancer-а та сервісів ingress. Не відкривайте такі порти, як SSH або RDP, намагайтеся використовувати SSM або взагалі нічого, оскільки Kubernetes-у майже не потрібна базова система конфігурацій. Крім того, використовуючи служби керування Kubernetes, вам навіть не потрібно хвилюватись про початкові налаштування. Ви просто керуватимете операторами.

Безпека контейнерів

Все починається з кращих практик для докерфайлі, давайте розглянемо їх.

Жартую, в нас про безпеку :)

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

Непривілейовані користувачі (rootless)

За замовчуванням багато служб контейнерів працюють як привілейований користувач root. У той самий час програми, що виконуються всередині контейнера як root, не мають потреби у привілейованому виконанні. Для того щоб зменшити ризик скомпрометувати ваш контейнер, обмежте використання root користувачів за допомогою non-root або rootless контейнерів.

Dockerfile-alpine

FROM alpine:3.12, 
# Create user and set ownership and permissions as required
RUN adduser -D myuser && chown -R myuser /myapp-data
COPY myapp /myapp
USER myuser
ENTRYPOINT ["/myapp"]

Незмінні контейнерні файлові системи

Такі системи захищають від створення файлів, завантаження скриптів та модифікації програм в контейнері. Однак ці обмеження також впливають на законні контейнерні програми та потенційно можуть призвести до збоїв. Щоб запобігти пошкодженню законних програм, ви можете підключити вторинні файлові системи читання/запису для певних каталогів, де програми потребують write-доступу.

read-only-deployment-yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
    name: web
spec:
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
      name: web
    spec:
      containers:
        - command: ["sleep"]
          args: ["999"]
          image: ubuntu:latest
          name: web
          securityContext:
            readOnlyRootFilesystem: true
          volumeMounts:
            - mountPath: /writeable/location/here
              name: volName
      volumes:
        - emptyDir: {}
          name: volName

Контейнери без shell, cat, grep, less, tail, echo тощо

«Distoless» зображення містять лише вашу програму та її залежності під час виконання. Вони не мають менеджерів пакетів, обгорток чи будь-яких інших програм, які ви очікували б знайти в стандартному дистрибутиві Linux.

Dockerfile-distroless

# Start by building the application.
FROM golang:1.13-buster as build

WORKDIR /go/src/app
ADD . /go/src/app

RUN go get -d -v ./...
RUN go build -o /go/bin/app

# Now copy it into our base image.
FROM gcr.io/distroless/base-debian10
COPY --from=build /go/bin/app /
CMD ["/app"]

Менше значить краще

Надавайте перевагу меншому обсягу даних, що зберігаються всередині контейнера. Ви повинні зберігати там лише свої програми, без вихідного коду та build залежностей.

Секрети

Секрети Kubernetes, які зростають разом із самим додатком, використовуються для передачі конфіденційної інформації, наприклад, паролів чи токенів. Ви можете зберігати секрети в Kubernetes API, монтувати їх як файли, або просто оголошувати як змінну середовища. Також є оператори, до прикладу Bitnami Sealed Secret, які допомагають зашифрувати вміст секрету та дають змогу відправити конфіденційні дані в репозиторій.

pod-with-secret-yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username

Скануйте Docker контейнери

Джерело

А тепер до хороших новин! Docker і Snyk нещодавно об’єдналися, щоб забезпечити краще сканування вразливостей контейнерів. Що це означає для вас? Тепер Snyk інтегровано з Docker Hub для сканування офіційних зображень. Крім того, Docker інтегрував сканування Snyk безпосередньо в клієнти Docker. Отже тепер ви можете інтегрувати його в одну команду для сканування контейнерів у вашій CI.

Звичайно, ви можете використовувати інші провайдери, як от Quay. Але вони вимагають більше інтеграцій та конфігурацій. Крім того, такі служби, як Docker hub, AWS ECR, Quay, забезпечують сканування зображення після того, як ви відправили контейнер в Docker registry. Але поки ви виправлятимете ці вразливості, контейнер, можливо, вже використовуватиметься на кількох середовищах, включно з продакшеном.

Також ви можете разгорнути декілька служб, як от docker-bench-security. Вони виконуватимуть сканування вашого Kubernetes кластера. Втім, це може бути зайвим, адже ми маємо Pod Security Policy, яка охоплюватиме більшість наших заходів безпеки, про що ми поговоримо нижче.

Безпека Kubernetes

Ця тема буде трохи більшою і складнішою, оскільки ми будемо говорити про мережу, протоколи, інструменти, різні підходи та політики. Ми розглянемо їх усі, і для тих, хто нещодавно почав працювати з Kubernetes, деякі теми можуть бути занадто складними. Однак, ми з усім розберемось.

Отже, перейдемо до цієї теми.

Перше питання, яке ми маємо поставити, працюючи з Kubernetes, це «як я можу встановити системні оператори та проєктні додатки в Kubernetes кластер?». Чому б не використовувати інструменти CLI? Це дійсно можливо. Але не обов’язково означає, що це правильний шлях. Адже усі workloads мають бути структуровані, як пакети, та розгорнуті з певною гнучкістю. Для цього ми маємо Helm.

Helm допомагає розгортати ті самі файли YALM, але з шаблонізацією, як от зі змінними та умовами. Крім того, він має історію ревізій, що дає змогу відновити ту чи іншу версію. Іншими словами, Helm може значно полегшити ваше життя. Крім того, майже всі сервіси надають свої власні Helm чарти, які ви можете встановити в один клік. Це так само просто, як встановлення пакетів у Linux.

Існує два підходи до автоматизованого та безпечного розгортання Helm чартів: push-based та pull-based.

Push-based підхід — це те, що я люблю називати класичним підходом. Ми всі його знаємо, оскільки використовуємо щодня. Скажімо, вам потрібно побудувати процес CI/CD. Ви обрали систему CI, створили та надіслали артефакт, а потім запускаєте розгортання безпосередньо з CI. Це найпростіший спосіб, і він має значні переваги, як от зворотний зв’язок.

У ньому також є підводні камені. По-перше, ви маєте надати доступ та права адміністратора до кластера з CI. По-друге, стан програми може бути змінений з моменту останнього випуску, або хтось може змінити конфігурації, і ваш CI буде зламано. Таким чином, маючи доступ адміністратора, CI може легко застосовувати, змінювати або видаляти інші ресурси. Щоб уникнути цього, ми можемо використовувати інший підхід.

Pull-based підхід, також відомий як GitOps, заснований на операторі, який працює всередині кластера. Він відстежує зміни в сховищі та застосовує їх автоматично. Оскільки оператор має доступ до репозиторію, нам не потрібно надавати CI системі доступ до кластера.

Перевага використання цього підходу полягає в тому, що ви завжди маєте джерело істини (SSOT — Single Source of Truth ). Щобільше, оператор помітить будь-які зміни, внесені вручну, і відновить їх до стану репозиторію, тому ми ніколи не зіткнемося зі зсувом конфігурації. Є два pull-based інструменти: Flux і ArgoCD. Давайте поговоримо про ArgoCD.

kind: Application
metadata:
  name: bookinfo
  namespace: argocd
spec:
  destination:
    namespace: bookinfo
    server: https://kubernetes.default.svc
  project: default
  source:
    path: applications/bookinfo
    repoURL: [email protected]:sqerison/gitops-demo-kubernetes-workloads.git
    targetRevision: main
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

kind: AppProject
metadata:
  name: bookinfo
  namespace: argocd
spec:
  destinations:
    - namespace: '*'
      server: '*'
  clusterResourceWhitelist:
    - group: '*'
      kind: '*'
  sourceRepos:
    - [email protected]:sqerison/gitops-demo-kubernetes-workloads.git
    - [email protected]:sqerison/gitops-demo-bookinfo-app.git

ArgoCD це оператор, який відповідає за pull-based підхід та слідує GitOps принципам. Основна його роль — це менеджити та оновлювати ресурсу щоразу, коли він отримує зміни з репозиторію. ArgoCD працює з двома основними ресурсами: Application та AppProject.

Application описує сам ресурс, тобто додаток, який потрібно встановити. Це можу бути Helm чарт, чи звичайні YAML файли, чи Kustomize ресурси. Також ми вказуємо до якого проєкту (AppProject) відноситься цей додаток.

AppProject забезпечує логічне групування додатків, що корисно, коли Argo CD використовується кількома командами. Він має декілька функцій. Наприклад, може обмежити те, що може бути розгорнуто. Або ж може обмежити ті типи об’єктів, які можуть або не можуть бути розгорнуті, наприклад, RBAC, CRD, DaemonSets, Network Policy тощо. При створенні додатків, ми матимемо змогу обирати, в рамках якого проєкту вони будуть існувати, та які доступи отримають.

Загалом, ArgoCD оснащений потужним інтерфейсом користувача, тому працювати з ним дуже зручно. Він має вбудовані функції безпеки, підтримку SAML/OKTA, а також має розширений role-based досвід.

Pod Security Policy

Нарешті ми підійшли до Pod Security Policy.

На початку цієї статті ми згадували non-root контейнери, read-only файлові системи та інші docker практики як передача сокета docker, чи використання мережі системи (—net=host). За допомогою PSP ми можемо запровадити та не допустити виконання подів, якщо ці вимоги не будуть задоволені.

psp-non-privileged-yaml

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false  # Don't allow privileged pods!
  # The rest fills in some required fields.
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

Ось простий приклад, для чого ми можемо застосувати PSP. Скажімо, ви можете заборонити запуск контейнерів в привілейованому режимі (privileged: false) або ж заборонити роботу root користувачів (MustRunAsNonRoot). Але пам’ятайте, для того, що правила PSP ресурсу вступили в силу, їх потрібно авторизувати за допомогою RBAC.

Через певну складність, інженери часто не використовують цей ресурс, бо разом із політиками, вам потрібно подбати про інші конфігурації, ламаючи голову, як і де їх використовувати. Саме тому PSP функціонал найближчим часом стане застарілим.

Але PSP — не єдине, що ми можемо використовувати для забезпечення функцій безпеки. У нас є Open Policy Agent.

Open Policy Agent

Агент Open Policy, по суті, є Gatekeeper-ом. Це оператор, який оцінює запити до контролера допуску (admission controller), щоб визначити, чи відповідають вони правилам.

За допомогою цього інструмента ви можете розширити контроль над ресурсами, які будуть створені. Ви можете контролювати такі речі, як labels, requests та limits. Це важливо, коли ви хочете масштабувати свою програму. Ви також можете обмежити список docker репозиторіїв, дозволивши лише корпоративні або AWS ECR.

Але, як і будь-який потужний інструмент, він має досить складний синтаксис політики. По суті, це мова REGO. Розгляньмо наступний приклад.

psp-non-privileged-yaml

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8spspprivilegedcontainer
spec:
  crd:
    spec:
      names:
        kind: K8sPSPPrivilegedContainer
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8spspprivileged
        violation[{"msg": msg, "details": {}}] {
            c := input_containers[_]
            c.securityContext.privileged
            msg := sprintf("Privileged container is not allowed: %v, securityContext: %v", [c.name, c.securityContext])
        }
        input_containers[c] {
            c := input.review.object.spec.containers[_]
        }
        input_containers[c] {
            c := input.review.object.spec.initContainers[_]
        }

Це — політика для обмеження docker репозиторіїв із типом ConstraintTemplate. Я не знаю, як писати на REGO. Тож це лише приклад, який я знайшов в бібліотеці, наданої Gatekeeper на GitHub. Отже, ця конфігурація — це просто шаблон, і аргументи для цього наведені в наступному прикладі.

opa-k8sallowedrepos-inuse-yaml

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: repo-is-openpolicyagent
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "default"
  parameters:
    repos:
      - "openpolicyagent/"
      - "quay.io/"
      - "<aws_account>.dkr.ecr.<region>.amazonaws.com/"

Щойно ви створите шаблон, Gatekeeper на його основі створиться CRD, на який ви зможете посилатися, описуючи, які саме репозиторії ви хочете дозволити і для яких namespace-ів це застосувати. Ми використовуємо цю політику для модулів і namespace-ів за замовченням, але ви можете самостійно визначити деякі namespace-и. Зрештою, у нас є список реєстрів, яким ми хочемо довіряти. Найважче — це написати шаблони, які взагалі-то можна погуглити, а решта не складна.

Network Policies

На щастя, у порівнянні з gatekeeper-ом Network Policies набагато простіші у використанні ys; Gatekeeper. Як ви знаєте, namespace-и в Kubernetes не ізольовані один від одного, і будь-який под може спілкуватися з будь-яким іншим подом. Це може створювати проблеми, особливо якщо у вас є сервіси з конфіденційними даними або моніторингом, які повинні мати доступ лише до порту метрик. Крім того, якщо у вас є кластер із кількома додатками від різних клієнтів, ви повинні бути впевнені, що вони не будуть взаємодіяти один з одним.

network-policy-deny-all-ns-yaml

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: default
  name: deny-from-other-namespaces
spec:
  podSelector:
    matchLabels:
  ingress:
  - from:
    - podSelector: {}

У цьому прикладі зображено, як ви можете дозволити трафік з інших namespace-ів на основі лейбів. Якщо ви хочете проекспериментувати з мережею, ви можете запустити под у тестовому namespace-і з міткою prod, і трафік буде дозволено. У крайньому випадку, завжди можна звернутися до Gatekeeper-a та вказати, які саме лейби повинні бути присутні в даному namespace-і.

np-web-allow-prod-yaml

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-prod
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production

Щоб Network Policies працювали, вам потрібно встановити мережевий плагін (CNI), який їх підтримує. Calico — хороший кандидат. AWS EKS має власний мережевий плагін, і його теж можна використовувати для подів та керувати правилами з AWS консолі.

np-api-allow-5000-yaml

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: api-allow-5000
spec:
  podSelector:
    matchLabels:
      app: apiserver
  ingress:
  - ports:
    - port: 5000
    from:
    - podSelector:
        matchLabels:
          role: monitoring

Останній приклад — обмеження за портом. Ви можете дозволити трафік тільки до порту з метриками, до якого матиме доступ система моніторингу. Також, важливо звернути увагу на ще одне зауваження щодо AWS CNI. У випадку використання Custom Networking, Network Policies втратять свою силу. Тому ви повинні обирати, яка система політик вам найбільше підходить.

Крім того, ще є Mesh система Istio, яка має свої політики. Вона працює на сьомому рівні OSI та дозволяє гнучкіше керувати трафіком. Але Istio — досить широка тема, тому ми сьогодні не будемо про неї говорити.

Секрети

Усім зараз цікаво, як ми можемо безпечно доставити конфіденційну інформацію в кластер. Одним з непоганих варіантів для управління вашими секретами є Bitnami Sealed Secrets. Вам просто потрібно зашифрувати секрет за допомогою ключа шифрування та отримати готовий ресурс, який можна розгортати в кластері.

Іншою альтернативою є GitCrypt, який шифрує файли за допомогою GPG ключів. Це не найкращий варіант для секретів Kubernetes, але хороший — для інших конфіденційних даних, таких як приватні ключі або kubeconfig.

Розгляньмо приклад Sealed Secrets. Як бачите, значення зашифровано. І, як тільки ви розгорнете цей файл у кластері, оператор Bitnami Sealed Secrets перетворить і розшифрує його у звичайний секрет.

sealed-secret.yaml

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  annotations:
    sealedsecrets.bitnami.com/cluster-wide: "true"
  creationTimestamp: null
  name: demo-secret
spec:
  encryptedData:
    api-key: AgCK+iL6mZX6woqKiYQPWeELNt4/JrpaiwLR75d24OnshhsNveGB7CqGF1dr+rAxal4gr+d4No4Q+uAQgUizgLnY2IdWvAKVh/3miCgPW8SO8p8BOxpD8U1qBgJBb74M8rPbvxh47L0y2iSymSa4wdf4zcyju5CvoWnnB0Qbsx6lNzGMDnt6rjjzje3Su7ktrj4qnmX6BhRnukGmw+bErT31DzVWDrgrlcd2eQFuAflysckJv7wdIZXKSZwAWHAJzipUcNbG+O+UHJwia7RXwef9F2Ruebnl2jXH5/7iCV+83NLivdl0aW2TzLGOLR1NMG63NtN3T95Qfisame2QkYCBmYRCCCn3iwwxzDXDymAFE9/RqnnIPzhA/K0YayPZnLInoO3pTVxF1DL+RnmWRojUOwoO5ZkY++Behzq7nn9nRrEC+u/aDk2CXwJe9WbHwVgznKM7N6v4IUlcQz93VhRUbDetnWhA3TnD+HDsc85z0hvFp8c2U4giqRL4CnXHQIfBG63hLHoAogWOH8I+paVId180DWFpwjsAsKXVbESUa2ORL7LmuiDg1qKLoVFxiEEVJmnYPv5F8P1XMvJPW6L6QRQnJqj/ntyRSyEKnNh3umRTBoJzfXNDhsDXMPMu0leuYN1D+arx6IHBCKPexevE53iE7JK05bj/Oq8ujCOJRyv6TqjX4gQM3+kgXmi8rnCYB1CJg6lvhH1+pw==
  template:
    data: null
    metadata:
      annotations:
        sealedsecrets.bitnami.com/cluster-wide: "true"
      creationTimestamp: null
      name: demo-secret

Тепер наш Sealed Secret — це звичайний секрет. Як ми вже згадували раніше, ви можете легко надати доступ до ArgoCD розробникам та іншим інженерам. Але не забудьте переконатися, що вони мають лише доступ на читання.

Kubernetes Hardening

Тепер час поговорити про самі компоненти кластеру. Вони також мають свої вразливі місця та зловмисники з радістю ними скористаються у випадки неправильних конфігурації.

API Server

API Server є ядром Kubernetes. На деяких ванільних та старих версіях, API-сервер працює не тільки через HTTPS, але й на незахищеному порту (HTTP), який не перевіряє автентифікацію та авторизацію. Обов’язково переконайтеся, що ви вимкнули незахищені порти. Ви також можете спробувати надіслати curl запит на 8080 порт, щоб перевірити, чи отримаєте відповідь.

Etcd

Etcd схожий на базу даних, яка зберігає інформацію про кластер і секрети кластера. Це важливий компонент, і кожен, хто може писати в etcd, може ефективно контролювати ваш Kubernetes кластер. Навіть просте читання вмісту etcd може легко дати корисні підказки потенційному зловмиснику. Сервер etcd має бути налаштований так, щоб довіряти лише сертифікатам, які призначені API-серверам. Таким чином він буде доступний лише для перевірених компонентів в кластері.

Kubelet

Kubelet — це агент, який отримує інструкції, що і де робити. Здебільшого відповідає за планування ваших додатків в кластері. Перевірте наявність анонімного доступу та правильного режиму авторизації, і ви будете в безпеці.

Kubernetes dashboard

Дошборду краще вимкнути повністю, оскільки у нас є інші інструменти, які можуть допомогти нам зрозуміти статус кластера. Як, наприклад, ArgoCD. Із його допомогою, ви побачите лише ресурси, створені Argo. І це добре, оскільки зазвичай проблеми виникають через додатки та ресурси проєкту, тоді як сам кластер є досить стабільним.

Також я підготував таблицю зі списком портів, які ви можете перевірити на вразливість.

Інші допоміжні інструменти

Це ще не все. У мене є кілька інструментів, які допоможуть із пошуком вразливих місць.

Kubescape

Щоб запустити цей інструмент, вам достатньо виконати дві команди. Одну — для завантаження скрипту, а іншу — для його виконання. В результаті ви отримаєте список вразливостей і неправильних конфігурацій із підсумком і загальною оцінкою в кінці. Пам’ятаєте рекомендації щодо посилення Kubernetes? Цей інструмент перевірить їх для вас. Крім того, Kubescape використовує бази даних, які відповідно оновлюються для виявлення нових вразливостей.

Kube-bench

Він майже такий самий, як Kubescape, за винятком того, що він виконується всередині кластера і може бути розгорнутий як Cronjob для регулярного сканування.

Kubesec

Простий плагін для сканування модулів Kubernetes.

Kubeaudit

Має подібні функції, але використовується для виявлення несправносте (debugging) та створює хороший список з прикладами, які допоможуть з їх усуненням.

І це все на сьогодні. Сподіваюся, вам сподобалася ця стаття і на основі цієї інформації ви зробите свій кластер hackers-proof :)

Матеріали зі статті

Контакти:

• LinkedIn
• GitHub
• Instagram
• YouTube

Презентація:

Політики та інші приклади:

Репозиторій з Helm чартом який використовувався для демо: github.com/...​erison/argo-rollouts-demo

Утиліти які згадувалися в останній секції:
github.com/armosec/kubescape
github.com/aquasecurity/kube-bench
github.com/...​olplaneio/kubectl-kubesec
github.com/...​fy/kubeaudit#installation
github.com/eldadru/ksniff

Матеріали для навчання:

• A book released by CISA (Cybersecurity and Infrastructure Security Agency)
• O`REILLY Kubernetes Security
• O`REILLY Container Security