Комментарии 7
Как будто эти сесурити что-то знают. Обычный сисадмин их за пояс заткнет по знаниям/опыту.
Таким образом, «Always» позволяет: защититься от злонамеренной подмены локальных образов на хосте
Неа. Можно поменять конкретные файлы в уже скачанном образе и никто ничего не заметит.
Насколько я понимаю, тут есть тонкий момент: с точки зрения Kubelet, любое изменение хэша должно приводить к загрузке "правильного"/нового образа с registry при старте/рестарте пода. Т.е. в момент, когда собственно и производиться проверка хэша образа.
Например, см. здесь ссылки на код Kuberentes https://github.com/kubernetes/kubernetes/issues/116867#issuecomment-2091119480
При этом, как справедливо отмечено здесь https://rx-m.com/kubernetes-image-pull-policy/ и, отчасти, в https://github.com/kubernetes/kubernetes/issues/116867
The container runtime will reconcile the image digest to ensure the most up-to-date image is used
By “always” downloading and reconciling the image manifest against the local cache, Kubernetes guarantees it always has the latest version of the image
обеспечивать реконсиляцию хэша должен container runtime. Которым для большинства новых инсталляция является containerd, точнее говоря cri.
К сожалению, мне не удалось найти, обладает ли containerd механизмом для принудительного пересчёта хэша образа. Вероятно, что нет, если полагать, что хэш образа в нормальных условиях рассчитывается только в процессе сборки образа. А containerd встроенными средства сборки не обладает.
Возможно, для гаратированной защиты от подмены образа требуется механика подписи образов, доступная на текущий момент в CRI-O https://kubernetes.io/blog/2023/06/29/container-image-signature-verification/
Это всё работает только на этапе скачивания. Уже скачанные и распакованные на диск файлы из образа не проверяются никак: https://github.com/containerd/containerd/issues/8678
В CRI-O, видимо, озадачились проблемой https://github.com/cri-o/cri-o/pull/9060 проверки образа непосредственно перед созданием контейнера.
С учётом механики подписи образов, возможно, это первое полноценное решение.
Как видно, requests игнорируются на этапе перехода к низкоуровневой спецификации — для них нет соответствующих сущностей ядра.
В прошлом разделе показано, что у requests нет пары в ядре Linux. Это не требуется, так как requests только сообщают планировщику о потребности контейнера (и управляющего им пода) в ресурсах.
Это не так. В cgroup контейнера есть параметр, который зависит от его requests.cpu – cpu.weight. Этот параметр отвечает за общий "вес" процессов в контейнере, который включается в игру, когда на ноде близкое к 100% потребление CPU, и планировщику linux нужно определить какому контейнеру (процессу в контейнере) сколько процессорного времени должно доставаться.
Наличие этого параметра так же означает, что даже при отсутствии лимитов на CPU у подов на ноде, в случае появления шумного соседа, забирающего себе всё CPU ноды, другие контейнеры, требующие в это время CPU, как минимум не будут получать его меньше, чем прописано в их requests.cpu. По крайней мере так должно быть и у меня в своё время не получилось добиться ситуации, в которой контейнер при "борьбе за cpu" получал бы его меньше, чем прописано в его реквестах :).
Вот тут можно почитать про это, но советую после статьи самому на тестовом кластере поэкспериментировать.
Большое спасибо за уточнение, это ценный комментарий - корректировки в статью внесены, чтобы не вводить в заблуждение возможных будущих читателей.
У меня были смутные воспоминания насчёт наличия механизма гарантированного обеспечения процессорного времени, заданного в requests. Но увы, при подготовке статьи проверка по источникам оказалась недостаточной - предложенного материала обнаружено не было. Здорово, что благодаря этому дополнению удалось исправить ошибку хотя бы сейчас.
Безопасность подов: взгляд пользователя K8s