Я не уверен, является ли serverfault подходящим обменом для этого вопроса, пожалуйста, укажите, не так ли
Создайте минимальные разрешения, настроенные для реализации максимально возможного уровня безопасности с RBAC и AD, прежде чем решать любые другие проблемы безопасности.
Покопавшись с начальными параметрами, я на данный момент решил, что роль Читателя каталогов в AD является наименее возможной привилегией AD для создания кластера кубернетов. Это дает пользователю доступ для чтения, но ничего больше.
У меня есть пользователь A, которому я предоставил эту роль на ОБЪЯВЛЕНИЕ, на RBAC единственные разрешения, которые у них есть, находятся внутри их собственной группы ресурсов, они даже не могут видеть, какие другие группы ресурсов существуют.
У меня есть сервисный принцип SPforA, который нуль роли на RBAC или ОБЪЯВЛЕНИЕ.
Пользователь A является владельцем группы ресурсов RGforA и не может видеть все другие существующие группы ресурсов (RGforB, RGforC и т. Д.) И не может создавать группы ресурсов.
Принципал службы SPforA находится в той же ситуации, что и A.
Теперь я создаю кластер kubernetes в RGforA с пользователем A и назначаю SPforA в качестве принципала службы для кластера.
Как указано в документации, при создании кластера kubernetes создается вторая группа ресурсов, содержащая всю инфраструктуру кластера.
Ни A, ни SPforA не могут создавать группу ресурсов или создаваемые машины и балансировщики нагрузки, службу безопасности, аналитику журналов и т. Д. Тем не менее группа ресурсов и инфраструктура созданы.
Журналы показывают, что создателем группы ресурсов и всех служб был субъект службы AzureContainerService.
Как получается, что пользователь без привилегий может создавать ресурсы даже через делегирование? Это какая-то странная сдержанная эскалация привилегий?
Мне может не хватать некоторых мелких деталей, поэтому, прежде чем поднимать заявку, я хотел бы знать, должно ли это быть реальным поведением.