Начинаем этот день с очередной интересной заметки от Rory McCune
– Cap or no cap.
Свой ресерч автор начал с allowPrivilegeEscalation
поля в манифесте. Это достаточно интересно, поскольку на самом деле выставление этого значения не делает то, о чем говорит его название. Об этом мы рассказывали на канале в этом посте.
Продолжая эксперементировать c allowPrivilegeEscalation
и добавлением capability
, исследователь приходит к интересным выводам. Так например, если вы используете containerd
, то:
- CAP_SYS_ADMIN
(для работы нужно добавлять SYS_ADMIN
) в манифесте позволяет задеплоиться
- allowPrivilegeEscalation: false
+ CAP_SYS_ADMIN
– не дает задеплоиться
- allowPrivilegeEscalation: false + SYS_ADMIN
– разрешает задеплоиться и добавляет capability
- добавление несуществующей capability LOREM
– разрешает задеплоиться
Промежуточный итог: Kubernetes не проверяет, какие capability
вы добавляете, и не генерирует ошибку, если вы добавляете недопустимую – он просто ничего не делает.
Далее автор продолжил свой эксперимент на cri-o
:
- CAP_SYS_ADMIN
– сработало
- SYS_ADMIN
– сработало
- allowPrivilegeEscalation: false + CAP_SYS_ADMIN
– не дает задеплоиться
- allowPrivilegeEscalation: false + SYS_ADMIN
– разрешает задеплоиться и добавляет capability
- установка несуществующей capability
привела к ошибке при создании контейнераCRI-O
обрабатывает это немного по-другому, позволяя работать обоим и выдавая ошибки при недопустимых capability
.
>>Click here to continue<<