k8s (in)security

Если вам мало CRI,CNI,CSI,CDI,CMI,CPI, то встречайте еще один интерфейс в Kubernetes под названием NRI.

NRI - это Node Resource Interface. По сути это механизм плагинов, позволяющий расширять возможности containerd с 1.7 и CRI-O c 1.26. Можно добавить собственную логику, которая будет выполняться в такие моменты жизни Pods как run, stop, remove и контейнеров как creation, post-creation, starting, post-start, updating, post-update, stopping, removal.

В первую очередь это было создано для более низкоуровневой, эффективной работы с ресурсами и устройствами, на пример, которых нельзя описать просто OCI спецификацией. Это может быть очень полезно облачным провайдерам или тем кто контролирует все свое железо и хочет заточится по его специфику. Примеры можно посмотреть тут и тут.

Также отдельно отметим очень высокий уровень критичности данного компонента, который по сути разливается привилегированным daemonset - при написании подобного помните о безопасности.

P.S. В процессе изучения данной темы был найден интересный показательный проект Koordinator (QoS-based scheduling), на котором можно проследить эволюцию подходов к управлению ресурсами в K8s.

www.tgoop.com/k8security/1384

4.1K viewsДмитрий Евдокимов, Dec 3 at 05:04

Если вам мало CRI,CNI,CSI,CDI,CMI,CPI, то встречайте еще один интерфейс в Kubernetes под названием NRI.

NRI - это Node Resource Interface. По сути это механизм плагинов, позволяющий расширять возможности containerd с 1.7 и CRI-O c 1.26. Можно добавить собственную логику, которая будет выполняться в такие моменты жизни Pods как run, stop, remove и контейнеров как creation, post-creation, starting, post-start, updating, post-update, stopping, removal.

В первую очередь это было создано для более низкоуровневой, эффективной работы с ресурсами и устройствами, на пример, которых нельзя описать просто OCI спецификацией. Это может быть очень полезно облачным провайдерам или тем кто контролирует все свое железо и хочет заточится по его специфику. Примеры можно посмотреть тут и тут.

Также отдельно отметим очень высокий уровень критичности данного компонента, который по сути разливается привилегированным daemonset - при написании подобного помните о безопасности.

P.S. В процессе изучения данной темы был найден интересный показательный проект Koordinator (QoS-based scheduling), на котором можно проследить эволюцию подходов к управлению ресурсами в K8s.

BY k8s (in)security