Третья часть из цикла [1,2] про
Согласитесь исполняемый файл
Я для себя выделил 3 типа гранулярности политик: слабое/низкое (1), среднее/гибридное (2) и сильное/высокое (3):
1) Все происходящее в контейнере относительно процессов, файлов и сетевого взаимодействия отражается в виде списков. То есть список процессов, что там был запущен, список файлов к которым было обращение и список сетевых
2) Это что-то среднее между низким и высоким уровнем гранулярности политик, относительно тех или иных связей между процессами, файлами и сетевыми операциями. Может быть много вариаций, в плоть до полного отказа от контроля от файловых операций. В основном, оставляют связи на уровни родитель-потомок.
3) Все происходящее в контейнере относительно процессов, файлов и сетевого взаимодействия отражается в виде графа. Это означает наличие иерархии взаимодействия между процессами и для каждого из них собственная иерархия взаимодействия с файловой системой и сетью. При этом каждый процесс в такой иерархии может иметь свои права доступа к файлам (
Для решения той или иной задачи в определенных условиях, окружении может быть достаточно и слабой гранулярности, но понять это можно для начала имея полную картину происходящего.
sensor-based решения по безопасности для Kubernetes.Согласитесь исполняемый файл
bash запущенный в контейнере от entrypoint (runc) и bash запущенный вашим, например, java и python приложениями это 3 разных действия с точки зрения поведения bash. Или еще пример: Обращение к файлам в директории /var/run/secrets/kubernetes.io/serviceaccount/ двумя разными процессами в контейнере это 2 разных действия. К чему это все? А к тому, что разные sensor-based решения на происходящее внутри контейнеров смотрят с разным уровнем гранулярности (точности), которая потом ложиться в основу модели поведения или политики. Я для себя выделил 3 типа гранулярности политик: слабое/низкое (1), среднее/гибридное (2) и сильное/высокое (3):
1) Все происходящее в контейнере относительно процессов, файлов и сетевого взаимодействия отражается в виде списков. То есть список процессов, что там был запущен, список файлов к которым было обращение и список сетевых
endpoint'ов к которым было обращение. При этом эти списки не связана. Таким образом, если процесс bash есть, то непонятно от кого и он всегда разрешен, если есть обращение к /var/run/secrets/kubernetes.io/serviceaccount то это можно всем, соединение на определенный IP возможет от любого процесса в контейнере. 2) Это что-то среднее между низким и высоким уровнем гранулярности политик, относительно тех или иных связей между процессами, файлами и сетевыми операциями. Может быть много вариаций, в плоть до полного отказа от контроля от файловых операций. В основном, оставляют связи на уровни родитель-потомок.
3) Все происходящее в контейнере относительно процессов, файлов и сетевого взаимодействия отражается в виде графа. Это означает наличие иерархии взаимодействия между процессами и для каждого из них собственная иерархия взаимодействия с файловой системой и сетью. При этом каждый процесс в такой иерархии может иметь свои права доступа к файлам (
r,w,rw). Для решения той или иной задачи в определенных условиях, окружении может быть достаточно и слабой гранулярности, но понять это можно для начала имея полную картину происходящего.