Это многостраничный печатный вид этого раздела. Нажмите что бы печатать.
Проблемы и безопасность Kubernetes
1 - Трекер задач (Issues) Kubernetes
Чтобы сообщить о проблеме в области безопасности, воспользуйтесь процедурой раскрытия информации о безопасности Kubernetes.
Механизм GitHub Issues позволяет работать с кодом Kubernetes и отслеживать активные задачи.
- Официальный список известных CVE (уязвимостей в области безопасности), которые были обнародованы Комитетом по реагированию на угрозы в области безопасности Kubernetes.
- Issues на GitHub, связанные с CVE
Связанные с безопасностью анонсы публикуются в рассылке kubernetes-security-announce@googlegroups.com.
2 - Общие сведения о безопасности Kubernetes и раскрытии информации
На этой странице приводятся общие сведения о безопасности Kubernetes и раскрытии информации, имеющей к ней отношение.
Анонсы в области безопасности
Информация о проблемах в области безопасности и ключевых изменениях API доступна в рассылке kubernetes-security-announce.
Сообщить об уязвимости
Мы искренне признательны исследователям в области безопасности и пользователям, которые передают информацию об уязвимостях в Open Source-сообщество Kubernetes. Все отчеты тщательно изучаются группой добровольцев сообщества.
Чтобы создать отчет, отправьте свою уязвимость в Bug Bounty-программу Kubernetes. Это позволит отследить и обработать уязвимость в стандартные сроки.
Также можно оправить стандартное письмо об ошибках Kubernetes с описанием проблемы с безопасностью и ее подробностями в закрытый список security@kubernetes.io.
Письмо можно зашифровать, используя GPG-ключи членов Комитета по безопасности. Шифрование с использованием GPG НЕ является обязательным.
Когда следует сообщать об уязвимости
- Вы думаете, что обнаружили уязвимость в безопасности Kubernetes.
- Вы не уверены, как именно уязвимость повлияет на Kubernetes.
- Вы думаете, что обнаружили уязвимость в другом проекте, от которого зависит работа Kubernetes.
- Если у проекта имеется собственный регламент регистрации и раскрытия информации об уязвимостях, пожалуйста, следуйте ему и пишите сразу в проект.
Когда НЕ следует сообщать об уязвимости
- Вам нужна помощь в настройке компонентов Kubernetes для обеспечения безопасности.
- Вам нужна помощь в применении обновлений, связанных с безопасностью.
- Проблема не связана с безопасностью.
Реагирование на уязвимости в области безопасности
Каждый отчет об уязвимости подтверждается и анализируется членами Комитета по реагированию на угрозы безопасности в течение 3 рабочих дней. После этого запускается соответствующая процедура.
Любая информация об уязвимостях, переданная Комитету по реагированию на угрозы безопасности, остается внутри проекта Kubernetes и не передается в другие проекты, если только этого не требуется для устранения проблемы.
Автору отчета будет сообщено о результатах триажа и дальнейших шагах по подготовке исправления и планированию релиза.
Сроки раскрытия информации
Дата публичного раскрытия согласовывается Комитетом по реагированию на угрозы безопасности Kubernetes и автором отчета об уязвимости. Мы предпочитаем полностью раскрывать информацию об обнаруженной проблеме сразу после того, как станет понятно, какие шаги необходимо предпринять для устранения ее последствий. Разумно отложить раскрытие информации, если проблема или порядок дальнейших шагов не до конца понятны, решение плохо протестировано или необходима координация действий вендоров. Срок раскрытия информации варьируется от незамедлительного (особенно если она уже широко известна) до нескольких недель. Для "простых" уязвимостей с момента подачи отчета до даты раскрытия обычно проходит около 7 дней. Комитет по реагированию на угрозы безопасности сохраняет последнее слово при определении даты раскрытия информации.
3 - Официальный CVE-фид
Kubernetes v1.27 [beta]
Поддерживаемый сообществом список официальных CVE, анонсированных Комитетом по реагированию на проблемы безопасности Kubernetes. Подробности см. на странице Общие сведения о безопасности Kubernetes и раскрытии информации.
Проект Kubernetes публикует фиды с анонсами проблем в области безопасности в формате JSON и RSS, доступные для автоматического считывания. Доступ к ним можно получить, выполнив следующие команды:
curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json
curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml
CVE ID | Описание проблемы | CVE GitHub Issue URL |
---|---|---|
CVE-2024-7646 | Ingress-nginx Annotation Validation Bypass | #126744 |
CVE-2024-5321 | Incorrect permissions on Windows containers logs | #126161 |
CVE-2024-3744 | azure-file-csi-driver discloses service account tokens in logs | #124759 |
CVE-2024-3177 | Bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | #124336 |
CVE-2023-5528 | Insufficient input sanitization in in-tree storage plugin leads to privilege escalation on Windows nodes | #121879 |
CVE-2023-5044 | Code injection via nginx.ingress.kubernetes.io/permanent-redirect annotation | #126817 |
CVE-2023-5043 | Ingress nginx annotation injection causes arbitrary command execution | #126816 |
CVE-2022-4886 | ingress-nginx path sanitization can be bypassed | #126815 |
CVE-2023-3955 | Insufficient input sanitization on Windows nodes leads to privilege escalation | #119595 |
CVE-2023-3893 | Insufficient input sanitization on kubernetes-csi-proxy leads to privilege escalation | #119594 |
CVE-2023-3676 | Insufficient input sanitization on Windows nodes leads to privilege escalation | #119339 |
CVE-2023-2431 | Bypass of seccomp profile enforcement | #118690 |
CVE-2023-2728 | Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | #118640 |
CVE-2023-2727 | Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin | #118640 |
CVE-2023-2878 | secrets-store-csi-driver discloses service account tokens in logs | #118419 |
CVE-2022-3294 | Node address isn't always verified when proxying | #113757 |
CVE-2022-3162 | Unauthorized read of Custom Resources | #113756 |
CVE-2022-3172 | Aggregated API server can cause clients to be redirected (SSRF) | #112513 |
CVE-2021-25749 | `runAsNonRoot` logic bypass for Windows containers | #112192 |
CVE-2021-25748 | Ingress-nginx `path` sanitization can be bypassed with newline character | #126814 |
CVE-2021-25746 | Ingress-nginx directive injection via annotations | #126813 |
CVE-2021-25745 | Ingress-nginx `path` can be pointed to service account token file | #126812 |
CVE-2021-25742 | Ingress-nginx custom snippets allows retrieval of ingress-nginx serviceaccount token and secrets across all namespaces | #126811 |
CVE-2021-25741 | Symlink Exchange Can Allow Host Filesystem Access | #104980 |
CVE-2021-25737 | Holes in EndpointSlice Validation Enable Host Network Hijack | #102106 |
CVE-2021-3121 | Processes may panic upon receipt of malicious protobuf messages | #101435 |
CVE-2021-25735 | Validating Admission Webhook does not observe some previous fields | #100096 |
CVE-2020-8554 | Man in the middle using LoadBalancer or ExternalIPs | #97076 |
CVE-2020-8566 | Ceph RBD adminSecrets exposed in logs when loglevel >= 4 | #95624 |
CVE-2020-8565 | Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9 | #95623 |
CVE-2020-8564 | Docker config secrets leaked when file is malformed and log level >= 4 | #95622 |
CVE-2020-8563 | Secret leaks in kube-controller-manager when using vSphere provider | #95621 |
CVE-2020-8557 | Node disk DOS by writing to container /etc/hosts | #93032 |
CVE-2020-8559 | Privilege escalation from compromised node to cluster | #92914 |
CVE-2020-8558 | Node setting allows for neighboring hosts to bypass localhost boundary | #92315 |
CVE-2020-8555 | Half-Blind SSRF in kube-controller-manager | #91542 |
CVE-2020-10749 | IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements | #91507 |
CVE-2019-11254 | kube-apiserver Denial of Service vulnerability from malicious YAML payloads | #89535 |
CVE-2020-8552 | apiserver DoS (oom) | #89378 |
CVE-2020-8551 | Kubelet DoS via API | #89377 |
CVE-2020-8553 | ingress-nginx auth-type basic annotation vulnerability | #126818 |
CVE-2019-11251 | kubectl cp symlink vulnerability | #87773 |
CVE-2018-1002102 | Unvalidated redirect | #85867 |
CVE-2019-11255 | CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation | #85233 |
CVE-2019-11253 | Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack | #83253 |
CVE-2019-11250 | Bearer tokens are revealed in logs | #81114 |
CVE-2019-11248 | /debug/pprof exposed on kubelet's healthz port | #81023 |
CVE-2019-11249 | Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal | #80984 |
CVE-2019-11247 | API server allows access to custom resources via wrong scope | #80983 |
CVE-2019-11245 | container uid changes to root after first restart or if image is already pulled to the node | #78308 |
CVE-2019-11243 | rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig() | #76797 |
CVE-2019-11244 | `kubectl:-http-cache=<world-accessible dir>` creates world-writeable cached schema files | #76676 |
CVE-2019-1002100 | json-patch requests can exhaust apiserver resources | #74534 |
CVE-2018-1002105 | proxy request handling in kube-apiserver can leave vulnerable TCP connections | #71411 |
CVE-2018-1002101 | smb mount security issue | #65750 |
CVE-2018-1002100 | Kubectl copy doesn't check for paths outside of it's destination directory. | #61297 |
CVE-2017-1002102 | atomic writer volume handling allows arbitrary file deletion in host filesystem | #60814 |
CVE-2017-1002101 | subpath volume mount handling allows arbitrary file access in host filesystem | #60813 |
CVE-2017-1002100 | Azure PV should be Private scope not Container scope | #47611 |
CVE-2017-1000056 | PodSecurityPolicy admission plugin authorizes incorrectly | #43459 |
Список автоматически обновляется с заметной, но небольшой задержкой (от нескольких минут до нескольких часов) с момента анонса CVE до момента его появления в этом фиде.
В качестве источника используется набор GitHub Issues, отфильтрованный по контролируемому и
ограниченному лейблу official-cve-feed
. Исходные данные хранятся в бакете Google Cloud,
право на запись в который есть только у небольшого числа доверенных представителей сообщества.