RBAC — управление доступом

• Принцип: минимально необходимые привилегии. Все роли (Role/ClusterRole) проектируются под конкретные задачи (verbs, resources, apiGroups), не давайте * без крайней нужды.

• Разделение прав: использовать namespaced Role + RoleBinding для приложений и операторов, а ClusterRoleBinding — только для действительно кластерных сервисов. Проверять и ревьювить binding’и (особенно ClusterRoleBinding).

• ServiceAccount как субъект: каждое приложение получает отдельный ServiceAccount; не использовать default для production. Автоматически выдавленные токены — отключать (automountServiceAccountToken: false) где не нужны.

• Группы и внешняя аутентификация: подключать OIDC/SSO (IdP) для людей, использовать группы для упрощения RBAC (например, devs, oncall, infra-admins).

• Политики управления привилегиями: запрет прямых привилегированных контейнеров и hostPath через admission; применять ограничительные RoleBindings через CI/CD review.

• Аудит и ревизия: включить Audit Logs на API-сервере; регулярно проводить ревизию ролей и привязок, удалять неиспользуемые bindings.

Network Policies — сегментация и защита East-West

• По умолчанию → default-deny: для каждого namespace сначала определить политику, блокирующую всё (Ingress/Egress), затем постепенно открывать только нужные пути.

• Правила специфицируются по podSelector, namespaceSelector, ipBlock и портам; комбинировать для точного разрешения трафика между компонентами.

• Разделение зон: использовать topologyKey/namespace для ограничений между окружениями (prod/test).

• Точка контроля: убедиться, что CNI поддерживает NetworkPolicy (Cilium/Calico/Cilium eBPF дают расширенные возможности — e.g. L7, DNS policy, mTLS).

• Egress контроль: закрыть исходящий трафик по умолчанию, позволить доступ к внешним сервисам через egress-gateway/Proxy, логировать запросы.

• Тестирование и симуляция: проверять политики интеграционными тестами (debug pods), обеспечить мониторинг отказов сетевых соединений.

Secrets management — хранение, ротация, защита

• Не хранить в Git в открытом виде. Для декларативных нужд использовать зашифрованные хранилища (SOPS) или SealedSecrets.

• Хранение в кластере: включить encryption at rest для etcd (encryptionConfiguration) с использованием KMS (cloud KMS/HSM) для хранения ключей; шифрование снимков etcd и бэкапов.

• Внешние хранилища: использовать Vault / AWS Secrets Manager / GCP Secret Manager / Azure Key Vault + Kubernetes External Secrets или CSI Secrets Store Provider для безопасной интеграции и ротации секретов.

• Короткоживущие токены: применять projected service account tokens (TokenRequest) с ограниченной аудиторией и TTL вместо бессрочных токенов, где возможно.

• Ротация и lifecycle: автоматизировать ротацию секретов и ключей, реворкать зависимости приложений и обновлять mounted secrets без логаута пользователей.

• Ограничение доступа: настроить RBAC для чтения Secret ресурсов; минимизировать get/list привилегии для учетных записей и CI.

• Мониторинг и аудит: логировать обращения к секретам, оповещать о подозрительных запросах и failed attempts.

Дополнительные меры безопасности (операционный слой)

• Admission controllers & policy engines: включать PodSecurity (restricted/baseline), NodeRestriction, и использовать OPA/Gatekeeper или Kyverno для организационных правил (deny privileged, enforce image provenance, required labels).

• Image security: приватный registry, image scanning в CI, подпись образов (cosign) и enforce в admission.

• Runtime protection: использовать Falco/Runtime security для детекции подозрительных действий (exec, write to sensitive paths), включать SELinux/AppArmor/seccomp и drop CAPs.

• Хостовая безопасность: минимальный хост-OS, регулярные патчи, изоляция control-plane (ограниченный доступ по сети), kubelet TLS и NodeRestriction.

• Сегментация и инфраструктурные firewall: внешние ACL/NSG, ограниченный доступ к API server (private endpoint, API whitelisting, bastion), VPN/Zero Trust для админов.

• Backup & DR: шифровать и ограничивать доступ к etcd-snapshots и backup-репозиториям; тестировать восстановления.

Процессы и культура

• Политика «least privilege», регулярные ревью прав, CI проверки политик при PR, автоматизированные тесты NetworkPolicy и Secret-rotation.

• On-call и runbooks для инцидентов безопасности, регулярные учения по восстановлению и проверке ротации ключей.