Начинаем этот день с очередной интересной заметки от 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.