Облачная безопасность и управление доступом

К этой теме приложение «Заметки» уже прошло весь путь от исходного кода до кластера: образы собраны (тема 4), компоненты запущены в Kubernetes и связаны через Service и DNS (тема 7), пароль базы лежит в Secret, а данные — на постоянном томе (тема 8), инфраструктура описана в OpenTofu (тема 9), вложения хранятся в S3 (тема 10). Всё это работает, но ни один из механизмов не отвечал на вопрос, кто имеет право выполнять действия и что произойдёт, если одна из частей системы окажется в руках злоумышленника. По умолчанию ответ неутешителен: любой под кластера может открыть соединение с любым другим подом, процесс в контейнере обычно работает от root, токен для обращения к API Kubernetes монтируется в каждый под, а образы содержат сотни пакетов, о большинстве которых автор приложения ничего не знает.

Безопасность облачного приложения не сводится к одному средству. Она складывается из нескольких независимых рубежей, каждый из которых закрывает свой класс угроз: управление доступом к API облака и кластера, изоляция процесса внутри узла, изоляция подов в сети, контроль происхождения и содержимого образов, журналирование действий. Если один рубеж прорван — уязвимость в приложении позволила выполнить код, — следующие ограничивают последствия. Этот принцип называют эшелонированной защитой (англ. defense in depth).

Изложение построено от угроз к механизмам. Первый раздел формулирует модель угроз облачного приложения и делит ответственность между провайдером и клиентом. Второй посвящён управлению доступом в облаке: сущностям IAM, вычислению политик, учётным записям для экстренного доступа и идентичности нагрузок. Третий прослеживает запрос к API Kubernetes через аутентификацию, авторизацию RBAC и контроль допуска. Четвёртый описывает изоляцию пода средствами Pod Security Standards и securityContext, пятый — сетевую изоляцию NetworkPolicy. Шестой раздел охватывает цепочку поставок образов, аудит и типичные ошибки. Примеры строятся на «Заметках» и на стенде лабораторной работы 11.

Модель угроз и разделение ответственности

Что атакуют в облачном приложении

Модель угроз (англ. threat model) — описание того, что в системе ценно, кто и какими путями может до этого добраться и какие механизмы этому препятствуют. Для «Заметок» ценны содержимое базы (заметки пользователей), учётные данные (пароль PostgreSQL, ключи доступа к S3, токены API кластера) и сама вычислительная мощность (захваченный кластер используют для майнинга или как плацдарм для атаки на другие системы). Модель угроз полезна тем, что превращает расплывчатое «сделать безопасно» в перечень конкретных вопросов, на каждый из которых есть проверяемый ответ.

Многие известные инциденты в облаках начинались не с изощрённых уязвимостей, а с ошибок конфигурации и управления доступом: утёкших долговременных ключей, избыточных прав, открытых наружу ресурсов. Рекомендации NIST по безопасности контейнеров выделяют риски образов, реестра, оркестратора, контейнеров и хоста ²; в таблице ниже они сведены в перечень, который определяет структуру темы.

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

Разделение ответственности между провайдером и клиентом

В собственном центре обработки данных за всё отвечает одна организация: от охраны здания до пароля в конфигурации приложения. В облаке ответственность делится. Провайдер отвечает за безопасность самого облака (англ. security of the cloud): физические площадки, оборудование, гипервизор, сеть между центрами данных, программное обеспечение управляемых сервисов. Клиент отвечает за безопасность в облаке (англ. security in the cloud): за то, как он настроил выданные ему ресурсы, кому дал доступ, какие данные и как хранит ⁴. Эту договорённость называют моделью разделения ответственности (англ. shared responsibility model); схема на рисунке ниже показывает её в общем виде.

Граница смещается вместе с сервисной моделью из темы 1. В модели IaaS клиент получает виртуальную машину и отвечает за гостевую ОС, её обновления, межсетевой экран и всё, что выше. В управляемом Kubernetes провайдер обновляет и защищает плоскость управления (apiserver, etcd, планировщик), а рабочие узлы, как правило, остаются в общей зоне: провайдер выпускает обновлённые образы узлов, но решение о применении и окно обновления часто остаются за клиентом. В SaaS клиенту остаются по существу только учётные записи и данные.

Две нижние строки не уходят к провайдеру ни в одной модели. Именно на них приходится большинство инцидентов: провайдер не может знать, что бакет с резервными копиями не должен быть публичным, а сервисной учётной записи CI не нужны права на удаление базы данных. Отсюда практический вывод: механизмы управления доступом — главная зона ответственности клиента в любом облаке.

Нулевое доверие и принцип наименьших привилегий

Классическая модель безопасности сети опиралась на периметр: всё внутри корпоративной сети считалось доверенным, всё снаружи — нет. В облаке и тем более внутри кластера периметр размыт: поды разных команд делят одну сеть, сервисы обращаются к API провайдера через интернет, разработчики работают из дома. Архитектура нулевого доверия (англ. zero trust architecture), описанная в NIST SP 800-207, отказывается от доверия на основании сетевого расположения: каждый запрос к ресурсу аутентифицируется и авторизуется по отдельности, с учётом идентичности субъекта, состояния устройства и контекста, а доступ выдаётся минимально необходимый и на ограниченное время ¹.

Для этой темы из нулевого доверия следуют три рабочих правила. Первое: идентичность важнее адреса — правило «разрешить подам из подсети 10.244.0.0/16» слабее правила «разрешить учётной записи notes-backend». Второе: принцип наименьших привилегий (англ. principle of least privilege) — каждому субъекту выдаются только те права, которые нужны для его задачи, и только на те ресурсы, с которыми он работает. Третье: исходить из предположения о компрометации — проектировать так, чтобы захват одного компонента не давал доступа ко всему остальному. Все механизмы следующих разделов — реализации этих правил на разных уровнях.

Управление идентификацией и доступом в облаке

Сущности IAM: субъект, ресурс, действие, политика, условие

Система управления идентификацией и доступом (англ. Identity and Access Management, IAM) облачного провайдера отвечает на один вопрос: может ли данный субъект выполнить данное действие над данным ресурсом в данных условиях. У разных провайдеров разные названия, но сущности одни и те же:

• субъект (англ. principal) — тот, от чьего имени выполняется запрос: пользователь-человек, группа, сервисная учётная запись, роль, которую временно принял субъект, или внешняя идентичность (например, под Kubernetes через федерацию);
• ресурс (англ. resource) — объект, над которым выполняется действие, с глобально уникальным именем: в AWS это ARN, например arn:aws:s3:::notes-attachments/2026/a.png;
• действие (англ. action) — операция API: s3:GetObject, ec2:TerminateInstances, compute.instances.start;
• политика (англ. policy) — документ, разрешающий или запрещающий набор действий над набором ресурсов; в одних облаках политика прикрепляется к субъекту или ресурсу (AWS), в других роль связывается с субъектом на уровне ресурса привязкой (англ. binding, так устроены Google Cloud и RBAC Kubernetes);
• условие (англ. condition) — дополнительное ограничение на контекст запроса: адрес источника, использование TLS, наличие MFA, время, метки ресурса.

Аутентификация (англ. authentication) устанавливает, кто выполняет запрос: проверяет подпись запроса ключом, пароль с вторым фактором, токен федерации. Авторизация (англ. authorization) решает, можно ли этому субъекту выполнить действие. Это две разные стадии с разными ошибками: неверный ключ приводит к отказу аутентификации, правильный ключ без нужной политики — к отказу авторизации. В теме 10 подпись SigV4 была механизмом аутентификации запроса к S3; политика бакета из той же темы — механизмом авторизации.

Политика в формате JSON и порядок её вычисления

Рассмотрим политику AWS IAM, которую можно прикрепить к роли backend «Заметок». Она разрешает читать и записывать вложения, но запрещает любые операции с бакетом без TLS и удаление резервных копий.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AttachmentsReadWrite",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::notes-attachments/*"
    },
    {
      "Sid": "DenyPlainHTTP",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::notes-attachments", "arn:aws:s3:::notes-attachments/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "DenyDeleteBackups",
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "arn:aws:s3:::notes-attachments/backups/*"
    }
  ]
}

Поле Version — версия языка политик, а не дата документа; значение 2012-10-17 текущее. Каждый элемент Statement состоит из эффекта (Allow или Deny), списка действий, списка ресурсов и необязательного условия. Шаблоны * допускаются в действиях и ресурсах, но именно они чаще всего превращают узкую политику в широкую: "Action": "s3:*", "Resource": "*" разрешает всё во всех бакетах аккаунта.

Порядок вычисления определяет, что делать, когда несколько утверждений и политик противоречат друг другу ⁵. Исходное решение — неявный запрет: всё, что не разрешено, запрещено. Затем просматриваются все применимые политики; если хотя бы одно утверждение с Deny подходит к запросу, результат — явный запрет, и никакое Allow его не отменяет. Если явного запрета нет, запрос разрешается, только когда его разрешает политика субъекта или ресурса и не ограничивают ограничители более высокого уровня: политики управления организацией (SCP), границы полномочий (англ. permissions boundary), политики сессии. Правило «явный запрет побеждает» позволяет администратору организации поставить ограждение, которое не обойдёт никакая политика внутри аккаунта.

Проверим порядок вычисления на конкретных запросах роли с этой политикой (других политик нет):

Третья и пятая строки дают одинаковый результат по разным причинам, и разница существенна. Неявный запрет снимается тем, что кто-то добавит политику с Allow на удаление. Явный запрет не снимет никакая дополнительная политика — для этого нужно изменить или удалить само запрещающее утверждение. Четвёртая строка показывает типичную ошибку проектирования: шаблон ресурса шире, чем подразумевал автор, и роль может перезаписать резервную копию. Защитой здесь служит либо более узкий шаблон, либо Object Lock из темы 10.

Учётные записи для экстренного доступа

Принцип наименьших привилегий не означает, что учётных записей с полными правами не должно существовать. Кто-то должен иметь возможность восстановить доступ, если сломан провайдер единого входа, удалена ключевая политика или заблокированы все администраторы. Для этого заводят учётные записи экстренного доступа (англ. break-glass accounts, по аналогии с «разбейте стекло» у пожарной кнопки). Их отличает не уровень прав, а режим использования: их не применяют в повседневной работе; их немного (обычно две, чтобы потеря одной не лишала доступа); учётные данные хранятся раздельно и физически защищены (аппаратные ключи второго фактора в сейфе); любое их использование немедленно вызывает оповещение; процедуру входа периодически проверяют, чтобы в момент аварии она сработала.

В Kubernetes аналогом служит конфигурация с сертификатом группы system:masters. Эта группа обрабатывается авторизатором особо и получает все права, минуя RBAC, поэтому отозвать её удалением привязки нельзя — только отзывом сертификата, что на практике означает перевыпуск центра сертификации кластера. Начиная с версии 1.29 kubeadm разделяет повседневный admin.conf (группа kubeadm:cluster-admins, права через обычную привязку RBAC, которую можно удалить) и super-admin.conf (группа system:masters) — второй и есть учётная запись экстренного доступа, и хранить его на рабочей станции администратора не следует.

Идентичность нагрузок вместо статических ключей

Приложению в облаке тоже нужна идентичность: backend «Заметок» обращается к S3. Простейшее решение — создать пользователя IAM, выпустить ему ключ доступа и положить ключ в Secret. У этого решения три недостатка. Ключ бессрочен: если он утёк в лог, в образ или в публичный репозиторий, им можно пользоваться до тех пор, пока кто-то не заметит утечку. Ключ не привязан к месту использования: с ним работают с любого компьютера в мире. Ключ нужно вручную менять, а смена в нескольких местах одновременно — источник аварий, поэтому её откладывают.

Идентичность нагрузок (англ. workload identity) заменяет хранимый секрет выдачей короткоживущих учётных данных на основании того, чем является нагрузка. В Kubernetes основой служит токен ServiceAccount (подробно — в разделе 3): kubelet получает от apiserver подписанный JWT, привязанный к конкретному поду и действующий ограниченное время, и монтирует его в контейнер. Облачный провайдер настраивается доверять издателю этих токенов. В Amazon EKS механизм называется IAM Roles for Service Accounts (IRSA) ⁶: кластер публикует открытые ключи издателя по протоколу OIDC; в под монтируется токен с аудиторией sts.amazonaws.com; SDK приложения вызывает sts:AssumeRoleWithWebIdentity, предъявляя токен, и получает временные ключи роли. В политике доверия роли условие ограничивает, какая учётная запись какого пространства имён может её принять:

{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.eu-central-1.amazonaws.com/id/EXAMPLE" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "oidc.eks.eu-central-1.amazonaws.com/id/EXAMPLE:sub": "system:serviceaccount:notes:notes-backend",
      "oidc.eks.eu-central-1.amazonaws.com/id/EXAMPLE:aud": "sts.amazonaws.com"
    }
  }
}

В Google Kubernetes Engine та же идея реализована как Workload Identity Federation, в Azure — Microsoft Entra Workload ID; в EKS появился и альтернативный механизм EKS Pod Identity с агентом на узле. Детали отличаются, а выигрыш один: в кластере не хранится ни одного долговременного ключа облака. Украденный токен живёт час, работает только для одной роли и только до удаления пода.

Доступ к API Kubernetes

Конвейер запроса: аутентификация, авторизация, допуск

Каждое действие в кластере — от kubectl get pods до создания пода контроллером ReplicaSet — это HTTPS-запрос к kube-apiserver (тема 7). Прежде чем объект будет записан в etcd, запрос проходит цепочку стадий, и каждая может его отклонить ⁷. Схема на рисунке ниже показывает эту цепочку и коды ответа при отказе.

Аутентификация устанавливает имя пользователя и группы. Kubernetes не хранит объектов «пользователь»: имя берётся из клиентского сертификата (поле CN — имя, поля O — группы), из токена ServiceAccount, из токена OIDC внешнего провайдера или из ответа вебхука. Аутентификаторы опрашиваются по очереди, первый успешный определяет субъект. Если токен предъявлен, но недействителен, ответ — 401 Unauthorized. Если учётных данных нет вовсе, а анонимный доступ включён (так по умолчанию в кластерах kubeadm и minikube), запрос получает имя system:anonymous и идёт дальше — чтобы почти сразу получить отказ авторизации.

Авторизация решает, разрешено ли субъекту действие. Запрос описывается атрибутами: пользователь и группы, глагол (get, list, create, delete и т. д.), группа API, ресурс и подресурс, пространство имён, имя объекта. Авторизаторы — обычно Node (права kubelet на объекты своего узла) и RBAC, иногда вебхук — опрашиваются по очереди; достаточно одного разрешения. Если не разрешил никто, ответ — 403 Forbidden. Важное отличие от IAM облака: в стандартном RBAC нет запрещающих правил, только разрешающие, поэтому вопрос «что побеждает» не возникает.

Контроль допуска (англ. admission control) выполняется только для запросов, изменяющих объекты, и смотрит уже на содержимое объекта. Мутирующие контроллеры допуска дополняют объект: проставляют учётную запись по умолчанию, ограничения ресурсов, внедряют вспомогательные контейнеры. Затем объект проверяется на соответствие схеме. Проверяющие контроллеры допуска решают, допустим ли объект: здесь работают встроенный PodSecurity (раздел 4), политики ValidatingAdmissionPolicy на языке CEL и внешние вебхуки Kyverno или OPA Gatekeeper (раздел 6). Разделение ролей между стадиями стоит запомнить: RBAC отвечает на вопрос «может ли этот субъект создавать поды в этом пространстве имён», а контроль допуска — «допустим ли этот конкретный под».

ServiceAccount и его токены

ServiceAccount — объект Kubernetes, представляющий идентичность процессов в подах. У каждого пространства имён есть учётная запись default; под, в котором serviceAccountName не указан, работает от её имени. Полное имя субъекта для авторизации — system:serviceaccount:<пространство>:<имя>, а группы — system:serviceaccounts и system:serviceaccounts:<пространство>.

До версии 1.22 токен ServiceAccount был бессрочным JWT, хранившимся в Secret; кто однажды прочитал этот Secret, мог пользоваться токеном, пока Secret не удалят. Современный механизм — привязанные (англ. bound) токены, которые kubelet получает через API TokenRequest и монтирует в под как спроецированный том (англ. projected volume) ⁹. Такой токен имеет срок действия, аудиторию (для кого он выпущен) и привязку к объекту пода: после удаления пода apiserver перестаёт его принимать, даже если срок не истёк. Начиная с версии 1.24 секреты с бессрочными токенами автоматически не создаются. Kubelet обновляет спроецированный токен, когда тот прожил 80 % срока или больше 24 часов, а приложение должно перечитывать файл, а не кешировать токен навсегда.

Токен — обычный JWT из трёх частей в base64url, и его полезную нагрузку можно прочитать без ключа. Для учётной записи notes-viewer стенда ЛР 11 токен выпускается командой kubectl create token; ниже показана примерная структура его полей (значения идентификаторов сокращены):

kubectl -n lab11 create token notes-viewer --duration=10m | python3 scripts/jwt-claims.py

header: {"alg": "RS256", "kid": "..."}
{
  "aud": ["https://kubernetes.default.svc.cluster.local"],
  "exp": 1792000600,
  "iat": 1792000000,
  "iss": "https://kubernetes.default.svc.cluster.local",
  "kubernetes.io": {
    "namespace": "lab11",
    "serviceaccount": {"name": "notes-viewer", "uid": "..."}
  },
  "nbf": 1792000000,
  "sub": "system:serviceaccount:lab11:notes-viewer"
}
срок жизни: 600 с (0.17 ч), истекает ...

Поле sub — имя субъекта для RBAC, iss — издатель (его открытые ключи и проверяет облако при федерации), aud — аудитория: apiserver отвергнет токен, выпущенный для другой аудитории, например для sts.amazonaws.com. Разность exp − iat = 600 с — это срок жизни. У токена, смонтированного kubelet в под, в поле kubernetes.io дополнительно присутствует объект pod с именем и UID — это и есть привязка. По умолчанию kubelet запрашивает токен на 3607 секунд, но apiserver с включённым по умолчанию флагом --service-account-extend-token-expiration выдаёт его на больший срок ради совместимости со старыми клиентами, которые не перечитывают файл; поэтому в ЛР 11 срок проверяется на поде с явно заданным expirationSeconds.

Большинству подов токен API не нужен вовсе: backend «Заметок» обращается к PostgreSQL и S3, а не к Kubernetes. Поле automountServiceAccountToken: false в спецификации пода или в объекте ServiceAccount отключает монтирование, и захваченный под не сможет даже попробовать обратиться к apiserver от своего имени.

RBAC: Role, ClusterRole и привязки

Авторизатор RBAC (англ. Role-Based Access Control) работает с четырьмя типами объектов ⁸. Role — набор правил в пределах одного пространства имён; ClusterRole — набор правил без привязки к пространству имён, который может описывать и кластерные ресурсы (узлы, PersistentVolume, сами пространства имён). RoleBinding связывает субъекты с ролью внутри одного пространства имён, ClusterRoleBinding — во всём кластере. Схема на рисунке ниже показывает эти объекты.

Правило роли состоит из групп API ("" — основная группа, где лежат pods, services, secrets; apps — Deployment и StatefulSet), ресурсов и подресурсов (pods/log, pods/exec), глаголов и, при необходимости, имён конкретных объектов (resourceNames). Роль стенда ЛР 11 разрешает только чтение подов и их журналов:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: lab11
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: notes-viewer-pod-reader
  namespace: lab11
subjects:
  - kind: ServiceAccount
    name: notes-viewer
    namespace: lab11
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader

Поле roleRef неизменяемо: чтобы привязать субъекта к другой роли, привязку удаляют и создают заново. Распространённый и полезный приём, который не виден на схеме, — RoleBinding, ссылающийся на ClusterRole: правила описываются один раз как ClusterRole, а действуют только в пространстве имён привязки. Так устроены встроенные роли view, edit и admin, которые выдают командам в их пространствах имён. Роль view намеренно не включает чтение Secret, edit — включает.

Проверять права нужно не чтением YAML, а вопросом к самому авторизатору. Команда kubectl auth can-i отправляет запрос SelfSubjectAccessReview — с флагом --as от имени олицетворяемого субъекта, — и apiserver отвечает, разрешил бы он действие:

kubectl auth can-i list pods -n lab11 --as=system:serviceaccount:lab11:notes-viewer
kubectl auth can-i list secrets -n lab11 --as=system:serviceaccount:lab11:notes-viewer
kubectl auth can-i list pods -n default --as=system:serviceaccount:lab11:notes-viewer

yes
no
no

Флаг --as сам по себе использует право олицетворения, о котором пойдёт речь ниже; у администратора кластера оно есть. Настоящий запрос с токеном учётной записи даёт тот же результат, но в виде HTTP-ответа: список подов с кодом 200 и для секретов — объект Status с кодом 403 и сообщением вида secrets is forbidden: User "system:serviceaccount:lab11:notes-viewer" cannot list resource "secrets" in API group "" in the namespace "lab11". Сообщение называет все атрибуты запроса, которые проверял авторизатор, и по нему удобно искать, какого правила не хватает.

Опасные права

Некоторые права в RBAC значат гораздо больше, чем подсказывает их название, потому что позволяют получить другие права ⁸. Документация Kubernetes выделяет их отдельно, и их полезно знать наизусть.

Без глаголов escalate и bind RBAC защищён от повышения привилегий: apiserver не даст создать роль или привязку, дающую больше, чем есть у создающего. Именно поэтому их выдача — по сути выдача всех прав. Практический вывод для приложений: учётной записи backend не нужны права на API вовсе, учётной записи CI достаточно edit в одном пространстве имён, а Prometheus из темы 12 получает ClusterRole только с get, list, watch на поды, сервисы и EndpointSlice.

Изоляция пода: Pod Security Standards и securityContext

Почему root в контейнере опасен

В теме 3 было показано, что контейнер — обычный процесс Linux в отдельных пространствах имён и группах cgroups, работающий на общем ядре узла. Пространство имён пользователей Kubernetes по умолчанию не включает, поэтому UID 0 внутри контейнера — тот же UID 0, что и на узле. От полного root его отделяют три механизма. Возможности (англ. capabilities) делят привилегии суперпользователя на около сорока частей; среда выполнения по умолчанию оставляет контейнеру лишь часть из них (у Docker — 14, среди них CHOWN, DAC_OVERRIDE, SETUID, SETGID, NET_RAW, NET_BIND_SERVICE, KILL). Фильтр системных вызовов seccomp запрещает опасные вызовы ядра. Модули LSM (AppArmor, SELinux) ограничивают доступ к файлам и операциям ³.

Каждый из этих механизмов можно ослабить в манифесте одной строкой, и тогда граница исчезает. Под с privileged: true получает все возможности и доступ к устройствам узла; с hostPID: true видит все процессы узла; с томом hostPath: / может прочитать и изменить файловую систему узла, включая учётные данные kubelet. Но и без этих крайностей root в контейнере увеличивает последствия ошибки: уязвимость ядра, достижимая только из-под UID 0 или требующая конкретной возможности, становится доступной; DAC_OVERRIDE позволяет игнорировать права файлов на смонтированных томах; NET_RAW позволяет формировать произвольные пакеты в сети узла. Процесс веб-сервера, работающий от непривилегированного UID без возможностей, при захвате даёт злоумышленнику существенно меньше.

Три профиля Pod Security Standards

Pod Security Standards — три профиля, которые определяют, какие поля спецификации пода допустимы ¹⁰. Они описывают политику, а реализует её встроенный контроллер допуска Pod Security Admission, ставший стабильным в версии 1.25 и заменивший удалённый в той же версии PodSecurityPolicy.

Профиль включается метками пространства имён. Каждая метка задаёт режим и уровень: enforce — под, нарушающий профиль, отклоняется; warn — запрос выполняется, но клиент получает предупреждение; audit — нарушение записывается в аудит. Дополнительные метки ...-version фиксируют версию правил, чтобы обновление кластера не ужесточило профиль внезапно.

apiVersion: v1
kind: Namespace
metadata:
  name: lab11-web
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest

Режимы различаются не только реакцией, но и объектами. enforce применяется только к подам. warn и audit применяются ещё и к объектам с шаблоном пода — Deployment, StatefulSet, Job. Отсюда характерная ловушка: если включён только enforce, Deployment с нарушающим шаблоном создаётся без единого сообщения, а поды не появляются; причина видна лишь в событиях ReplicaSet (FailedCreate ... violates PodSecurity "restricted:latest"). Поэтому enforce почти всегда дополняют warn того же уровня. Перед включением на существующем пространстве имён полезна проверка kubectl label --dry-run=server --overwrite ns <имя> pod-security.kubernetes.io/enforce=restricted: apiserver перечислит уже работающие поды, которые нарушают профиль, ничего не меняя.

Поля securityContext

Профиль только проверяет; соответствовать ему должен сам манифест. Безопасные значения задаются в securityContext — на уровне пода (действуют на все контейнеры) и на уровне контейнера (переопределяют значения пода для этого контейнера). Ниже — frontend «Заметок» на nginx, приведённый к профилю restricted; это тот же манифест, что в ЛР 11.

apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: lab11-web
spec:
  automountServiceAccountToken: false
  securityContext:                     # уровень пода
    runAsNonRoot: true
    runAsUser: 101
    runAsGroup: 101
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: nginx
      image: nginxinc/nginx-unprivileged:1.31.7-alpine3.24
      ports:
        - containerPort: 8080
      securityContext:                 # уровень контейнера
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir:
        sizeLimit: 16Mi

Разберём поля по одному.

runAsNonRoot: true — требование, а не действие: kubelet перед запуском контейнера проверяет, что процесс не будет работать от UID 0, и отказывается запускать его, если это не так. Проверка опирается на runAsUser, а если он не задан — на инструкцию USER образа (тема 4). Здесь кроется частая ошибка: если в Dockerfile написано USER node или USER app — имя, а не число, — kubelet не может узнать UID, не заглянув в /etc/passwd образа, и под не запускается со статусом CreateContainerConfigError и сообщением container has runAsNonRoot and image has non-numeric user (node), cannot verify user is non-root. Исправлений два: указывать в Dockerfile числовой UID (USER 10001 или USER 10001:10001) или задавать runAsUser в манифесте. Образ nginxinc/nginx-unprivileged уже содержит USER 101, а в манифесте UID продублирован явно. Обычный образ nginx инструкции USER не имеет, работает от root и слушает порт 80 — поэтому для профиля restricted выбран вариант образа, рассчитанный на непривилегированный запуск и слушающий порт 8080.

readOnlyRootFilesystem: true монтирует корневую файловую систему контейнера — верхний слой overlay2 из темы 3 — только для чтения. Злоумышленник, получивший выполнение кода, не сможет подменить файлы приложения или записать и запустить свой исполняемый файл. Но приложению обычно нужно куда-то писать: nginx-unprivileged кладёт в /tmp pid-файл и временные файлы прокси. Для таких каталогов монтируется emptyDir — временный том, живущий столько же, сколько под; sizeLimit ограничивает его размер, а при medium: Memory он размещается в памяти и учитывается в лимите памяти контейнера.

capabilities.drop: ALL удаляет все возможности, включая стандартный набор среды выполнения. Веб-серверу на порту выше 1024 ни одна из них не нужна. Если процесс всё же должен слушать порт 80 без root, в список capabilities.add добавляют ровно одну — NET_BIND_SERVICE.

allowPrivilegeEscalation: false устанавливает процессу флаг ядра no_new_privs: после этого ни запуск setuid-программ (su, sudo, ping в старых дистрибутивах), ни файловые возможности не могут дать процессу больше прав, чем у родителя. Для контейнеров с privileged: true или с возможностью CAP_SYS_ADMIN повышение привилегий всегда считается разрешённым — им повышать уже нечего.

seccompProfile.type: RuntimeDefault включает профиль seccomp среды выполнения (containerd, CRI-O), который запрещает системные вызовы, редко нужные приложениям и часто встречающиеся в эксплойтах: загрузку модулей ядра, kexec_load, reboot, часть операций с ключами ядра и т. п. Существенная деталь: в Kubernetes без явного указания контейнеры работают без seccomp (Unconfined), в отличие от Docker, где профиль по умолчанию включён. Kubelet можно настроить флагом --seccomp-default использовать RuntimeDefault для всех подов, но по умолчанию он выключен.

Последнее поле — automountServiceAccountToken: false — не входит в securityContext и не требуется профилем, но относится к той же задаче: не давать поду то, что ему не нужно.

Сетевая изоляция: NetworkPolicy

Модель: изолированные поды и аддитивные правила

Сетевая модель Kubernetes (тема 7) требует, чтобы любой под мог связаться с любым другим подом без NAT. Это упрощает построение приложений и одновременно означает, что захваченный frontend «Заметок» может напрямую подключиться к PostgreSQL на порт 5432, обойдя backend со всей его проверкой прав. NetworkPolicy — объект, ограничивающий, какие соединения разрешены на уровне IP-адресов и портов (уровни 3 и 4) ¹¹.

Модель NetworkPolicy строится на понятии изоляции. Под, который не выбран ни одной политикой, не изолирован: ему разрешено всё входящее и исходящее. Как только хотя бы одна политика выбирает под полем podSelector и содержит в policyTypes значение Ingress, под становится изолированным для входящих соединений: теперь к нему допускается только то, что явно разрешено правилами ingress хотя бы одной из выбирающих его политик. То же независимо для Egress. Политики только разрешают, запрещающих правил в стандартном API нет. Поэтому политики аддитивны: итоговое множество разрешённых соединений — объединение правил всех политик, выбирающих под, и порядок применения политик не важен.

Из модели следуют два свойства, которые часто упускают. Первое: соединение проходит, только если его разрешают обе стороны — egress-политики пода-источника и ingress-политики пода-назначения. Второе: правила относятся к установлению соединения; ответные пакеты уже разрешённого соединения пропускаются автоматически, отдельное правило для них не нужно.

Важнее всех деталей синтаксиса одно условие: NetworkPolicy реализует сетевой плагин CNI, а не apiserver. Apiserver примет и сохранит объект при любом CNI. Если плагин политики не поддерживает, объект просто ничего не делает: трафик идёт, как шёл, и никаких ошибок нет. Документация Kubernetes прямо предупреждает, что политика без реализующего её контроллера не действует ¹¹; документация minikube уточняет, что сетевой плагин minikube по умолчанию политики не реализует и кластер для работы с ними создают с флагом --cni=calico. Calico и Cilium поддерживают политики, Flannel — нет. Поэтому любую политику проверяют попыткой соединения, которое она должна запретить, а не наличием объекта в kubectl get networkpolicy.

default-deny и разрешающие политики

Надёжная схема начинается с запрета всего и добавления узких разрешений: политика по умолчанию «запретить» (англ. default-deny). Пустой podSelector: {} выбирает все поды пространства имён, а отсутствие правил ingress при значении Ingress в policyTypes ничего не разрешает:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: lab11
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-from-backend
  namespace: lab11
spec:
  podSelector:
    matchLabels:
      app: db
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 5432

Первая политика изолирует все поды для входящих соединений — изнутри кластера и снаружи. Вторая добавляет одно разрешение: к подам app=db на 5432/TCP от подов app=backend того же пространства имён. Рисунок ниже показывает стенд ЛР 11 до появления политик и после полного набора: default-deny в обе стороны и явные разрешения.

Заметим, что порт в правиле — порт пода (containerPort), а не порт Service. Политики вообще формулируются в терминах подов, а не сервисов: в распространённых реализациях соединение с ClusterIP сначала транслируется kube-proxy в адрес конкретного пода, и уже этот адрес сопоставляется с правилами. Отброшенное соединение выглядит у клиента как тайм-аут, а не как отказ: Calico и большинство других плагинов молча отбрасывают пакеты, и pg_isready или curl ждут до истечения своего тайм-аута.

Исходящий трафик и ловушка DNS

Ограничение входящего трафика защищает базу от frontend, но не мешает захваченному поду устанавливать соединения наружу: выгружать данные, скачивать инструменты, подключаться к серверу управления. Для этого нужна изоляция исходящего трафика. Её включают так же — политикой default-deny со значением Egress в policyTypes — и именно на этом шаге чаще всего ломают работающее приложение.

Причина — DNS. Backend обращается к базе по имени db, и первым делом его библиотека отправляет запрос к CoreDNS (тема 7) — исходящее соединение на порт 53 пода в пространстве имён kube-system. После default-deny egress этот запрос отбрасывается, имя не разрешается, и приложение сообщает об ошибке подключения к базе, хотя правило «backend → db» на месте. Разрешение DNS выписывают отдельно, для всех подов пространства имён:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: lab11
spec:
  podSelector: {}
  policyTypes: ["Egress"]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

TCP указан не для полноты: DNS переходит на TCP, когда ответ не помещается в UDP-датаграмму, и разрешение только UDP даёт редкие, плохо воспроизводимые сбои. Метку kubernetes.io/metadata.name apiserver автоматически ставит каждому пространству имён начиная с версии 1.22, поэтому по ней удобно выбирать пространство имён. Метка k8s-app: kube-dns у подов CoreDNS — соглашение kubeadm и minikube; в управляемых кластерах её стоит проверить командой kubectl -n kube-system get pods --show-labels. После разрешения DNS остаётся добавить egress-сторону основного разрешения: backend → поды app=db на 5432/TCP.

Селекторы: «и» против «или»

Элемент списка from или to может содержать podSelector, namespaceSelector и ipBlock. Тонкость в YAML: два селектора в одном элементе списка объединяются по «и», два отдельных элемента — по «или». Сравним:

# Один элемент: поды k8s-app=kube-dns В пространстве имён kube-system
- to:
    - namespaceSelector: {matchLabels: {kubernetes.io/metadata.name: kube-system}}
      podSelector: {matchLabels: {k8s-app: kube-dns}}

# Два элемента: ЛЮБОЙ под в kube-system ИЛИ поды k8s-app=kube-dns в своём пространстве имён
- to:
    - namespaceSelector: {matchLabels: {kubernetes.io/metadata.name: kube-system}}
    - podSelector: {matchLabels: {k8s-app: kube-dns}}

Разница — один дефис, а смысл противоположный: вторая форма разрешает соединения со всеми подами kube-system. Отдельно стоит запомнить, что podSelector без namespaceSelector выбирает поды только в пространстве имён самой политики. Политика «разрешить DNS» с одним podSelector: {k8s-app: kube-dns} ничего не разрешает, потому что в lab11 подов CoreDNS нет; в ЛР 11 эта ошибка разбирается как задание «найдите ошибку».

Элемент ipBlock задаёт диапазон адресов в нотации CIDR с исключениями except и применяется для адресов вне кластера: внешней базы данных, API провайдера. Для подов он ненадёжен, так как их адреса меняются. У стандартного NetworkPolicy есть и ограничения: нет запрещающих правил и приоритетов, нельзя сослаться на доменное имя, нельзя описать политику для всего кластера сразу. Эти задачи решают расширения конкретных плагинов (GlobalNetworkPolicy в Calico, CiliumNetworkPolicy с правилами по DNS-именам и уровню 7) и разрабатываемый SIG Network API AdminNetworkPolicy.

Цепочка поставок, аудит и типичные ошибки

Сканирование образов и конфигураций

Образ «Заметок» содержит не только код приложения, но и базовый дистрибутив с сотнями пакетов: libc, OpenSSL, интерпретатор, утилиты. Каждый из них может содержать известные уязвимости, зарегистрированные в каталоге CVE (англ. Common Vulnerabilities and Exposures). Сканер уязвимостей определяет по метаданным образа список пакетов и их версии и сопоставляет его с базой уязвимостей ². Trivy — сканер с открытым кодом, который проверяет образы, файловые системы и репозитории, а также конфигурации: Dockerfile, манифесты Kubernetes, код OpenTofu ¹³. В теме 4 он упоминался кратко; здесь важно понять, что именно означают его числа.

Ниже — результаты сканирования четырёх образов Python, каждый из которых отличается от предыдущего одним свойством. Сканирование выполнено 22.10.2026 программой Trivy 0.70.0 с базой уязвимостей от 21.10.2026; в таблице — уязвимости пакетов ОС.

Таблица учит нескольким вещам. Python 3.8 вышел из поддержки в 2024 году, и образ 3.8-slim больше не пересобирается: он застыл на Debian 12.7 и накапливает уязвимости, для 217 из которых исправленные пакеты давно есть. Переход на 3.12-slim убирает все критические уязвимости, но меняет две переменные сразу — версию Python и версию Debian, — что видно из колонки «Основа»; приписывать выигрыш одному из факторов по этим данным нельзя. Все 44 HIGH в 3.12-slim имеют статус affected без исправленной версии: Debian ещё не выпустил исправлений, и обновление пакетов внутри образа ничего не даст. Флаг --ignore-unfixed скрыл бы их все, поэтому решение о нём — осознанная политика, а не способ «почистить отчёт». Alpine показывает почти ноль, но отчасти потому, что база безопасности Alpine (secdb) содержит только уязвимости, для которых уже выпущено исправление: неисправленные уязвимости в отчёте по Alpine не видны в принципе, и строки таблицы не вполне сравнимы. Меньшее число в отчёте не тождественно меньшему числу уязвимостей в природе. Наконец, distroless на той же Debian 13.7 даёт меньше, чем slim, за счёт меньшего числа пакетов — это и есть уменьшение поверхности атаки, измеренное при одной изменённой переменной.

Числа в таблице устареют через несколько дней: база уязвимостей обновляется ежедневно, а образы с плавающими тегами (3.12-slim) пересобираются. Поэтому любые выводы о «безопасности образа» сопровождают датой, версией сканера и версией базы. По той же причине образ, прошедший проверку при сборке, сканируют повторно в реестре и в работающем кластере.

Второй режим — проверка конфигураций. trivy config не запускает ничего, а проверяет файлы набором правил. Для намеренно плохого Dockerfile из ЛР 11 (основа python:3.8-slim, нет USER, apt-get install без --no-install-recommends) отчёт выглядит так:

trivy config --quiet image/Dockerfile.bad

Dockerfile.bad (dockerfile)
===========================
Tests: 27 (SUCCESSES: 24, FAILURES: 3)
Failures: 3 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 2, CRITICAL: 0)

DS-0002 (HIGH): Specify at least 1 USER command in Dockerfile with non-root user as argument
DS-0026 (LOW): Add HEALTHCHECK instruction in your Dockerfile
DS-0029 (HIGH): '--no-install-recommends' flag is missed: 'apt-get update && apt-get install -y curl'
...

Для манифестов правила семейства KSV проверяют то же, что Pod Security Standards, и ещё кое-что сверх них: обычный под nginx из ЛР 11 даёт 17 замечаний, приведённый к restricted — четыре, и все они — рекомендации, которых профиль не требует (UID не больше 10000, не задан лимит CPU, образ не из доверенного реестра). Это полезное напоминание: у сканера свой набор мнений, и «ноль замечаний» не равно «соответствует профилю», и наоборот.

В конвейере CI сканер становится воротами (англ. gate) через код выхода: trivy image --exit-code 1 --severity CRITICAL,HIGH <образ> завершается с кодом 1, если найдено хотя бы одно совпадение, и шаг сборки падает. На практике к этому добавляют --ignore-unfixed и файл .trivyignore с явными исключениями — иначе ворота закроются навсегда из-за уязвимостей, которые никто не может исправить.

SBOM, подпись образов и политики допуска

Список компонентов программного обеспечения (англ. Software Bill of Materials, SBOM) — машиночитаемая опись того, из чего собран образ: пакеты, версии, лицензии, хеши. Её формируют при сборке (trivy image --format cyclonedx --output sbom.cdx.json <образ> или syft <образ> -o spdx-json) в форматах CycloneDX или SPDX и хранят рядом с образом. Ценность SBOM проявляется, когда публикуют новую уязвимость: вместо повторного скачивания и разбора всех образов достаточно поискать уязвимый пакет в описях (trivy sbom sbom.cdx.json).

Сканирование отвечает на вопрос «что внутри», но не на вопрос «откуда это взялось». Образ в реестре можно подменить, если украдены учётные данные реестра; тег notes-backend:1.4 можно перезаписать другим содержимым. Защиту дают два механизма. Первый — ссылка на образ по digest (тема 4): registry.example.com/notes/backend@sha256:... неизменна по определению. Второй — криптографическая подпись. Cosign из проекта Sigstore подписывает digest образа и кладёт подпись в тот же реестр ¹⁴. Подписывать можно ключевой парой (cosign sign --key cosign.key <образ>@sha256:...) или без долговременного ключа: в режиме keyless сборочный конвейер аутентифицируется по OIDC, удостоверяющий центр Fulcio выдаёт сертификат на несколько минут, а факт подписи записывается в публичный журнал прозрачности Rekor. Проверка выполняется командой cosign verify с указанием ожидаемого ключа или ожидаемой идентичности подписавшего. Так, например, проект Kubernetes подписывает свои образы, и их подлинность проверяется по идентичности сборочной учётной записи проекта.

Чтобы подписи и правила сканирования что-то значили, их нужно проверять в момент допуска пода, а не на рабочей станции. Это задача проверяющих контроллеров допуска из раздела 3. Встроенный механизм ValidatingAdmissionPolicy (стабилен с версии 1.30) позволяет описать проверку на языке выражений CEL без внешних компонентов. Например, следующая пара объектов запрещает в пространстве имён notes поды, у которых образ указан не по digest:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: images-by-digest
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: "object.spec.containers.all(c, c.image.contains('@sha256:'))"
      message: "образ должен быть указан по digest"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: images-by-digest
spec:
  policyName: images-by-digest
  validationActions: ["Deny"]
  matchResources:
    namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: notes

Проверку подписи CEL выполнить не может — для неё нужен доступ к реестру и криптография. Её выполняют внешние контроллеры допуска, подключаемые вебхуком: Kyverno (политики в виде YAML, правило verifyImages проверяет подписи cosign и аттестации) и OPA Gatekeeper (политики на языке Rego, проверка подписей через внешние поставщики данных). Рисунок ниже собирает цепочку поставки целиком: на каждом звене — свой механизм контроля.

Аудит kube-apiserver

Аудит отвечает на вопрос, который возникает после инцидента: кто, когда и что сделал. Kube-apiserver может записывать событие о каждом запросе в журнал аудита ¹². Что записывать, задаёт политика аудита — список правил, из которых для каждого запроса применяется первое подходящее. Уровень правила определяет подробность: None — не записывать, Metadata — только метаданные (кто, что, над каким объектом, код ответа), Request — плюс тело запроса, RequestResponse — плюс тело ответа. Событие может записываться на нескольких стадиях: RequestReceived, ResponseStarted (для долгих запросов вроде watch), ResponseComplete, Panic.

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
  # Секреты и ConfigMap — только метаданные: тела содержат пароли
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps", "serviceaccounts/token"]
  # Выполнение команд в контейнерах и изменения RBAC — подробно
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach"]
      - group: "rbac.authorization.k8s.io"
  # Шумные запросы чтения от системных компонентов — не записывать
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
  # Всё остальное — метаданные
  - level: Metadata

Порядок правил существенен: секреты стоят первыми, иначе их содержимое попало бы в журнал по более подробному правилу и журнал аудита сам стал бы хранилищем паролей. Политика подключается флагом --audit-policy-file, журнал — --audit-log-path (с ротацией --audit-log-maxage, --audit-log-maxbackup, --audit-log-maxsize) или вебхуком во внешнюю систему. В управляемых кластерах журнал аудита включается настройкой провайдера и попадает в его службу журналов. Каждое событие — JSON-объект с полями user (имя и группы), verb, objectRef (ресурс, пространство имён, имя), sourceIPs, userAgent, responseStatus.code и аннотацией authorization.k8s.io/reason — какое правило RBAC разрешило запрос. По этим полям ищут, например, все обращения к секретам от учётных записей приложений или все pods/exec за ночь.

Ограничения и типичные ошибки интерпретации

Первая и самая распространённая ошибка — считать политику действующей по факту её существования. NetworkPolicy при CNI без поддержки политик, метка PSS в режиме warn вместо enforce, политика допуска в режиме аудита, сканер, отчёт которого никто не читает, — всё это объекты, которые есть, но ничего не запрещают. Любую защитную меру проверяют негативным тестом: попыткой сделать то, что она должна запретить.

Вторая — смешение аутентификации и авторизации. Код 401 означает, что apiserver не поверил учётным данным; код 403 — что поверил, но правила не разрешают действие. Добавление роли не исправит 401, а перевыпуск токена не исправит 403.

Третья — неверное чтение RBAC. В нём нет запрещающих правил, поэтому «отнять» право у субъекта можно только удалив разрешающую привязку; права через группы (system:authenticated, system:serviceaccounts) получают все её члены, и их легко не заметить при чтении одной RoleBinding. Права на list secrets равносильны чтению всех секретов, а право создавать поды — правам всех учётных записей пространства имён.

Четвёртая — ожидание, что runAsNonRoot что-то меняет в образе. Поле только проверяет UID и не делает root непривилегированным; если образ рассчитан на root, под просто не запустится. Нечисловой USER не проходит проверку вовсе. Связанное заблуждение — проверять «не root ли под» по одному полю: runAsUser может быть задан на уровне пода, на уровне контейнера или не задан нигде, и тогда действует USER образа; полный ответ даёт только kubelet при запуске или сканер, видящий и манифест, и образ.

Пятая — неверная интерпретация отчётов сканера. Число CVE — не мера риска: уязвимость в пакете, который никогда не загружается процессом приложения, не эквивалентна уязвимости в OpenSSL сетевого сервиса; уязвимость без исправленной версии нельзя закрыть обновлением; сравнение двух образов имеет смысл, только если они отличаются одной переменной и сняты одной версией базы в один день. Отсутствие найденных уязвимостей не означает их отсутствия — сканер знает только о зарегистрированных и только о пакетах, которые смог распознать.

Шестая — ожидание, что NetworkPolicy защищает данные. Политика решает, может ли соединение начаться, но не шифрует и не аутентифицирует трафик: разрешённый под backend может передать базе что угодно, а трафик идёт открытым текстом. Шифрование и взаимная аутентификация между сервисами — задача TLS и сервисных сеток, которые в курсе не рассматриваются.

Итоги темы

Безопасность облачного приложения строится от модели угроз: сначала определяется, что ценно и какими путями до этого можно добраться, затем каждый путь закрывается своим механизмом. Модель разделения ответственности оставляет клиенту при любой сервисной модели учётные записи, права и данные, и именно в этой зоне происходит большинство инцидентов. Поэтому центральная тема — управление доступом: в облаке это политики IAM с правилом «явный запрет побеждает» и условиями, в Kubernetes — цепочка аутентификации, авторизации RBAC и контроля допуска.

Второй сквозной сюжет — замена долговременных секретов короткоживущими учётными данными, выдаваемыми на основании идентичности. Привязанные токены ServiceAccount живут ограниченное время и умирают вместе с подом; федерация этих токенов с IAM облака (IRSA, Workload Identity) позволяет обходиться в кластере без единого ключа облака. Учётные записи с полными правами при этом не исчезают, а переходят в режим экстренного доступа с отдельным хранением и оповещением при использовании.

Изоляция в кластере выполняется на двух уровнях. На уровне процесса Pod Security Standards задают профиль, а securityContext реализует его: запуск от числового непривилегированного UID, корневая файловая система только для чтения с emptyDir для записи, удаление всех возможностей, запрет повышения привилегий, профиль seccomp. На уровне сети NetworkPolicy начинают с default-deny и добавляют узкие разрешения с обеих сторон соединения, не забывая о DNS; работает всё это только при сетевом плагине с поддержкой политик.

Цепочка поставок защищается контролем на каждом звене: проверка конфигураций до сборки, сканирование образа как ворота CI, SBOM, подпись по digest и проверка подписи при допуске, повторное сканирование в работе. Числа сканера сопровождаются датой и версией базы и сравниваются при одной изменённой переменной. Аудит apiserver замыкает картину, позволяя восстановить действия после инцидента. Следующая тема — наблюдаемость — продолжает эту линию: метрики, журналы и трассы показывают не только сбои, но и аномалии, и сам Prometheus будет обращаться к API кластера от имени ServiceAccount с минимальной ролью RBAC, построенной по правилам этой темы.

Литература

1. Rose S., Borchert O., Mitchell S., Connelly S. Zero Trust Architecture. — NIST SP 800-207, 2020. https://doi.org/10.6028/NIST.SP.800-207
2. Souppaya M., Morello J., Scarfone K. Application Container Security Guide. — NIST SP 800-190, 2017. https://doi.org/10.6028/NIST.SP.800-190
3. Rice L. Container Security: Fundamental Technology Concepts that Protect Containerized Applications. — O'Reilly Media, 2020.
4. Amazon Web Services. Shared Responsibility Model. — https://aws.amazon.com/compliance/shared-responsibility-model/ (дата обращения: 22.10.2026).
5. AWS Identity and Access Management User Guide. Policy evaluation logic. — https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html (дата обращения: 22.10.2026).
6. Amazon EKS User Guide. IAM roles for service accounts. — https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html (дата обращения: 22.10.2026).
7. Kubernetes Documentation. Controlling Access to the Kubernetes API. — https://kubernetes.io/docs/concepts/security/controlling-access/ (дата обращения: 22.10.2026).
8. Kubernetes Documentation. Using RBAC Authorization. — https://kubernetes.io/docs/reference/access-authn-authz/rbac/ (дата обращения: 22.10.2026).
9. Kubernetes Documentation. Service Accounts. — https://kubernetes.io/docs/concepts/security/service-accounts/ (дата обращения: 22.10.2026).
10. Kubernetes Documentation. Pod Security Standards. — https://kubernetes.io/docs/concepts/security/pod-security-standards/ (дата обращения: 22.10.2026).
11. Kubernetes Documentation. Network Policies. — https://kubernetes.io/docs/concepts/services-networking/network-policies/ (дата обращения: 22.10.2026).
12. Kubernetes Documentation. Auditing. — https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/ (дата обращения: 22.10.2026).
13. Trivy Documentation. — https://trivy.dev/docs/ (дата обращения: 22.10.2026).
14. Sigstore Documentation. Cosign: Signing Overview. — https://docs.sigstore.dev/cosign/signing/overview/ (дата обращения: 22.10.2026).

Дополнительные материалы

Вопросы для самопроверки

1. Почему в модели разделения ответственности учётные записи, права и данные остаются за клиентом при любой сервисной модели? Приведите пример инцидента, который провайдер не может предотвратить.
2. Какие три правила для проектирования доступа следуют из архитектуры нулевого доверия?
3. Чем аутентификация отличается от авторизации? Какие коды ответа возвращает kube-apiserver при отказе на каждой из этих стадий и при отказе контроля допуска?
4. Перечислите сущности IAM и покажите их на примере политики, разрешающей backend читать вложения из бакета только по TLS.
5. В политике есть утверждение Allow на s3:* для бакета и утверждение Deny на s3:DeleteObject для префикса backups/. Разрешено ли удаление объекта backups/a.dump? Изменит ли решение ещё одна политика с Allow на s3:DeleteObject? Чем явный запрет отличается от неявного?
6. Зачем нужны учётные записи экстренного доступа, если действует принцип наименьших привилегий? Как ими пользуются и почему группа system:masters в Kubernetes подходит только для этой роли?
7. Почему статический ключ доступа к облаку в Secret хуже, чем IRSA или Workload Identity? Опишите по шагам, как под получает временные учётные данные роли.
8. Чем привязанный токен ServiceAccount отличается от токена в Secret, использовавшегося до версии 1.22? Когда kubelet обновляет токен и что происходит с токеном после удаления пода?
9. Чем различаются Role и ClusterRole, RoleBinding и ClusterRoleBinding? Зачем привязывать ClusterRole через RoleBinding?
10. Почему права escalate, bind, impersonate, create на pods/exec и list на secrets считаются опасными? Почему право создавать поды косвенно даёт доступ к секретам пространства имён?
11. Почему процесс от root в контейнере опаснее процесса от непривилегированного UID, если контейнер изолирован пространствами имён? Какие механизмы отделяют root в контейнере от root на узле?
12. Чем профили baseline и restricted различаются по требованиям? Почему Deployment, нарушающий профиль, может создаться без ошибки?
13. Каково поведение сети Kubernetes при отсутствии NetworkPolicy? Как записать политику default-deny для входящего трафика и почему после default-deny для исходящего трафика прежде всего ломается DNS?
14. Задача. В пространстве имён notes есть политики: default-deny ingress; разрешение к app=db на 5432 от app=backend; разрешение к app=db на 5432 от подов любого пространства имён с меткой team=analytics. Под app=report из пространства имён bi с меткой team=analytics подключается к базе. Пройдёт ли соединение, если в bi действует default-deny egress без других политик? Если в bi политик нет? Объясните по правилам аддитивности и двусторонности.
15. Задача. Образ A на Debian 12 содержит 9 CRITICAL и 116 HIGH, образ B на Debian 13 — 0 и 44, причём у всех 44 нет исправленной версии. Какие выводы о «безопасности» этих образов допустимы, а какие нет? Что произойдёт с воротами CI --exit-code 1 --severity HIGH с флагом --ignore-unfixed и без него?

Глоссарий темы

Шпаргалка по инструментам

Права и токены:

kubectl auth whoami                                        # кто я для apiserver
kubectl auth can-i create deployments -n notes             # могу ли я
kubectl auth can-i --list -n notes --as=system:serviceaccount:notes:notes-backend
kubectl -n notes create token notes-backend --duration=10m # токен на 10 минут
kubectl get rolebindings,clusterrolebindings -A -o wide | grep notes-backend
kubectl describe clusterrole edit                          # что входит во встроенную роль

Pod Security Admission:

kubectl label ns notes pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted
kubectl label --dry-run=server --overwrite ns notes \
  pod-security.kubernetes.io/enforce=restricted           # кто нарушил бы профиль
kubectl -n notes get events --field-selector reason=FailedCreate

Проверка «кто работает от root». Однострочник с jsonpath по полю runAsUser контейнера даёт ложное спокойствие: он не видит securityContext уровня пода, не видит USER образа и выводит пустоту, когда UID не задан нигде, — а именно тогда процесс, скорее всего, работает от root. Точный ответ знает только kubelet в момент запуска, поэтому надёжных способов три:

# 1. Спросить сам процесс (работает для подов, где есть id или /proc)
kubectl -n notes exec deploy/notes-backend -- id
kubectl -n notes exec deploy/notes-backend -- grep -E '^(Uid|CapEff|NoNewPrivs|Seccomp):' /proc/1/status

# 2. Поручить проверку Pod Security Admission: runAsNonRoot обязателен в restricted,
#    а kubelet не запустит контейнер, который всё равно оказался бы root
kubectl label --dry-run=server --overwrite ns notes pod-security.kubernetes.io/enforce=restricted

# 3. Статически — Trivy по манифестам (правила KSV-0012, KSV-0020 и др.)
#    и по образу (DS-0002 для Dockerfile без USER)
trivy config k8s/
trivy config Dockerfile

Если нужен обзор по всему кластеру, полезно хотя бы показывать оба уровня securityContext рядом, помня, что пустые значения означают «решает образ»:

kubectl get pods -A -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,POD_UID:.spec.securityContext.runAsUser,POD_NONROOT:.spec.securityContext.runAsNonRoot,CTR_UID:.spec.containers[*].securityContext.runAsUser,CTR_NONROOT:.spec.containers[*].securityContext.runAsNonRoot'

NetworkPolicy:

kubectl -n notes get netpol
kubectl -n notes describe netpol db-allow-from-backend    # разбор селекторов и портов
kubectl -n kube-system get pods --show-labels | grep dns  # метки CoreDNS для правила DNS
kubectl -n notes exec backend -- nslookup db.notes.svc.cluster.local
kubectl -n notes exec backend -- pg_isready -h db -p 5432 -t 3

Trivy:

trivy --version                                           # версия и дата базы
trivy image --severity HIGH,CRITICAL python:3.12-slim
trivy image --severity HIGH,CRITICAL --ignore-unfixed python:3.12-slim
trivy image --exit-code 1 --severity CRITICAL IMAGE       # ворота CI
trivy image --format json -o report.json IMAGE
trivy image --format cyclonedx --output sbom.cdx.json IMAGE
trivy sbom sbom.cdx.json                                  # сканирование описи
trivy config .                                            # Dockerfile, манифесты, HCL
trivy k8s --report summary                                # кластер текущего контекста

Подпись образов (cosign):

cosign generate-key-pair
cosign sign --key cosign.key registry.example.com/notes/backend@sha256:...
cosign verify --key cosign.pub registry.example.com/notes/backend@sha256:...

Что почитать и посмотреть

• Kubernetes Documentation. Role Based Access Control Good Practices — https://kubernetes.io/docs/concepts/security/rbac-good-practices/. Перечень опасных прав RBAC с объяснением, как каждое ведёт к повышению привилегий; основа таблицы опасных прав в лекции.
• Kubernetes Documentation. Configure a Security Context for a Pod or Container — https://kubernetes.io/docs/tasks/configure-pod-container/security-context/. Все поля securityContext с примерами, в том числе порядок применения полей пода и контейнера.
• Kubernetes Documentation. Pod Security Admission — https://kubernetes.io/docs/concepts/security/pod-security-admission/. Режимы enforce/warn/audit, версии профилей, исключения и порядок перехода с PodSecurityPolicy.
• minikube Handbook. Network Policy — https://minikube.sigs.k8s.io/docs/handbook/network_policy/. Почему CNI minikube по умолчанию не реализует политики и как включить Calico.
• Rose S. et al. Zero Trust Architecture, NIST SP 800-207 — https://doi.org/10.6028/NIST.SP.800-207. Первоисточник принципов нулевого доверия: короткий, хорошо структурированный документ.
• Rais R., Morillo C., Gilman E., Barth D. Zero Trust Networks: Building Secure Systems in Untrusted Networks. 2nd ed. — O'Reilly Media, 2024. Книга о практическом построении сетей нулевого доверия; во втором издании добавлены главы о современных средствах идентичности и сценарии внедрения.
• Garbis J., Chapman J. W. Zero Trust Security: An Enterprise Guide. — Apress, 2021. Взгляд со стороны организации: как переводить инфраструктуру к нулевому доверию поэтапно и что при этом меняется в процессах.
• Rice L. Container Security. — O'Reilly Media, 2020. Главы о возможностях ядра, seccomp, запуске без root и сканировании образов объясняют механику, на которую опираются Pod Security Standards.
• Kubernetes Documentation. Verify Signed Kubernetes Artifacts — https://kubernetes.io/docs/tasks/administer-cluster/verify-signed-artifacts/. Пошаговая проверка подписей образов Kubernetes с cosign; основа продвинутой части ЛР 11.
• Документация Kyverno — https://kyverno.io/docs/ и OPA Gatekeeper — https://open-policy-agent.github.io/gatekeeper/website/docs/. Два основных внешних контроллера допуска; полезно сравнить, как одна и та же политика записывается в YAML и на Rego.
• Википедия, статья «Capabilities (Linux)» и man-страница capabilities(7) — https://man7.org/linux/man-pages/man7/capabilities.7.html. Полный список возможностей ядра и правила их наследования при execve.

Углубление (по желанию)

От PodSecurityPolicy к Pod Security Admission

Первым механизмом ограничения подов в Kubernetes был PodSecurityPolicy — объект, описывающий допустимые настройки, и контроллер допуска, который выбирал подходящую политику для каждого пода. На практике он оказался трудным: какая политика применится, зависело от прав RBAC как создателя пода, так и учётной записи контроллера; политика могла не только проверять, но и изменять под; отлаживать отказы было мучительно. В версии 1.21 PodSecurityPolicy объявили устаревшим, в 1.25 удалили. Заменивший его Pod Security Admission намеренно прост: три фиксированных профиля, выбор по меткам пространства имён, никаких изменений объекта. Всё, что сложнее (запрет конкретных реестров, обязательные метки, проверка подписей), вынесено во внешние контроллеры — Kyverno, Gatekeeper — и во встроенный ValidatingAdmissionPolicy на языке CEL.

Пространства имён пользователей в Kubernetes

В теме 3 говорилось, что пространство имён пользователей позволяет процессу быть root внутри контейнера и непривилегированным пользователем на хосте. Kubernetes долго не использовал эту возможность для подов: она требует поддержки от ядра (монтирование с отображением идентификаторов), среды выполнения и kubelet. Поле hostUsers: false в спецификации пода включает отдельное пространство имён пользователей; функция развивалась несколько лет, и на момент написания её зрелость зависит от версии кластера, ядра и среды выполнения — перед использованием стоит свериться с документацией своей версии. Когда она доступна, UID 0 внутри контейнера отображается на непривилегированный UID узла, и многие сценарии выхода за пределы контейнера теряют смысл. Это не отменяет runAsNonRoot и удаления возможностей, но добавляет ещё один рубеж.

Почему сканер находит уязвимости, которых нет

Сканер вроде Trivy сопоставляет версии пакетов с базой уязвимостей и не знает, используется ли уязвимый код. Пакет libsqlite3 может быть установлен как зависимость, но ни разу не загружаться процессом приложения; уязвимость в функции разбора XML не опасна, если приложение не принимает XML. Отсюда интерес к оценке применимости: формат VEX (англ. Vulnerability Exploitability eXchange) позволяет поставщику образа заявить «уязвимость CVE-… к этому образу неприменима, потому что…», а Trivy умеет учитывать такие заявления. Обратная сторона: сканер не видит уязвимостей в коде, установленном не через менеджер пакетов (скопированный бинарный файл, собранная из исходников библиотека), и в коде самого приложения. Поэтому сканирование образа — необходимый, но не достаточный рубеж.

Лабораторная работа 11. Управление доступом, изоляция подов и сканирование образов

• Раздел курса: тема 11 «Облачная безопасность и управление доступом»

Введение

В лабораторных работах 7 и 8 приложение «Заметки» было развёрнуто в Kubernetes, и всё это время кластер работал в режиме полного доверия: любой под мог подключиться к базе данных, контейнеры запускались от root, а права на API никто не ограничивал. Настоящая работа проходит по рубежам защиты из темы 11 на учебном стенде из трёх компонентов — frontend, backend и db (PostgreSQL) — и на каждом рубеже требует не только настроить механизм, но и доказать негативным тестом, что он действительно запрещает то, что должен.

Работа начинается с кластера, у которого сетевой плагин реализует NetworkPolicy, — без этого половина работы дала бы ложный результат. Затем выдаются и проверяются права RBAC, причём не только через kubectl auth can-i, но и настоящими HTTP-запросами к apiserver с токеном учётной записи. Третий рубеж — профиль restricted Pod Security Standards: под, который он отвергает, нужно привести к профилю. Четвёртый — сетевая изоляция: default-deny для входящего и исходящего трафика и неизбежная починка DNS. Последняя часть не требует кластера: ряд образов сканируется Trivy так, чтобы между соседними образами менялась одна переменная, а trivy config проверяет Dockerfile и манифесты и служит воротами CI.

Базовая часть — части 1–8. Продвинутая часть (части 9–10, по желанию) показывает повышение привилегий через право создавать поды и проверку подписи образа cosign.

Цель работы

Научиться выдавать и проверять минимальные права в Kubernetes, приводить поды к профилю restricted, строить сетевую изоляцию с default-deny и интерпретировать результаты сканирования образов и конфигураций.

После выполнения работы можно будет:

• объяснить, почему NetworkPolicy не действует без CNI с поддержкой политик, и проверить это негативным тестом;
• выдать учётной записи ServiceAccount роль RBAC и проверить права командой kubectl auth can-i и прямым запросом к API с её токеном, различая ответы 401 и 403;
• прочитать поля токена ServiceAccount и измерить его срок действия;
• привести под к профилю restricted Pod Security Standards и объяснить назначение каждого поля securityContext;
• построить набор NetworkPolicy с default-deny в обе стороны, найти и устранить отказ DNS;
• сравнить образы по отчётам Trivy при одной изменённой переменной и зафиксировать условия измерения;
• использовать trivy config и trivy image --exit-code 1 как ворота конвейера сборки.

Теоретический минимум

Теория изложена в теме 11: разделы «Доступ к API Kubernetes», «Изоляция пода: Pod Security Standards и securityContext», «Сетевая изоляция: NetworkPolicy», «Цепочка поставок, аудит и типичные ошибки». Ниже — сжатая справка.

Учебный стенд (пространство имён lab11, кластер minikube с профилем lab11 и CNI Calico):

  frontend (app=frontend)        backend (app=backend)          db (app=db)
  postgres:17.11-alpine3.24      postgres:17.11-alpine3.24      postgres:17.11-alpine3.24
  sleep infinity                 sleep infinity                 PostgreSQL :5432
  должен НЕ достучаться до db    должен достучаться до db       Service db :5432 (часть 5)

  api-client (ServiceAccount notes-viewer, токен на 600 с)      — часть 2
  web в пространстве имён lab11-web (профиль restricted)         — часть 4
  CoreDNS в kube-system (k8s-app=kube-dns)                       — части 5–7

Клиентские поды frontend и backend используют тот же образ PostgreSQL ради двух утилит: pg_isready проверяет, принимает ли сервер соединения (код выхода 0 — да, 2 — нет ответа), а nslookup из BusyBox проверяет разрешение имён. Настоящее приложение «Заметки» для проверки сетевых правил не нужно: правила NetworkPolicy зависят только от меток подов и портов.

Перечень оснащения

• ОС Ubuntu 24.04 (физическая машина, виртуальная машина или WSL2) либо macOS/Windows с Docker Desktop; 4 ядра, 8 ГБ RAM, 15 ГБ свободного диска.
• Docker Engine 27 или новее (драйвер minikube).
• minikube 1.39 или новее (проверено по документации для 1.39.0 и Kubernetes v1.37.0), kubectl той же минорной версии, что кластер, ±1. Установка — по документации minikube; версии зафиксируйте командами minikube version и kubectl version.
• Trivy 0.6x или новее (материалы темы подготовлены на 0.70.0): установка из репозитория Aqua Security по инструкции на trivy.dev или пакетом из выпусков на GitHub. Trivy умеет скачивать образы из реестра сам, без Docker.
• Python 3.12 (для вспомогательных скриптов), curl.
• Архив окружения lr-env: скрипты up.sh/down.sh, манифесты manifests/, учебный образ image/ (два Dockerfile), вспомогательные scripts/, README.md.
• Образы (скачиваются при работе): postgres:17.11-alpine3.24, nginx:1.31.7-alpine3.24, nginxinc/nginx-unprivileged:1.31.7-alpine3.24, образы ряда Trivy своего варианта. Доступ в интернет нужен.

Порядок выполнения работы

Распакуйте архив и перейдите в каталог окружения:

unzip lr-env.zip -d ~/lab11 && cd ~/lab11/lr-env && chmod +x *.sh scripts/*.sh

Скрипт up.sh создаёт кластер minikube с профилем lab11 и CNI Calico, ждёт готовности Calico и CoreDNS, создаёт пространство имён lab11 и три пода стенда. Остальные объекты применяются вручную по ходу работы. В конце выполните ./down.sh — он удаляет профиль и безопасен при повторном запуске. Части 1–7 выполняются по порядку на одном кластере; часть 8 не требует кластера и может быть выполнена в любой момент.

Выберите вариант. Параметры варианта заменяют значения из манифестов стенда: имя учётной записи и ресурс правите в manifests/10-rbac.yaml (а для ресурсов из групп apps и batch — ещё и apiGroups), срок токена — в manifests/11-api-client.yaml.

Ряды образов (между соседними образами по замыслу меняется одно свойство):

Ниже команды приведены для варианта 1. Части 2–7 составлены по документации Kubernetes и minikube и автором на кластере не прогонялись; манифесты проверены синтаксически, часть 8 выполнена автором, её результаты приведены как образец.

Часть 1. Кластер с CNI, реализующим политики

Задание

1. Предсказание. Прочитайте up.sh. Что произойдёт, если создать кластер без флага --cni=calico, применить политику default-deny и проверить соединение backend → db? Будет ли ошибка при kubectl apply? Запишите ответ до запуска.

2. Поднимите стенд:

   ./up.sh
   

3. Убедитесь, что Calico работает, и найдите поды CoreDNS с их метками:

   kubectl -n kube-system get pods -l k8s-app=calico-node -o wide
   kubectl -n kube-system get pods -l k8s-app=kube-dns --show-labels
   kubectl get ns kube-system --show-labels
   

4. Запишите версии: minikube version, kubectl version, kubectl get nodes -o wide (версия kubelet и среды выполнения).

Что должно получиться

Под calico-node в состоянии Running и готовности 1/1; поды CoreDNS с меткой k8s-app=kube-dns; у пространства имён kube-system метка kubernetes.io/metadata.name=kube-system. Эти две метки понадобятся в части 6. Поды frontend, backend и db в пространстве имён lab11 — Running.

Ответ на пункт 1: объект NetworkPolicy хранит apiserver, а исполняет сетевой плагин. Если плагин политики не поддерживает (документация minikube указывает, что CNI по умолчанию их не реализует), kubectl apply завершится успешно, объект будет виден в kubectl get netpol, но трафик пройдёт. Ошибки не будет нигде — отсюда вывод «политика есть, значит работает» и его опасность. Если calico-node долго не становится готовым, чаще всего не хватает памяти: проверьте kubectl -n kube-system describe pod -l k8s-app=calico-node и при необходимости пересоздайте кластер с большим --memory.

Часть 2. RBAC и токен ServiceAccount

Задание

1. Примените учётную запись, роль и привязку (для своего варианта — после правки файла) и проверьте права:

   kubectl apply -f manifests/10-rbac.yaml
   SA=system:serviceaccount:lab11:notes-viewer
   kubectl auth can-i list pods -n lab11 --as=$SA
   kubectl auth can-i delete pods -n lab11 --as=$SA
   kubectl auth can-i list secrets -n lab11 --as=$SA
   kubectl auth can-i list pods -n default --as=$SA
   kubectl auth can-i --list -n lab11 --as=$SA
   

2. Предсказание. Какой HTTP-код вернёт apiserver на каждый из четырёх запросов ниже: со свежим токеном к списку подов, с тем же токеном к списку секретов, без токена к списку подов, с испорченным токеном (к строке добавлен символ) к списку подов? Запишите до выполнения.

3. Выполните настоящие запросы к API с токеном учётной записи:

   SERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
   TOKEN=$(kubectl -n lab11 create token notes-viewer --duration=10m)
   CA=~/.minikube/ca.crt
   req() { curl -sS --cacert "$CA" -o /tmp/lab11-resp.json -w '%{http_code}\n' "$@"; }
   
   req -H "Authorization: Bearer $TOKEN"  "$SERVER/api/v1/namespaces/lab11/pods"
   req -H "Authorization: Bearer $TOKEN"  "$SERVER/api/v1/namespaces/lab11/secrets";  cat /tmp/lab11-resp.json
   req                                    "$SERVER/api/v1/namespaces/lab11/pods";     cat /tmp/lab11-resp.json
   req -H "Authorization: Bearer ${TOKEN}x" "$SERVER/api/v1/namespaces/lab11/pods";   cat /tmp/lab11-resp.json
   

4. Прочитайте поля токена и вычислите срок его действия:

   echo "$TOKEN" | python3 scripts/jwt-claims.py
   

5. Создайте под api-client, в который токен спроецирован на 600 секунд, и прочитайте токен изнутри:

   kubectl apply -f manifests/11-api-client.yaml
   kubectl -n lab11 wait --for=condition=Ready pod/api-client --timeout=120s
   kubectl -n lab11 exec api-client -- cat /var/run/secrets/lab11/token | python3 scripts/jwt-claims.py
   kubectl -n lab11 exec api-client -- ls /var/run/secrets/kubernetes.io/serviceaccount
   

   Найдите в полях токена привязку к поду. Почему последняя команда сообщает, что каталога нет?

6. Наблюдение. Через 9–10 минут снова прочитайте токен в поде. Изменились ли iat и exp? Сопоставьте с правилом обновления токена kubelet из лекции.

7. Удалите под api-client и повторите запрос curl с токеном, прочитанным из него в пункте 5 (сохраните его заранее в переменную). Что ответит apiserver и почему, если срок токена ещё не истёк?

Что должно получиться

Ответы auth can-i для варианта 1: yes, no, no, no; в --list — строка pods с глаголами get list watch, а также строки с правами, выданными всем аутентифицированным субъектам (selfsubjectaccessreviews, selfsubjectreviews и т. п.) — объясните, откуда они.

Коды ответа: 200 для подов со свежим токеном; 403 для секретов с объектом Status, в поле message которого перечислены пользователь, глагол, ресурс, группа API и пространство имён; 403 без токена, но с пользователем system:anonymous (анонимный доступ в minikube включён, запрос аутентифицирован как аноним и отклонён авторизатором); 401 Unauthorized с испорченным токеном (подпись не сошлась, аутентификация не состоялась). Если для запроса без токена получен 401, анонимный доступ в вашем кластере выключен — это допустимое отклонение, объясните его.

Срок действия токена из create token — 600 с. В токене пода в поле kubernetes.io есть объект pod с именем api-client и UID; срок равен expirationSeconds вашего варианта. Каталога /var/run/secrets/kubernetes.io/serviceaccount нет из-за automountServiceAccountToken: false. После 80 % срока kubelet перевыпускает токен — iat меняется. Токен удалённого пода отклоняется с кодом 401 даже до истечения срока: apiserver проверяет, что объект, к которому привязан токен, существует и его UID совпадает.

Часть 3. Опасное право: найдите ошибку

Задание

1. Коллега «временно» выдал учётной записи право читать все объекты пространства имён, но «без секретов», и выполнил:

   kubectl -n lab11 create role almost-view --verb=list --resource=pods,services,secrets
   kubectl -n lab11 create rolebinding almost-view --role=almost-view --serviceaccount=lab11:notes-viewer
   kubectl -n lab11 create secret generic db-pass --from-literal=password=lab11-only
   

   Его аргумент: «глагола get для секретов нет, значит, прочитать конкретный секрет нельзя». Предсказание: прав ли он?

2. Проверьте: kubectl auth can-i get secrets/db-pass -n lab11 --as=$SA, затем запрос curl с токеном к $SERVER/api/v1/namespaces/lab11/secrets. Найдите в ответе значение пароля и раскодируйте его (base64 -d).

3. Исправьте ошибку и удалите роль и привязку almost-view.

Что должно получиться

auth can-i get отвечает no, но list возвращает объекты целиком, включая поле data с паролем в base64. Различие get/list для секретов не защищает их содержимое. Исправление — не выдавать никаких глаголов на secrets; если приложению нужен один секрет, его монтируют в под, а не читают через API.

Часть 4. Pod Security Standards: профиль restricted

Задание

1. Создайте пространство имён с профилем restricted в режимах enforce и warn и попробуйте создать обычный под nginx:

   kubectl apply -f manifests/30-web-namespace.yaml
   kubectl apply -f manifests/31-web-insecure.yaml
   

   Выпишите все нарушения из сообщения об ошибке и сопоставьте каждое с полем securityContext.

2. Наблюдение. Создайте Deployment с тем же образом и посмотрите, что произошло с подами:

   kubectl -n lab11-web create deployment web2 --image=nginx:1.31.7-alpine3.24
   kubectl -n lab11-web get deploy,rs,pods
   kubectl -n lab11-web describe rs -l app=web2 | tail -n 5
   

   Удалите метки warn с пространства имён (kubectl label ns lab11-web pod-security.kubernetes.io/warn- pod-security.kubernetes.io/warn-version-), удалите и создайте Deployment заново. Чем отличается вывод? Верните метки (kubectl apply -f manifests/30-web-namespace.yaml) и удалите web2.

3. Проверьте заранее, какие поды нарушили бы профиль в lab11, ничего не меняя:

   kubectl label --dry-run=server --overwrite ns lab11 pod-security.kubernetes.io/enforce=restricted
   

4. Примените исправленный под и проверьте, от какого пользователя работает nginx и можно ли писать в корневую файловую систему:

   kubectl apply -f manifests/32-web-restricted.yaml
   kubectl -n lab11-web wait --for=condition=Ready pod/web --timeout=120s
   kubectl -n lab11-web exec web -- id
   kubectl -n lab11-web exec web -- sh -c 'touch /etc/x; touch /tmp/x && echo tmp-ok'
   kubectl -n lab11-web exec web -- grep -E '^(CapEff|NoNewPrivs|Seccomp):' /proc/1/status
   kubectl -n lab11-web port-forward pod/web 8080:8080 >/dev/null & sleep 2
   curl -sI http://127.0.0.1:8080 | head -1; kill %1
   

5. Сломать и починить. По очереди внесите в копию 32-web-restricted.yaml одну из поломок, примените (предварительно удалив под), опишите симптом и место, где его видно (ответ apiserver, kubectl get pods, kubectl describe, kubectl logs), затем верните исправный вариант:

   • удалить том tmp и его монтирование;
   • заменить образ на nginx:1.31.7-alpine3.24 и порт на 80, остальное оставить;
   • удалить runAsUser и runAsGroup и заменить образ на собственный, в Dockerfile которого USER nginx (собирать не обязательно — опишите по лекции, что произойдёт и почему);
   • удалить seccompProfile.

Что должно получиться

В пункте 1 — ответ Error from server (Forbidden) вида:

pods "web" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false
(container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities
(container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or
container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx"
must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

В пункте 2 Deployment и ReplicaSet создаются, подов нет, в событиях ReplicaSet — FailedCreate с тем же списком нарушений. При метке warn kubectl create deployment печатает Warning: would violate PodSecurity ...; без неё — ничего. Это и есть ловушка «enforce без warn». В пункте 3 перечислены поды db, backend, frontend, api-client с их нарушениями, а метка не изменена.

В пункте 4 id показывает uid=101; touch /etc/x завершается ошибкой Read-only file system, запись в /tmp проходит; CapEff равно нулю, NoNewPrivs: 1, Seccomp: 2 (фильтр включён); nginx отвечает HTTP/1.1 200 OK. В пункте 5: без тома /tmp под уходит в CrashLoopBackOff, в журнале — ошибка nginx о невозможности создать каталог или pid-файл в /tmp из-за файловой системы только для чтения; с обычным образом nginx профиль формально соблюдён и под допускается, но уходит в CrashLoopBackOff: образ рассчитан на запуск от root, и в журнале видна первая из ошибок nginx — невозможность создать временный каталог в /var/cache/nginx на файловой системе только для чтения (а если её устранить томом — отказ открыть порт 80 без NET_BIND_SERVICE); точный текст возьмите из kubectl logs; с нечисловым USER и без runAsUser — CreateContainerConfigError с сообщением image has non-numeric user (nginx), cannot verify user is non-root; без seccompProfile под отклоняется apiserver на этапе допуска.

Часть 5. NetworkPolicy: default-deny для входящего трафика

Задание

1. Предсказание. Выполните kubectl -n lab11 exec backend -- pg_isready -h db -p 5432 -t 3. Почему команда не находит db, хотя под с таким именем работает? Создайте Service и повторите:

   kubectl -n lab11 expose pod db --port=5432
   kubectl -n lab11 get svc,endpointslices
   ./scripts/check-net.sh
   

2. Примените политику default-deny для входящего трафика. Предсказание: что покажет матрица для backend и frontend? Изменится ли DNS?

   kubectl apply -f manifests/40-np-default-deny-ingress.yaml
   ./scripts/check-net.sh
   

3. Добавьте разрешение backend → db и снова снимите матрицу:

   kubectl apply -f manifests/41-np-allow-backend-to-db.yaml
   kubectl -n lab11 describe netpol db-allow-from-backend
   ./scripts/check-net.sh
   

4. Измерьте, сколько длится отказ: time kubectl -n lab11 exec frontend -- pg_isready -h db -p 5432 -t 3. Почему клиент получает тайм-аут, а не немедленный отказ в соединении?

5. Проверка аддитивности. Создайте политику, разрешающую frontend → db на порт 5432, проверьте матрицу и удалите политику. Нужно ли было удалять db-allow-from-backend, чтобы новое разрешение заработало?

Что должно получиться

До создания Service имя db не разрешается: DNS-записи создаются для Service, а не для подов, созданных напрямую. После expose матрица — ok везде. После default-deny ingress — db:5432=FAIL по имени и по ClusterIP для обоих клиентов, dns=ok (входящий трафик к CoreDNS не ограничен: политика действует в lab11, а CoreDNS в kube-system). После разрешения — ok для backend, FAIL для frontend. Отказ длится около трёх секунд — тайм-аут pg_isready: Calico отбрасывает пакеты, а не отвечает TCP RST. Дополнительное разрешение работает без удаления существующего: политики объединяются по «или».

Часть 6. Исходящий трафик и починка DNS

Задание

1. Предсказание. Что сломается после применения default-deny для исходящего трафика? Будет ли работать соединение backend → db по ClusterIP? По имени?

   kubectl apply -f manifests/42-np-default-deny-egress.yaml
   ./scripts/check-net.sh
   kubectl -n lab11 exec backend -- nslookup db.lab11.svc.cluster.local
   

2. Разрешите DNS для всех подов пространства имён и снова снимите матрицу:

   kubectl apply -f manifests/43-np-allow-dns.yaml
   ./scripts/check-net.sh
   

3. Объясните, почему backend → db всё ещё не работает, хотя политика db-allow-from-backend есть. Примените недостающую политику и проверьте:

   kubectl apply -f manifests/44-np-allow-backend-egress-db.yaml
   ./scripts/check-net.sh
   

4. Проверьте, что backend не может выйти за пределы кластера: kubectl -n lab11 exec backend -- wget -q -T 3 -O /dev/null https://example.com; echo $?. Какую одну политику пришлось бы добавить, чтобы разрешить выход только на этот адрес, и почему для этого не подходит доменное имя?

Что должно получиться

После default-deny egress: dns=FAIL у обоих клиентов (nslookup печатает сообщение о тайм-ауте), db:5432=FAIL и по имени, и по ClusterIP — исходящие соединения запрещены целиком. После разрешения DNS: dns=ok, но db:5432=FAIL у backend — соединению нужны разрешения с обеих сторон, а egress-разрешения для backend ещё нет. После третьей политики: backend — ok везде, frontend — dns=ok, db:5432=FAIL. Внешний запрос завершается ошибкой (ненулевой код выхода). Для доступа к внешнему адресу нужна политика egress с ipBlock; стандартный NetworkPolicy не умеет выбирать по доменному имени, так как фильтрует пакеты по адресам, а адрес за именем может меняться.

Часть 7. Найдите ошибку в политике DNS

Задание

1. Замените политику DNS на «упрощённую» версию коллеги и снимите матрицу:

   kubectl apply -f manifests/90-broken-dns.yaml
   ./scripts/check-net.sh
   

2. Найдите в manifests/90-broken-dns.yaml две ошибки, не открывая 43-np-allow-dns.yaml: одну, из-за которой DNS не работает совсем, и одну, которая проявилась бы только на больших ответах. Объясните каждую.

3. Ещё один коллега предлагает исправление: добавить в список to отдельный элемент - namespaceSelector: {matchLabels: {kubernetes.io/metadata.name: kube-system}} рядом с существующим podSelector. Заработает ли DNS? Что ещё станет разрешено? Верните правильную политику 43-np-allow-dns.yaml.

Что должно получиться

DNS не работает: podSelector без namespaceSelector выбирает поды с меткой k8s-app=kube-dns в пространстве имён самой политики, то есть в lab11, где их нет. Вторая ошибка — разрешён только UDP, а DNS переходит на TCP при длинных ответах. Предложенное исправление включит DNS, но два элемента списка объединяются по «или», и политика разрешит соединения со всеми подами kube-system на порт 53; правильная форма — оба селектора в одном элементе.

Часть 8. Сканирование образов и конфигураций Trivy

Задание

Часть не требует кластера.

1. Зафиксируйте условия измерения: дату, trivy --version (версия программы и дата базы уязвимостей).

2. Предсказание. Для своего ряда образов предскажите, как изменится число уязвимостей CRITICAL и HIGH при каждом шаге, и какая переменная меняется на каждом шаге. Затем просканируйте ряд:

   mkdir -p reports
   trivy image --format json -o reports/1.json python:3.8-slim
   trivy image --format json -o reports/2.json python:3.12-slim
   trivy image --format json -o reports/3.json python:3.12-alpine
   trivy image --format json -o reports/4.json gcr.io/distroless/python3-debian13:nonroot
   python3 scripts/trivy-summary.py reports/*.json
   

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

4. Для второго образа ряда сравните отчёты с флагом --ignore-unfixed и без него (--severity HIGH,CRITICAL). Сколько уязвимостей исчезло и что это значит для того, кто поддерживает образ?

5. Проверьте Dockerfile и манифесты стенда:

   trivy config image/
   trivy config manifests/
   

   Для Dockerfile.bad объясните каждое замечание. Сравните число замечаний для 31-web-insecure.yaml и 32-web-restricted.yaml; какие замечания остались у пода, соответствующего профилю restricted, и требует ли их профиль?

6. Ворота CI. Выполните и запишите коды выхода:

   trivy config --exit-code 1 --severity HIGH,CRITICAL image/Dockerfile.bad; echo "код: $?"
   trivy config --exit-code 1 --severity HIGH,CRITICAL image/Dockerfile;     echo "код: $?"
   trivy image  --exit-code 1 --severity CRITICAL python:3.8-slim >/dev/null; echo "код: $?"
   trivy image  --exit-code 1 --severity CRITICAL --ignore-unfixed python:3.12-slim >/dev/null; echo "код: $?"
   

7. Сформируйте SBOM второго образа и найдите в нём пакет библиотеки OpenSSL (в Debian 13 он называется libssl3t64), затем просканируйте SBOM:

   trivy image --format cyclonedx --output reports/sbom.cdx.json python:3.12-slim
   grep -iE '"name": ?"libssl' reports/sbom.cdx.json | sort -u
   trivy sbom --severity HIGH,CRITICAL reports/sbom.cdx.json
   

Что должно получиться

Таблица «образ — ОС — CRITICAL — HIGH — всего — с исправлением» с датой и версией базы. Для ориентира — результаты автора для ряда А (Trivy 0.70.0, база от 21.10.2026, пакеты ОС): python:3.8-slim (Debian 12.7) — 9 CRITICAL, 116 HIGH, всего 505, из них 217 с исправленной версией; python:3.12-slim (Debian 13.7) — 0, 44, 164, с исправлением 0; python:3.12-alpine (Alpine 3.24.2) — 0, 0, 1; distroless на Debian 13.7 — 0, 26, 162. Ваши числа будут другими — это нормально и ожидаемо, важно, чтобы выводы опирались на ваши числа и условия.

Переход 3.8-slim → 3.12-slim меняет и версию Python, и версию Debian; переход к distroless с той же Debian 13.7 меняет только состав пакетов. С флагом --ignore-unfixed уязвимости со статусом affected (исправления нет) исчезают из отчёта — их невозможно устранить обновлением пакетов, и решать надо иначе (другой базовый образ, анализ применимости, явное исключение). Для Alpine неисправленные уязвимости не видны и без флага: база безопасности Alpine содержит только исправленные.

Для Dockerfile.bad — три замечания: DS-0002 (нет USER, HIGH), DS-0026 (нет HEALTHCHECK, LOW), DS-0029 (нет --no-install-recommends, HIGH); исправленный Dockerfile — без замечаний. Для 31-web-insecure.yaml — 17 замечаний, для 32-web-restricted.yaml — 4 (KSV-0011 нет лимита CPU, KSV-0020 и KSV-0021 UID и GID не больше 10000, KSV-0125 реестр не из списка доверенных); профиль restricted их не требует. Коды выхода: 1, 0, 1 и 0 (последний — если на дату работы в python:3.12-slim нет CRITICAL с выпущенным исправлением); любое расхождение объясните по отчёту.

Часть 9. Повышение привилегий через создание подов (продвинутая)

Задание

1. Создайте вторую учётную запись db-admin и секрет, к которому у notes-viewer нет доступа. Выдайте notes-viewer роль только с create на pods в lab11 и убедитесь, что auth can-i get secrets по-прежнему no.
2. От имени notes-viewer (запрос curl с её токеном, метод POST, тело — JSON-манифест пода) создайте под, который монтирует этот секрет как том, и прочитайте его журнал, где под печатает содержимое секрета. Для чтения журнала используйте права администратора.
3. Объясните, почему RBAC не помешал, и какие механизмы из темы могли бы помешать (подсказка: политики допуска, ограничивающие serviceAccountName и тома).

Что должно получиться

Под создан, содержимое секрета видно в журнале: право создавать поды в пространстве имён эквивалентно доступу ко всем его секретам и учётным записям. Ответ на пункт 3 — политика допуска (ValidatingAdmissionPolicy, Kyverno), запрещающая монтировать секреты и указывать чужие serviceAccountName, и разнесение чувствительных секретов в отдельное пространство имён.

Часть 10. Проверка подписи образа (продвинутая)

Задание

1. Установите cosign по документации Sigstore и выполните проверку подписи образа Kubernetes по инструкции страницы «Verify Signed Kubernetes Artifacts» документации Kubernetes (образ компонента той версии, что у вашего кластера; ожидаемая идентичность подписавшего и издатель OIDC указаны на странице).
2. Измените в команде ожидаемую идентичность на любую другую и повторите. Что изменилось?
3. Объясните, почему проверка выполняется по digest, а не по тегу, и где в цепочке поставки на рисунке темы такая проверка должна выполняться автоматически.

Что должно получиться

Первая проверка завершается успешно и выводит JSON с данными подписи; с неверной идентичностью — ошибка проверки сертификата и ненулевой код выхода. Подпись привязана к digest, тег можно перенаправить на другой образ; автоматическая проверка — на этапе допуска (Kyverno verifyImages или аналог). Эта часть составлена по документации и не прогонялась автором.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод и объяснение расхождения. Для частей 5–7 удобно вести матрицу check-net.sh после каждой применённой политики — по ней видно, какое изменение что сломало или починило. Для части 8 обязательно запишите дату, версию Trivy и дату базы: без них числа через неделю ничего не значат.

Контрольные вопросы

1. Почему kubectl apply для NetworkPolicy завершается успешно при CNI, не поддерживающем политики? Как убедиться, что политика действует?
2. Запрос с токеном получил 401, другой запрос — 403. На какой стадии конвейера apiserver произошёл каждый отказ и что надо менять в каждом случае?
3. Почему токен удалённого пода отклоняется до истечения срока действия? Какое поле токена делает это возможным?
4. Почему права list на секреты равносильны их чтению, а право создавать поды — правам всех учётных записей пространства имён?
5. Чем различаются режимы enforce, warn и audit Pod Security Admission? Почему Deployment с нарушающим шаблоном может создаться без единого сообщения?
6. Что именно проверяет runAsNonRoot: true и почему образ с USER app не проходит эту проверку? Какие два способа это исправить?
7. Зачем при readOnlyRootFilesystem: true нужен том emptyDir, и чем рискует приложение, если смонтировать его в корень /?
8. Почему после политики default-deny для исходящего трафика соединение по ClusterIP тоже перестаёт работать, а после разрешения DNS соединение backend → db всё ещё не работает?
9. Чем отличается политика с namespaceSelector и podSelector в одном элементе списка to от политики с двумя элементами? Приведите пример, где эта разница превращает узкое разрешение в широкое.
10. Почему сравнение python:3.8-slim с python:3.12-alpine не позволяет сделать вывод о влиянии дистрибутива на число уязвимостей? Как построить корректное сравнение?
11. Почему отчёт Trivy без даты и версии базы нельзя использовать для выводов, и что означает флаг --ignore-unfixed для ворот CI?
12. Под соответствует профилю restricted, но trivy config выдаёт для него замечания. Противоречие ли это?