Объяснение:
Для чего предназначен CAPSYSADMIN?
Возможности Linux — это широкая тема сама по себе, но вкратце, как вы можете прочитать здесь:
Начиная с ядра 2.2, Linux разделяет привилегии
традиционно ассоциируется с суперпользователем в отдельные единицы,
известные как возможности, которые могут быть независимо активированы и
Отключено. Возможности — это атрибут потока.
Другими словами, это отдельные единицы, которые можно использовать для управления повышением привилегий в вашей ОС Linux.
И CAP_SYS_ADMIN является одним из них, и на самом деле это довольно мощный. Он позволяет выполнять ряд операций системного администрирования, привилегированных, которые не может выполнять обычный пользователь. Полный список см. этот документ и Ctrl+ф за CAP_SYS_ADMIN.
Как вы понимаете, с точки зрения безопасности использование этой возможности не рекомендуется, за исключением случаев крайней необходимости. Это соответствует принцип наименьших привилегий что в основном означает «предоставление учетной записи пользователя или процессу только тех привилегий, которые необходимы для выполнения его предполагаемой функции».
Но вернемся к контексту кубернет, АКС и Лазурный поскольку вам, вероятно, все еще любопытно, как все, что я упомянул выше, подходит туда.
Включены ли модули по умолчанию с этим свойством?
Нет, это не так, если вы не включите его явно в Стручок определение. Таким образом, предупреждение, которое вы получаете, касается не того факта, что эта возможность используется каким-либо из ваших модулей, а скорее возможности того, что это свойство может быть использовано любым из ваших пользователей, которым разрешено создавать новые модули в АКС кластер. Другими словами, на данный момент модули, которые используют CAP_SYS_ADMIN возможность может быть создана на вашем АКС кластер.
Ниже вы можете увидеть пример такой Стручок:
апиВерсия: v1
вид: стручок
метаданные:
имя: демо-контекст-безопасности-4
спецификация:
контейнеры:
- имя: sec-ctx-4
изображение: gcr.io/google-samples/node-hello:1.0
безопасностьКонтекст:
возможности:
добавить: ["SYS_ADMIN"]
Для получения более подробной информации см. Установить возможности для контейнера раздел в официальной документации kubernetes.
Вы можете легко проверить это самостоятельно, и вы увидите, что приведенное выше Стручок будет успешно создан, так как сейчас это никак не запрещено.
Затем вы можете kubectl exec к таким Стручок и убедитесь, что CAP_SYS_ADMIN способность действительно используется им. Просто запустите:
kubectl exec -it security-context-demo-4 -- /bin/bash
После подключения к Стручок Вы можете запустить:
капш --print | grep cap_sys_admin
И ты увидишь, что cap_sys_admin возможность включена.
Вы можете проверить то же самое в Стручок который не использует эту возможность:
апиВерсия: v1
вид: стручок
метаданные:
имя: демо-контекст-безопасности-4-1
спецификация:
контейнеры:
- имя: sec-ctx-4
изображение: gcr.io/google-samples/node-hello:1.0
Когда ты kubectl exec внутрь:
kubectl exec -ti security-context-demo-4-1 -- /bin/bash
и выполните ту же команду:
капш --print | grep cap_sys_admin
вы увидите, что он не включен по умолчанию.
Решение:
Хотя АКС является управляемой службой kubernetes, и на самом деле многие уровни безопасности уже обработаны для вас Microsoft, вам по-прежнему предоставляется довольно широкий круг обязанностей, когда дело доходит до управления вашими АКС кластер. Вы можете, например. выполните некоторые дальнейшие действия самостоятельно, чтобы сделать его еще более безопасным.
Хорошая новость заключается в том, что вы не остаетесь один на один с такими задачами, и вам предоставляется набор готовых решений, которые вы можете просто применить в своей среде Azure.
Один из них является Центр безопасности Azure, что освобождает вас от необходимости самостоятельно обнаруживать новые потенциальные угрозы в вашей текущей настройке. Как вы можете прочитать здесь рекомендация Кластеры Kubernetes не должны предоставлять возможности безопасности CAPSYSADMIN. является частью Новые рекомендации по усилению защиты кластеров Kubernetes которые все еще находятся в предварительном просмотре, поэтому вы, возможно, не видели их раньше:
Новые рекомендации по усилению защиты кластеров Kubernetes (в предварительной версии)
Следующие рекомендации позволят вам еще больше укрепить
Кластеры Kubernetes
- Кластеры Kubernetes не должны использовать пространство имен по умолчанию. - Для защиты от несанкционированного доступа к ConfigMap, Pod, Secret,
Типы ресурсов Service и ServiceAccount предотвращают использование
пространство имен по умолчанию в кластерах Kubernetes.
- Кластеры Kubernetes должны отключить автоматическое монтирование учетных данных API. - Чтобы предотвратить потенциально скомпрометированный ресурс Pod
от запуска команд API для кластеров Kubernetes, отключите
автоматическое монтирование учетных данных API.
- Кластеры Kubernetes не должны предоставлять возможности безопасности CAPSYSADMIN.
Тогда что будет причиной этого предупреждения?
Учитывая вышеизложенное, на этот вопрос можно ответить: чтобы дать вам возможность улучшить безопасность вашего кластера kubernetes за счет уменьшения потенциальной поверхности атаки ваших контейнеров. Но это полностью зависит от вас, решите ли вы следовать этой рекомендации или нет.
Вот вам и часть обнаружения угроз. Что насчет ремонтной части?
И как мы можем исправить это предупреждение?
Политики Azure это ответ на это. Возможно, вы уже слышали о них. К счастью, для устранения этой конкретной угрозы вам не нужно писать собственную настраиваемую политику, которую предоставляет Azure. встроенные определения политик для службы Azure Kubernetes и вы можете просто использовать их на своем АКС кластер.
В первом столбце вам предоставляется прямая ссылка на ваш портал Azure, что приведет вас на страницу определения политики, где вы сможете изучить ее детали и назначить ее определенной подписке и группе ресурсов:
Для получения более подробной информации см.:
Другие полезные ссылки:
