{"id":13680225,"url":"https://github.com/Vinum-Security/kubernetes-security-checklist","last_synced_at":"2025-04-29T23:30:52.027Z","repository":{"id":41132658,"uuid":"416227460","full_name":"Vinum-Security/kubernetes-security-checklist","owner":"Vinum-Security","description":"Kubernetes Security Checklist and Requirements - All in One (authentication, authorization, logging, secrets, configuration, network, workloads, dockerfile)","archived":false,"fork":false,"pushed_at":"2021-12-13T07:39:53.000Z","size":114,"stargazers_count":450,"open_issues_count":5,"forks_count":88,"subscribers_count":15,"default_branch":"main","last_synced_at":"2024-02-15T03:34:23.570Z","etag":null,"topics":["checklist","cloud-native-security","container-security","devsecops","kubernetes","kubernetes-security","requirments","security"],"latest_commit_sha":null,"homepage":"https://www.vinumsec.com/devsecops","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Vinum-Security.png","metadata":{"files":{"readme":"README-RU.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2021-10-12T07:21:29.000Z","updated_at":"2024-02-13T11:02:03.000Z","dependencies_parsed_at":"2022-08-10T01:36:15.755Z","dependency_job_id":null,"html_url":"https://github.com/Vinum-Security/kubernetes-security-checklist","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Vinum-Security%2Fkubernetes-security-checklist","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Vinum-Security%2Fkubernetes-security-checklist/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Vinum-Security%2Fkubernetes-security-checklist/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Vinum-Security%2Fkubernetes-security-checklist/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Vinum-Security","download_url":"https://codeload.github.com/Vinum-Security/kubernetes-security-checklist/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":251599776,"owners_count":21615578,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["checklist","cloud-native-security","container-security","devsecops","kubernetes","kubernetes-security","requirments","security"],"created_at":"2024-08-02T13:01:14.465Z","updated_at":"2025-04-29T23:30:48.427Z","avatar_url":"https://github.com/Vinum-Security.png","language":null,"funding_links":[],"categories":["0 General","The Basics","security","General Resources","Others"],"sub_categories":[],"readme":"# Kubernetes Security Checklist and Requirements - All in One\n\n- **Аутентификация**\n  - [ ] Рекомендуется использовать сторонний IdP сервер в качестве стороннего провайдера для аутентификации пользователей в API Kubernetes (например, с использованием [OIDC](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens)). Администраторам кластера не рекомендуется использовать токены service account для аутентификации.\n  - [ ] Для управления сертификатами внутри кластера (пользовательские и сервисные) рекомендуется использовать сторонний централизованный сервис управления сертификатами.\n  - [ ] Пользовательские УЗ должны быть персонализированы. Названия сервисных УЗ должны отражать назначение УЗ и используемые права доступа.\n- **Авторизация**\n  - [ ] Для каждого кластера должна быть проработана ролевая модель доступа. \n  - [ ] Для кластера Kubernetes должен быть настроен Role-Based Access Control ([RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)). Права должны назначаться в пределах пространства имен проекта по принципу наименьших привилегий (least privilege) и разделения полномочий (seperation of duties) ([RBAC-tool](https://github.com/alcideio/rbac-tool)).\n  - [ ] Все сервисы должны обладать уникальным service account с настроенными правами RBAC.\n  - [ ] Разработчики не должны иметь доступ к препродуктивной и продуктивной среде без согласования с командой безопасности.\n  - [ ] Запрещено использовать средства [user impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) (возможность выполнять действия под другой УЗ).\n  - [ ] Запрещено использовать анонимную аутентификацию, кроме ```/healthz```, ```/readyz```, ```/livez```. Исключения должны согласовываться с командой безопасности.\n  - [ ] Администраторы кластера и функциональное сопровождение должны взаимодействовать с API кластера и инфраструктурными сервисами через решение контроля привилегированных пользователей ([Teleport](https://goteleport.com/docs/kubernetes-access/introduction/), [Boundary](https://www.hashicorp.com/blog/gating-access-to-kubernetes-with-hashicorp-boundary)).\n  - [ ] Все компоненты каждой информационной системы должны быть разделены на отдельные пространства имен (namespaces), при этом рекоммендуется избегать ситуации, когда одна и та же команда сопровождения ответственная за разные пространства имен.\n  - [ ] Права RBAC необходимо регулярно подвергать аудиту ([KubiScan](https://github.com/cyberark/KubiScan), [Krane](https://github.com/appvia/krane))\n- **Безопасная работа с секретами**\n  - [ ] Сформированные секреты храниться в защищенном стороннем хранилище ([HashiCorp Vault](https://www.vaultproject.io/docs/platform/k8s), [Conjur](https://www.conjur.org/blog/securing-secrets-in-kubernetes/)), либо в etcd в зашифрованном виде.\n  - [ ] Объекты типа \"secrets\" должны добавляться в контейнер с использованием механизма volumeMount или механизма secretKeyRef.  Для сокрытия секретов в исходных кодах может использоваться, например, инструмент [sealed-secret](https://github.com/bitnami-labs/sealed-secrets). \n- **Безопасность конфигурации кластера**\n  - [ ] Должно быть включено повсеместное использование шифрования TLS между компонентами кластера. \n  - [ ] Должно использоваться стороннее решение, поддерживающее механизм настраиваемых политик безопасности ([OPA](https://www.openpolicyagent.org/docs/v0.12.2/kubernetes-admission-control/), [Kyverno](https://kyverno.io/)).\n  - [ ] Конфигурацию кластера рекомендуется соответствовать [CIS Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) за исключением [требований к PSP](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). \n  - [ ] Рекомендуется использовать только последние версии компонентов кластера ([CVE list](https://www.container-security.site/general_information/container_cve_list.html)).\n  - [ ] Для сервисов с повышенными требованиями к безопасности рекомендуется использовать low-lever run-time с высокой степенью изоляцией ([gVisior](https://gvisor.dev/docs/user_guide/quick_start/kubernetes/), [Kata-runtime](https://github.com/kata-containers/documentation/blob/master/how-to/run-kata-with-k8s.md)).\n  - [ ] Конфигурация кластера должна регулярно подвергаться аудиту ([Kube-bench](https://github.com/aquasecurity/kube-bench), [Kube-hunter](https://github.com/aquasecurity/kube-hunter), [Kubestriker](https://www.kubestriker.io/))\n- **Логирование**\n  - [ ] Необходимо фиксировать все случаи изменения прав доступа в кластере.\n  - [ ] Необходимо фиксировать все операции с секретами (включая неавторизованный доступ к секретам). При этом фиксация значений секретов должна быть исключена.\n  - [ ] Необходимо фиксировать все действия администраторов сопровождения и администраторов кластера, связанных с развертыванием приложений и изменением их конфигурации.\n  - [ ] Необходимо фиксировать все случаи изменения параметров, системных настроек или конфигурации всего кластера. В том числе средствами на уровне ОС.\n  - [ ] Все зарегистрированные события безопасности, как на уровне кластера, так и на уровне приложения должны передаваться в централизованную систему аудита/логирования (SIEM).\n  - [ ] Используемая подсистема аудита должна быть расположена вне кластера Kubernetes.\n  - [ ] Выстроить процессы observability и visibility для того, чтобы понимать происходящее в инфраструктуре и сервисах([Luntry](https://luntry.com/), [WaveScope](https://github.com/weaveworks/scope))\n  - [ ] На всех нодах должно быть запущено стороннее решение для реализации мониторинга безопасности ([Falco](https://falco.org/), [Sysdig](https://sysdig.com/), [Aqua Enterpise](https://www.aquasec.com/), [NeuVector](https://neuvector.com/), [Prisma Cloud Compute](https://www.paloaltonetworks.com/prisma/cloud)).\n- **Безопасность конфигурации ОС**\n  - [ ] Администрирование хостов должно осуществляться через стороннее решение, логирующее действия пользователя (в т.ч. bastion host). Также может использоваться ОС без возможности удаленного подключения.\n  - [ ] Рекомендуется конфигурировать ОС и ПО в соответствии с baseline и стандартами ([CIS](https://www.cisecurity.org/cis-benchmarks/), [NIST](https://ncp.nist.gov/repository)).\n  - [ ] Рекомендуется регулярно сканировать пакеты на наличие уязвимостей([OpenSCAP профили](https://static.open-scap.org/), [Lynis](https://cisofy.com/lynis/)).\n  - [ ] Рекомендуется регулярно обновлять версию ядра ОС ([CVEhound](https://github.com/evdenis/cvehound)).\n- **Безопасность сети**\n  - [ ] Все пространства имен должны обладать NetworkPolicy. Взаимодействия между пространствами имен должны быть ограничены NetworkPolicy по принципам Least Privileges ([Inspektor Gadget](https://github.com/kinvolk/inspektor-gadget)).\n  - [ ] При организации микросервисного взаимодействия, рекомендуется, чтобы каждый сервис проходил аутентификацию и авторизацию ([Istio](https://platform9.com/blog/kubernetes-service-mesh-how-to-set-up-istio/), [Linkerd](https://platform9.com/blog/how-to-set-up-linkerd-as-a-service-mesh-for-platform9-managed-kubernetes/), [Consul](https://www.consul.io/docs/architecture)).\n  - [ ] Интерфейсы компонентов кластера и инструментов инфраструктуры запрещено публиковать в сети в Интернет.\n  - [ ] Инфраструктурные сервисы, control plane и хранилища данных должны быть расположены в отдельном VLAN на изолированных нодах.\n  - [ ] Внешний пользовательский трафик, проходящий внутрь кластера, должен инспектироваться с помощью WAF.\n  - [ ] Рекомендуется разделять ноды кластера, взаимодействующие с сетью Интернет (DMZ), от нод кластера, взаимодействующих с внутренними сервисами. Разграничение может быть в рамках одного кластера, либо в рамках двух разных кластеров (DMZ и VLAN).\n- **Безопасность конфигурации разворачиваемых приложений**\n  - [ ] Запрещено запускать поды под учетной записью [root](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - UID 0.\n  - [ ] Для всех сервисов должен быть установлен [параметр]((https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod)) ```runAsUser```.\n  - [ ] Должен быть выставлен [параметр](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) ```allowPrivilegeEscalation - false```.\n  - [ ] Запрещен запуск [привилегированного пода](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) (```privileged: true```).\n  - [ ] Рекомендуется выставлен [параметр](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) ```readonlyRootFilesystem - true```.\n  - [ ] [Запрещено](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#host-namespaces) использовать ```hostPID``` и ```hostIPC```.\n  - [ ] [Запрещено](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#host-namespaces) использовать ```hostNetwork```.\n  - [ ] [Запрещено](https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/) использование небезопасных системных вызовов (sysctl):\n    - ```kernel.shm*```,\n    - ```kernel.msg*```,\n    - ```kernel.sem```,\n    - ```fs.mqueue.*```,\n  - [ ] [Запрещено](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems) использовать ```hostPath```.\n  - [ ] Должны быть выставлены [ограничения](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) на CPU/RAM. Значения должны быть минимально достаточным для работы контейнеризированного приложения. \n  - [ ] [Capabilities](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) должны выдаваться по принципу наименьших привилегий (drop 'ALL', после чего перечисление всех необходимых сapabilities для работы приложения, при этом запрещено использовать:\n    - ```CAP_FSETID```,\n    - ```CAP_SETUID```,\n    - ```CAP_SETGID```,\n    - ```CAP_SYS_CHROOT```,\n    - ```CAP_SYS_PTRACE```,\n    - ```CAP_CHOWN```,\n    - ```CAP_NET_RAW```,\n    - ```CAP_NET_ADMIN```,\n    - ```CAP_SYS_ADMIN```,\n    - ```CAP_NET_BIND_SERVICE```)\n  - [ ] Запрещено использовать пространство имен по умолчанию (default).\n  - [ ] Приложение должно иметь профиль seccomp, apparmor или selinux по принципам least privileges ([Udica](https://github.com/containers/udica), [Oci-seccomp-bpf-hook](https://github.com/containers/oci-seccomp-bpf-hook), [Go2seccomp](https://github.com/xfernando/go2seccomp), [Security Profiles Operator](https://github.com/kubernetes-sigs/security-profiles-operator)).\n  -  [ ] Конфигурация приложений должна регулярно подвергаться аудиту ([Kics](https://checkmarx.com/product/opensource/kics-open-source-infrastructure-as-code-project/),  [Kubeaudit](https://github.com/Shopify/kubeaudit), [Kubescape](https://github.com/armosec/kubescape), [Conftest](https://github.com/open-policy-agent/conftest),  [Kubesec](https://github.com/controlplaneio/kubesec), [Checkov](https://github.com/bridgecrewio/checkov))\n- **Безопасная разработка образа**\n  - [ ] Запрещено использовать конструкцию ```RUN``` с ```sudo```.\n  - [ ] Рекомендуется не использовать тэг ```latest```.\n  - [ ] Вместо инструкции ```ADD``` требуется использовать ```COPY```. \n  - [ ] Запрещено использовать автоматическое обновление пакетов через ```apt-get upgrade```, ```yum update```, ```apt-get dist-upgrade```. \n  - [ ] Необходимо явно указывать версии устанавливаемых пакетов. Для определения перечня используемых пакетов могут использоваться инструменты для построения SBOM ([Syft](https://github.com/anchore/syft)).\n  - [ ] Запрещено хранить чувствительную информацию (пароли, токены, сертификаты) в Dockerfile.\n  - [ ] Состав пакетов в образе контейнера должен быть минимально достаточен для работы. Неиспользуемые в ходе работы контейнеризированного приложения пакеты должны отсутствовать в образе контейнера.\n  - [ ] Не рекомендуется устанавливать ```wget```, ```curl```, ```netcat```, внутри образа и контейнера продуктивного приложения.\n  - [ ] Состав пробрасываемых в контейнер портов должен быть минимально достаточен для работы. Неиспользуемые в ходе работы контейнеризированного приложения порты не должны использоваться в контейнере.\n  - [ ] Рекомендуется использовать ```dockerignore``` для предотвращения помещения чувствительной информации внутрь образа.\n  - [ ] Рекомендуется использовать минимальное количество слоев используя [многоступенчатую сборку](https://docs.docker.com/develop/develop-images/multistage-build/).\n  - [ ] Рекомендуется использовать ```WORKDIR``` в качестве абсолютного пути. Не рекомендуется использовать ```cd``` вместо ```WORKDIR```.\n  - [ ] При скачивании пакетов из Интернета в процессе сборки, рекомендуется проверять целостность этих пакетов. \n  - [ ] Рекомендуется остерегаться рекурсивного копирование с помощью конструкции ```COPY . .```\n  - [ ] Запрещено запускать средства удаленного управления в контейнере.\n  - [ ] По результатам сканирования образов Docker должна формироваться подпись образа, которая будет проверяться перед развертыванием ([Notary, Cosign](https://medium.com/sse-blog/verify-container-image-signatures-in-kubernetes-using-notary-or-cosign-or-both-c25d9e79ec45)).\n  - [ ] Dockerfile должны проверяться в процессе разработки автоматизированными сканнерами ([Kics](https://checkmarx.com/product/opensource/kics-open-source-infrastructure-as-code-project/), [Hadolint](https://github.com/hadolint/hadolint), [Conftest](https://github.com/open-policy-agent/conftest)).\n  - [ ] Все образы должны проверяться в жизненном цикле приложения автоматизированными сканнерами ([Trivy](https://github.com/aquasecurity/trivy), [Clair](https://github.com/quay/clair), [Grype](https://github.com/anchore/grype)). \n  - [ ] Должна быть выстроена безопасность CI и CD, а также безопасность цепочки поставок([SLSA](https://github.com/slsa-framework/slsa))\n\n#\n\u003ca href=\"https://kubernetes.io/\"\u003e\n    \u003cimg src=\"https://upload.wikimedia.org/wikipedia/commons/thumb/8/83/Telegram_2019_Logo.svg/1200px-Telegram_2019_Logo.svg.png\"\n         alt=\"Kubernetes logo\" title=\"Kubernetes\" height=\"50\" width=\"50\" /\u003e\n\u003c/a\u003e\u003c/br\u003e\n\n\n## Полезный контент\n- Обсуждение на тему безопасности Kubernetes можно продолжить в нашем Telegram-чате: [DevSecOps Chat](https://t.me/sec_devops_chat)\n- Канал автора чеклиста: [DevSecOps Wine](https://t.me/sec_devops)\n- Чеклист был подготовлен при поддержке автора канала [k8security](https://t.me/k8security)\n\n\n\n\n\n\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FVinum-Security%2Fkubernetes-security-checklist","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FVinum-Security%2Fkubernetes-security-checklist","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FVinum-Security%2Fkubernetes-security-checklist/lists"}