Це багатосторінковий друкований вигляд цього розділу. Натисність щоб друкувати.
Безпека та проблеми Kubernetes
1 - Трекер проблем Kubernetes
Для повідомлення про проблему безпеки використовуйте Процес розкриття інформації про безпеку в Kubernetes.
Робота з кодом Kubernetes та публічними проблемами відстежуватися за допомогою GitHub Issues.
- Офіційний список відомих CVE (вразливості безпеки), які були оголошені Комітетом з питань реагування на загрози безпеці
- Тікети на GitHub, повʼязані з CVE
Повідомлення про безпеку надсилаються у список розсилки kubernetes-security-announce@googlegroups.com.
2 - Процес розкриття інформації про безпеку в Kubernetes
Ця сторінка описує процес розкриття інформації про безпеку в Kubernetes.
Оголошення з питань безпеки
Приєднуйтесь до групи kubernetes-security-announce, щоб отримувати електронні листи щодо безпеки та основних оголошень API.
Повідомлення про вразливості
Ми дуже вдячні фахівцям з безпеки та користувачам, які повідомляють про вразливості Kubernetes Open Source Community. Всі звіти ретельно розглядаються командою волонтерів спільноти.
Для повідомлення про вразливість подайте свій звіт у Програму винагородження за виправлення помилок у Kubernetes. Це дозволяє класифікувати та обробляти вразливість за стандартизованими часовими рамками відповіді.
Ви також можете надіслати електронного листа на приватну адресу security@kubernetes.io з деталями щодо безпеки та необхідними деталями для всіх звітів про помилки Kubernetes.
Ви можете зашифрувати свій лист для цього списку за допомогою GPG-ключів членів комітету з питань реагування на загрози безпеці. Шифрування за допомогою GPG НЕ є обовʼязковим для повідомлення про проблеми з безпекою.
Коли потрібно повідомляти про вразливість?
- Ви вважаєте, що виявили потенційну вразливість в Kubernetes
- Ви не впевнені, як вразливість впливає на Kubernetes
- Ви вважаєте, що виявили вразливість в іншому проєкті, від якого залежить Kubernetes
- Для проєктів з власним процесом повідомлення про вразливості та розкриттям відповідних відомостей, будь ласка, повідомте про це безпосередньо туди
Коли НЕ потрібно повідомляти про вразливість?
- Вам потрібна допомога у налаштуванні компонентів Kubernetes для безпеки
- Вам потрібна допомога з застосуванням оновлень, повʼязаних з безпекою
- Ваша проблема не стосується безпеки
Реагування на вразливості безпеки
Кожне повідомлення отримує відповідь та аналіз від членів комітету з питань реагування на загрози безпеці протягом 3 робочих днів. Це ініціює Security Release Process.
Будь-яка інформація про вразливість, що надходить до Комітету, залишається в проєкті Kubernetes і не буде розповсюджуватися до інших проєктів, якщо це необхідно для виправлення проблеми.
В міру того, як повідомлення про проблеми безпеки переходить з етапу попереднього розгляду, визначення шляхів виправлення та планування випуску, ми будемо тримати особу, що повідомила про проблему, в курсі подій.
Терміни оприлюднення інформації
Дата публічного оприлюднення узгоджується Комітетом з реагування на проблеми безпеки Kubernetes та автором повідомлення про ваду. Ми надаємо перевагу повному розкриттю вади якомога швидше, як тільки користувачеві буде доступне рішення для її усунення. Доцільно затримати розкриття, коли помилка або виправлення ще не до кінця зрозумілі, рішення ще не добре протестоване, або для узгодження з постачальником. Часові рамки для розкриття інформації — від негайного (особливо якщо вона вже відома загалу) до декількох тижнів. Для вразливостей, які легко усунути, ми очікуємо, що від дати повідомлення до дати розкриття буде близько 7 днів. Комітет з реагування на вразливості Kubernetes має вирішальне слово при встановленні дати оприлюднення.
3 - Офіційний список CVE
Kubernetes v1.27 [beta]Це список офіційних CVE, оголошених Комітетом з питань реагування на загрози безпеці Kubernetes. Детальніше дивіться в Процес розкриття інформації про безпеку в Kubernetes.
Проєкт Kubernetes публікує програмно доступний потік опублікованих проблем безпеки у форматах JSON feed та RSS feed. Ви можете отримати до них доступ, виконавши наступні команди:
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 |
|---|---|---|
| CVE-2024-10220 | Arbitrary command execution through gitRepo volume | #128885 |
| CVE-2024-9594 | VM images built with Image Builder with some providers use default credentials during builds | #128007 |
| CVE-2024-9486 | VM images built with Image Builder and Proxmox provider use default credentials | #128006 |
| 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, до якого мають доступ лише декілька довірених членів спільноти.