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