Security для Application

Что нужно знать перед уроком

M1 урок 11 — базовая модель RBAC Kubernetes. Этот урок разбирает специфичную для Deckhouse иерархию ролей уровня namespace, NetworkPolicy и Pod Security Standards применительно к Application.

Теория

Иерархия namespace-ролей d8:use:role:*

Deckhouse предоставляет четыре встроенные ClusterRole, предназначенные именно для использования в namespace-scoped RoleBinding (не ClusterRoleBinding) — каждая следующая роль включает права предыдущей плюс дополнительные:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: myapp-developer
  namespace: myapp
subjects:
  - kind: User
    name: app-developer@example.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: d8:use:role:admin
  apiGroup: rbac.authorization.k8s.io

Обратите внимание: даже d8:use:role:admin — это администрирование namespace, а не кластера в целом — типичный разработчик Application, которому предоставлена эта роль в своём namespace, может управлять RBAC/ResourceQuota/NetworkPolicy внутри своего namespace, но не имеет доступа к cluster-wide ресурсам (ModuleConfig, ClusterRole за пределами namespace, узлы кластера) — это архитектурно согласуется с ограничением «Application зависит только от Module, не создаёт cluster-wide ресурсов» из M5 урока 5.

NetworkPolicy — сетевая изоляция на уровне namespace

Стандартный Kubernetes-ресурс, доступный для управления в рамках роли d8:use:role:admin:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: {{.Application.Instance.Name}}-allow-internal
  namespace: {{.Release.Namespace}}
spec:
  podSelector:
    matchLabels:
      app: {{.Application.Instance.Name}}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: {{.Release.Namespace}}

podSelector — к каким подам применяется политика; namespaceSelector/podSelector внутри from/to — источники/назначения разрешённого трафика; ipBlock — разрешение/запрет по CIDR-диапазону IP-адресов (для взаимодействия с внешними, не-Kubernetes системами).

CiliumClusterwideNetworkPolicy — расширенные возможности при cni-cilium

При использовании CNI-плагина Cilium (одна из опций сетевого стека Deckhouse) доступен более выразительный CRD CiliumClusterwideNetworkPolicy, поддерживающий L7-политики (например, разрешение только конкретных HTTP-методов/путей, а не просто L3/L4 трафика в целом). Важная деталь для безопасного внедрения: policyAuditMode — режим, в котором политика логирует нарушения, но не блокирует трафик — позволяет протестировать корректность новой, потенциально строгой политики на реальном трафике production-окружения перед переключением в режим полного применения, избегая риска случайно заблокировать легитимный трафик собственной непроверенной политикой.

Pod Security Standards через лейбл namespace

1

d8 k label ns my-namespace security.deckhouse.io/pod-policy=restricted

Простой, декларативный способ применения профиля Pod Security Standards (restricted — самый строгий из стандартных профилей Kubernetes, запрещающий privileged-контейнеры, требующий non-root, ограничивающий capabilities) ко всем подам конкретного namespace через один лейбл. Это защитный механизм платформы, применимый администратором к namespace приложения (или самим разработчиком, если у него есть права manager/admin уровня namespace) — гарантирует, что даже случайно написанный шаблон, запрашивающий избыточные привилегии контейнера, будет отклонён на уровне admission control, не дойдя до реального запуска.

Частые ошибки и подводные камни

• Ожидать, что d8:use:role:admin даёт доступ к cluster-wide ресурсам. Это исключительно namespace-scoped администрирование — попытка использовать её через ClusterRoleBinding вместо RoleBinding не даст ожидаемого cluster-wide эффекта (хотя технически может быть неправильно применена — важно использовать именно RoleBinding в конкретном namespace).
• Внедрять новую CiliumClusterwideNetworkPolicy сразу в режиме полного применения, без предварительного policyAuditMode. Риск случайно заблокировать легитимный трафик собственного приложения из-за неучтённого сценария коммуникации значительно выше без предварительного тестового периода.
• Не применять security.deckhouse.io/pod-policy=restricted к namespace production-приложения. Без этого защитного барьера случайная ошибка в шаблоне (например, забытый securityContext.runAsNonRoot: false по умолчанию) не будет заблокирована на уровне admission control.

Практика в кластере

1
2
3

d8 k get rolebinding -n course-m10-umami
d8 k auth can-i delete secrets -n course-m10-umami --as=app-developer@example.com
d8 k label ns course-m10-umami security.deckhouse.io/pod-policy=restricted --dry-run=server

Проверьте через d8 k auth can-i, какие конкретные права предоставляет каждая из четырёх d8:use:role:* ролей в вашем практическом namespace.

Практика разработки

Добавьте в пакет Umami NetworkPolicy, разрешающую входящий трафик только из того же namespace и от Ingress-контроллера, полностью изолируя приложение от произвольного трафика из других namespace кластера.

Шпаргалка команд урока

1
2

d8 k auth can-i <verb> <resource> -n <namespace> --as=<user>
d8 k label ns <namespace> security.deckhouse.io/pod-policy=restricted

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

Рекомендуемая литература

Официальная документация

• Deckhouse — Экспериментальная RBAC-модель (Use roles)
• Deckhouse — Политики безопасности
• kubernetes.io — Using RBAC Authorization

Статьи и блоги

• Основные концепции сетевой архитектуры Kubernetes (RBAC, ServiceAccount) — Habr.
• Deckhouse Prom++: оптимизация Prometheus — Flant на Habr.
• Kubernetes на базе Deckhouse: встроенный мониторинг и логирование — обзор возможностей DKP на Habr.

Книги

• Brendan Burns, David Oppenheimer. Designing Distributed Systems. 2018. ISBN 978-1491983645.
• Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.

Связанные материалы

• Предыдущий урок: M10.08 — Backup: что действительно бэкапится, а что нет.
• Следующий урок: M10.10 — Troubleshooting по статусной модели.

✓ Урок пройден — все вопросы самопроверки отвечены верно