Как понять каких полномочий не хватает пользователю?
В системе действует принцип «что не разрешено, то запрещено». То есть изначально пользователю не разрешено ничего, кроме входа (логина) в систему.
Минимальный набор операций для того или иного бизнес-процесса выделяется в роль, которая имеет описание и меню, в котором могут быть транзакции, отчеты или внешние ссылки. Для каждой роли генерируется профиль полномочий, который содержит набор полномочий (или разрешений) минимально достаточных для выполнения набора операций, для которого созадана роль (рис. 1). Про генерацию профиля я писал в этом посте.Рис. 1. Роли и полномочия в SAP системе. |
Роли присваиваются пользователям, после чего пользователи получают, указанный в них, набор полномочий.
Присвоенный пользователю набор полномочий в SAP системе можно посмотреть в транзакции SU56 (рис. 2).
Рис. 2. Список присвоенных пользователю полномочий. |
Проверка полномочий в SAP системе производится в 2 этапа:
- Проверка на запуск транзакции.
- Проверка на полномочия для тех или иных действий с объектом (просмотр, создание, удаление, изменение и т.п.) в транзакции.
Покажу на примере.
Пользователь пытается запустить транзакцию SM04 и получает уведомление об отсутствии полномочий на запуск транзакции (рис. 3).
Рис. 3. Сообщение об отсутствии полномочий на запуск транзакции SM04. |
Для анализа недостающих полномочий необходимо в поле запуска транзакции набрать транзакцию SU53 (рис. 4).
Рис. 4. Анализ недостастающих полномочий в транзакции SU53. |
Как видно из снимка экрана, сообщение об ошибке это результат неудачной проверки первого типа — на запуск транзакции, в данном случае SM04.
Стоит отметить, что все полномочия в SAP системе выделются через объекты полномочий, у которых есть поля и присвоенные им значения. Для удобства поиска и выбора все объекты полномочий объединены в классы.
За полномочия на запуск транзакции (первый этап проверки) отвечает объект полномочий S_TCODE (рис. 4). Значениями поля TCD являются транзакции, которые пользователь может запускать. В данном случае система искала в этом объекте значение SM04, не нашла и выдала сообщение об ошибке.
После того, как я добавил такой объект с нужным значением поля в роль, которая присвоена пользователю, и заново сгенерировал профиль полномочий для этой роли, пользователь сделал вторую попытку запуска транзакции SM04. Система разрешила запуск транзакции, показав основной экран транзакции. Но при дальнейшей работе, например, попытке просмотреть список режимов у любого пользователя в транзакции SM04 вновь выдала сообщение об ошибке. На этот раз, на предмет проверки полномочий на объект (рис. 5).
Рис. 5. Сообщение об отсутствии полномочий на администрирование процессов/программ в SM04. |
Рис. 6. Анализ полномочий на работу в транзакции SM04. |
Данный инструмент показывает только те полномочия, на проверке которых система «споткнулась». То есть только один, последний, шаг.
Для получения полного списка необходимых полномочий на выполнение той или иной операции в системе существует другой инструмент. Но об этом в другой раз.
Учтите, что если вы хотите анализировать у пользователей результаты последней проверки полномочий, то необходимо им добавить полномочия на запуск транзакции SU53 — объект S_TCODE. Либо можно использовать параметр auth/tcodes_not_checked (рис. 7). Можно ввести значения «SU53», «SU56» или сразу обе транзакции «SU53 SU56» и, тогда система не будет проводить первый тип проверки для этих транзакций.Рис. 7. Параметр для отключения проверок для транзакций SU53, SU56. |
Подробности о концепции ролей и полномочий можно найти в курсе «SAP ADM940 — ABAP AS Autorization Concept».
SAPLand — Мир решений SAP
Записки SAP Basis консультанта.
Как вы уже, наверное, слышали, в SAP системе (AS ABAP её части) для разграничения доступа пользователей к тем или иным функциям системы используется концепция ролей и полномочий.
В системе действует принцип «что не разрешено, то запрещено». То есть изначально пользователю не разрешено ничего, кроме входа (логина) в систему.
Минимальный набор операций для того или иного бизнес-процесса выделяется в роль, которая имеет описание и меню, в котором могут быть транзакции, отчеты или внешние ссылки. Для каждой роли генерируется профиль полномочий, который содержит набор полномочий (или разрешений) минимально достаточных для выполнения набора операций, для которого создана роль (Рис. 1). Про генерацию профиля я писал в этом посте.
Рис. 1. Роли и полномочия в SAP системе.
Роли присваиваются пользователям, после чего пользователи получают, указанный в них, набор полномочий.
Присвоенный пользователю набор полномочий в SAP системе можно посмотреть в транзакции SU56 (Рис. 2).
Рис. 2
. Список присвоенных пользователю полномочий.Проверка полномочий в SAP системе производится в 2 этапа:
- Проверка на запуск транзакции.
- Проверка на полномочия для тех или иных действий с объектом (просмотр, создание, удаление, изменение и т.п.) в транзакции.
Покажу на примере.
Пользователь пытается запустить транзакцию SM04 и получает уведомление об отсутствии полномочий на запуск транзакции (Рис. 3).
Рис. 3. Сообщение об отсутствии полномочий на запуск транзакции SM04.
Для анализа недостающих полномочий необходимо в поле запуска транзакции набрать транзакцию SU53 (Рис. 4).
Рис. 4. Анализ недостастающих полномочий в транзакции SU53.
Как видно из снимка экрана, сообщение об ошибке это результат неудачной проверки первого типа — на запуск транзакции, в данном случае SM04.
Стоит отметить, что все полномочия в SAP системе
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
ЗарегистрироватьсяУ вас уже есть учетная запись?
ВойтиУправление полномочиями для разработки в SAP HANA — Наука
Сегодня практически каждый пользователь SAP сталкивается с SAP HANA – системой управления базами данных, которая также используется как среда разработки приложений. Но прежде чем начать разрабатывать приложения или даже писать простые запросы к базе, необходимо настроить доступ пользователей и определить доступные для них полномочия.
В этой статье мы не касаемся конкретных требований по безопасности, так как они зависят от предприятия. Приведём лишь общие сведения о работе с полномочиями – создании и присвоении ролей пользователям. Всё нижеописанное актуально для версии SAP HANA Studio 2.3.17.00000. В других версиях могут быть небольшие различия, но общая концепция сохраняется.
Создание пользователя в SAP HANA
Предположим, что HANA Studio уже установлена, настроена, в ней созданы системы (ландшафты) для разработки.
Прежде всего необходимо создать учётную запись пользователя. Для этого выбирается система, в которой будет создан пользователь. В дереве каталогов выбирается папка Security и объект Users внутри папки. В контекстном меню надо нажать на пункт New User – это стандартный пользователь. Также можно выбрать Restricted User – такой пользователь не может создавать объекты, видеть данные, и он подключается только по HTTP.
В открывшемся окне вводится имя пользователя в соответствии с порядками, введёнными в организации. Далее нужно выбрать тип аутентификации. Если по паролю, то вводится и подтверждается начальный пароль. Также возможна аутентификация по протоколу Kerberos, сопоставляющему идентификацию в Windows Active Directory. Для этого указывается login, по которому будет осуществляется авторизация по протоколу.
На следующем скриншоте показано, что пользователь создан с параметром аутентификации по протоколу Kerberos. Выставленный чекбокс напротив параметра SAML означает, что для данного пользователя используется сертификат SAML. С помощью данного сертификата реализуется технология единого входа, т.е. он позволяет не осуществлять повторную аутентификацию и использовать учётную запись для нескольких систем и программных продуктов. Например, таким образом можно получить доступ к SAP HANA и Business Object – инструменту разработки отчётности. Настройка сертификата осуществляется с помощью кнопки Configure:
Предполагается, что при настройке систем сертификат уже был установлен в систему. В открывшемся окне нажимается кнопка Add (добавить), выбирается из списка необходимый сертификат и указывается пользователь для целевой системы – в данном случае Business Object:
Также имеется возможность использовать сертификат X.509. Он необходим для доступа SAP HANA XS по протоколу HTTP. Для его использования нужно повторить действия, аналогичные для протокола SAML.
Вышеописанные действия необходимо повторить для пользователя в каждой системе, в которой он заводится.
Присвоение полномочий пользователю в SAP HANA
Созданной учётной записи необходимы полномочия, чтобы осуществлять полноценную разработку. При создании стандартного пользователя по умолчанию присваивается роль PUBLIC, предоставляющая доступ только на чтение:
Остальные роли присваиваются по необходимости. Каждая роль даёт определённые полномочия на определённые объекты. Если взять конкретную роль, то в ней может быть несколько типов привилегий. Ниже на картинке представлена общая схема:
1. System Privileges – полномочия для администрирования (создание и изменение схем, мониторинг, управление пользователями). Для обычного пользователя и большинства разработчиков данный тип привилегий не требуется.
2. Object Privileges – полномочия на конкретный объект (каталог, схему, представление и т.д.). Ниже пример того, как на объект – схему – предоставлены полномочия только на запуск операции select:
3. Analytic Privileges – полномочия на доступ к данным в определённом объекте. Они используются, когда есть необходимость разграничить выгружаемые данные в зависимости от роли пользователя. Обычно аналитические привилегии привязаны к конкретному объекту, например, к представлению. В общей же роли, допустим, на целую схему аналитические привилегии не добавляют, хотя это зависит от регламентов безопасности, принятых на предприятии.
4. Package Privileges – полномочия на пакеты (каталоги, папки), в которых находятся объекты. К примеру, в общей роли на схему можно разграничить, к каким пакетам будет доступ у пользователя и какие опции будут при этом доступны. На указанном ниже примере видно, что данная роль предоставляет доступ к списку пакетов, с возможностью чтения, редактирования, активации как для уже имеющихся объектов, так и для импортированных:
5. Application Privileges – полномочия на использование приложений SAP HANA XS. В таком случае приложение будет указано как объект.
6. Privileges on Users – полномочия, предоставляемые конкретному пользователю. Например, такая роль применяется для возможности осуществлять дебаг объекта.
После создания учётной записи пользователя и определения необходимости предоставляемых полномочий создаётся роль в соответствии с правилами безопасности предприятия. Для создания роли необходимо выбрать папку Security в выбранной системе и в контекстном меню выбрать пункт New Role:
В меню создания роли необходимо указать наименование роли в соответствии с положениями, принятыми на предприятии. Далее в соответствующих разделах по нажатию кнопки «плюс» добавляются необходимые роли и привилегии, если это необходимо. Таким образом можно создать и так называемую групповую роль, в которую включены несколько ролей, и отдельную роль на конкретный объект. После всех выбранных объектов роль необходимо активировать.
Созданную роль можно назначить необходимому пользователю, открыв свойства учётной записи пользователя и при нажатии «плюса» в разделе присвоенных ролей выбрав необходимую из списка:
После выполнения всех этих действий будет готова учётная запись пользователя, для него будет создана и присвоена роль. Пользователь уже сможет осуществлять разработку в SAP HANA Studio, если, конечно, ему были присвоены необходимые роли. Как только разработчик создаст объекты – например, аналитический отчёт для пользователей – потребуется сделать роли для такого объекта. Это позволит разграничить доступ к данным, выгружаемым из этого отчёта.
Создание ролей на объекты аналитических привилегий в SAP HANA
При большом количестве пользователей различных бизнес-сфер и разработок для них может возникнуть необходимость разделять доступ, например, к данным или конкретным отчётам для сохранения конфиденциальности. Допустим, отделу аналитики, который занимается отчётами о продажах, не нужно знать данные о заработной плате – их должны видеть только бухгалтерия и отдел кадров. Таким образом, понадобится создать как минимум две роли, разграничивающие эти сферы. Реализовать это можно посредством хранения процедур экстракции таких данных в двух разных каталогах, которые будут ограничены в доступе на выполнение созданными ролями.
В предыдущем разделе был описан процесс, в результате которого имеется учётная запись пользователя с присвоенной ролью (например, на конкретный пакет с объектами). Однако при создании отчёта в Business Object может возникнуть необходимость в полномочиях на объект (т.е. на конкретное представление) и в доступе к определённым данным. В таком случае, чтобы ограничить доступ к объекту, создаётся объектная роль, а для ограничения данных создаётся аналитическая привилегия.
Объектная роль
Объектная роль, как понятно из названия, нужна для предоставления доступа к конкретному объекту. Если имеется возможность создания ролей в каталоге Security, то процесс уже был описан выше. В каталоге создаётся новая роль. В разделе Object Privileges перечисляются объекты, к которым будет предоставлен доступ. Если речь идёт об отчёте Business Object, то указывается модель отчёта в HANA и возможные операции (в случае доступа пользователя к отчёту указывается только select).
Может произойти ситуация, когда возможности создавать роли в каталоге Security нет, например, если роль создаётся разработчиком, а полномочия на создание ролей в этом каталоге есть только у администратора системы. В таком случае роль создаётся в репозитории, т.е. локально у себя на диске, а затем переносится в общий каталог. Если репозитория нет в разделе рядом с системами, то для его открытия нужно зайти в раздел Window, далее Show View – Other. В появившемся окне выбирается раздел SAP HANA и в нём Repositories:
В открывшемся репозитории выбирается нужная система (при первом запуске HANA Studio предложит выбрать место на диске для локального хранения файлов). Далее в нужном каталоге создаётся роль – подчеркнём, что желательно хранить роли отдельно от других объектов, в отдельном пакете. Правым кликом по пакету вызывается контекстное меню, в котором выбирается пункт New, далее Other и в открывшемся окне в разделе Database Development нужно найти объект Role.
Указывается наименование и выбирается действие Finish. Созданная роль откроется в рабочей области HANA Studio. В самой роли в виде SQL кода указывается адрес нахождения роли, включаемые в роль объекты и допустимые операции с ними:
После создания роль необходимо сохранить и активировать, чтобы она перенеслась из репозитория в систему. Сохраняется роль по кнопке на панели инструментов. Активация осуществляется с помощью вызова контекстного меню по правому клику на объектной роли, которую необходимо активировать.
Аналитическая привилегия
Если объектная роль ограничивает доступ к конкретному объекту, то аналитическая привилегия ограничивает определённый срез данных. Например, данные формируются в разрезе нескольких отделов предприятия. В таком случае имеет смысл разделить вывод данных в отчёте в зависимости от принадлежности пользователя к отделу (подобное разделение зависит от политики безопасности в компании).
На модели SAP HANA для отчёта должен быть выставлен параметр Classical Analytic Privileges. Это означает, что пользователь не сможет запустить отчёт для просмотра данных, если у него нет аналитической привилегии на этот отчёт.
Создание аналитической привилегии осуществляется в разделе Systems. Для этого необходимо выбрать систему и каталог, в котором будет создан объект. Правым кликом по каталогу вызывается контекстное меню, в нём выбирается пункт New – Analytic Privilege. Указывается наименование, и, если нужно, привилегия создаётся как копия другой привилегии.
Далее в разделе Secured Models указываются необходимые для отчёта модели, в которых выставлен параметр аналитических привилегий (см. выше). В разделе Associated Attributes Restrictions определяются поля, по которым будет ограничиваться разрез данных. В разделе Assign Restrictions указываются значения полей, по которым будут ограничены данные. После всех необходимых действий привилегия сохраняется и активируется.
Полученная привилегия может быть добавлена в роль, а роль – в свою очередь – назначена пользователю. Таким образом, осуществляется разграничение доступа к данным.
Описанные в данной статье действия показывают, как осуществляется создание ролей и назначение их пользователям SAP HANA. Создавая роли, можно как предоставить доступ к определённым объектам (папкам, системам, процедурам и т.д.), так и ограничить доступ к ним или выгружаемым данным. В ситуации с большим количеством пользователей, которые могут относиться к разным бизнес-сферам, потребуется добавлять каждую разработку в определённую роль или группу ролей и назначать их пользователям.
NAUKA ВКонтакте
NAUKA в Facebook
NAUKA в Instagram
Вернуться в пресс-центр
Участники | Просмотр Это право доступа позволяет просматривать участников организации. Если отмечено, права доступа Просмотр позволяют участникам просматривать вкладку Участники на странице Организация. Если не отмечено, участники не могут видеть страницу Организация. |
Группы | Создание, обновление и удаление Это право доступа позволяет участникам создавать группы на портале и управлять ими. |
Присоединение к группам организации Участники ролей, которым предоставлено это право, могут направлять запрос на присоединение к группам в организации. Это право доступа полезно только в том случае, если вы также предоставляете роль право просмотра групп, доступных на портале. Если у роли нет этого права, участники не будут видеть группы и, следовательно, не смогут направлять запрос на присоединение к ним. | |
Просмотреть группы, доступные на портале Это право доступа позволяет участникам обнаруживать группы, настроенные таким образом, чтобы участники портала могли их просматривать. | |
Ресурсы | Создание, обновление и удаление Это право доступа позволяет участникам создавать элементы на портале и управлять ими. Это право доступа необходимо, если вы предоставляете какие-либо права, позволяющие участникам публиковать, регистрировать хранилища данных или создавать Блокноты. |
Публикация размещённых векторных слоёв Это право доступа позволяет участникам публиковать размещенные векторные слои на портале как из самого портала, так и из других приложений, например ArcGIS Pro. Это право доступа также необходимо при использовании приложений, создающих размещенные векторные слои, такие как ArcGIS Survey123 и ArcGIS Workforce. | |
Публикация размещённых слоёв листов Это право доступа позволяет участникам публиковать размещенные слои листов на портале как из самого портала, так и из других приложений, например ArcGIS Pro. | |
Публикация размещенных слоёв сцены Это право доступа позволяет участникам публиковать размещенные слои сцены на портале как из самого портала, так и из других приложений, например ArcGIS Pro. | |
Публикация серверных слоёв Это право доступа позволяет участникам публиковать веб-слои ArcGIS Server на сайтах ArcGIS Server, интегрированных с порталом. Это право доступа также необходимо для участников, который выполняют пакетную публикацию слоев из элемента хранилища данных. | |
Просмотр ресурсов, опубликованные в организации Это право доступа позволяет участникам получать доступ к элементам, которые являются общими для организации портала. | |
Регистрация хранилищ данных Это право доступа позволяет обладателям этой роли добавлять элементы хранилищ данных на портал. | |
Пакетное создание векторных слоев из хранилища данных Это право доступа позволяет владельцу элемента хранилища данных публиковать векторные слои и слои изображений карты из всех классов объектов и таблиц, доступных в базе данных. | |
Просмотр отслеживания местоположения Это право доступа предоставляет возможность отслеживать местоположения участников через опубликованные представления трекинга, когда включено отслеживание местоположений. | |
Создание и изменение Блокнотов Это право доступа позволяет обладателям этой роли создавать блокноты ArcGIS, используя стандартную среду. Это право доступа видно только в том случае, если для вашей организации настроен Notebook Server. Могут потребоваться дополнительные права (например, управление ресурсами или запуск специальных инструментов анализа) — в зависимости от рабочих процессов, выполняемых автором блокнота. | |
Настройка расписаний Блокнотов Это право доступа позволяет участникам роли планировать расписание блокнотов ArcGIS для запуска в определенное время. Для настройки расписания определенного блокнота, пользователь должен быть владельцем блокнота или обладать административными правами. Это право доступа видно только в том случае, если для вашей организации настроен Notebook Server. Для включения права доступа Создание и изменение блокнотов оно должно быть активировано. | |
Публикация | Общий доступ для групп Это право доступа позволяет участникам делиться элементами, которыми они владеют, с любыми группами, к которым принадлежит участник. |
Общий доступ на портале Это право позволяет участникам делиться на портале организации любыми элементами, которыми они владеют. | |
Общий доступ для всех Это право доступа позволяет участникам делиться элементами, которыми они владеют, с кем угодно, даже с пользователями, которые не вошли на портал. | |
Создание групп, видимых на портале Когда вы создаете группу, вы указываете, кто может видеть группу или искать ее. Это право доступа «Сделать группы видимыми на портале» требуется, чтобы позволить создателям групп настроить группу таким образом, чтобы позволить участникам портала просматривать группу. Это право доступа полезно только в том случае, если роль также включает право создавать, обновлять и удалять группы. | |
Создание групп, видимых для всех Когда вы создаете группу, вы указываете, кто может видеть группу или искать ее. Это право доступа «Сделать группы видимыми для всех» требуется, чтобы позволить создателям групп настроить группу таким образом, чтобы позволить анонимным пользователям просматривать группу. Это право доступа полезно только в том случае, если роль также включает право создавать, обновлять и удалять группы. | |
Ресурсы и анализ | Геокодирование Используйте ArcGIS World Geocoding Service для конвертации адресов или мест в точки на карте (геокодирование), например для добавления файлов .csv с адресами на карту. (Не применяется к собственным локаторам, настроенным для организации. Это не контролирует возможность публикации файла Microsoft Excel адресов в качестве размещенного векторного слоя. |
Сетевой анализ Это право доступа позволяет выполнять задачи анализа сети, например, построение зон доступности. | |
Стандартный анализ объектов Это право доступа позволяет выполнять задачи пространственного анализа, например, создание буферных зон. | |
Геообогащение Это право доступа позволяет использовать сервис GeoEnrichment для доступа к демографической информации. | |
Анализ объектов GeoAnalytics Это право доступа позволяет использовать Геоаналитика. | |
Анализ растра Это право доступа позволяет использовать инструменты анализа растров. | |
Расширенная среда Notebook Это право доступа позволяет создавать блокноты ArcGIS Notebook, используя расширенные рабочие среды. Это право доступа видно только в том случае, если для вашей организации настроен Notebook Server. Могут потребоваться дополнительные права (например, управление ресурсами или запуск специальных инструментов анализа) — в зависимости от рабочих процессов, выполняемых автором блокнота. | |
Пространственные объекты | Редактирование Это право доступа позволяет редактировать объекты в зависимости от разрешений, настроенных для слоя. |
Редактирование с полным доступом Редактирование с полным доступом: добавление, удаление и обновление объектов и атрибутов в редактируемых размещенных векторных слоях, даже если операции редактирования в слоях ограничены. | |
Управление версиями | Управлять всеми (новое в версии 10.8.1) Это право доступа позволяет участникам с этой ролью просматривать, изменять и удалять все версии ветви, доступные через векторный веб-слой ArcGIS Server. Это право доступа также позволяет участникам с этой ролью управлять блокировками версии на этих слоях. При включении этого права доступа по умолчанию также включаются следующие права доступа:
Участники с пользовательской ролью, имеющие эти три права доступа, называются администраторами версий. |
Критичные полномочия в системе SAP
Если в одной SAP системе автоматизировано большое количество бизнес-процессов, поддерживаемое обособленными проектными командами с не очень хорошо выстроенным процессом коммуникаций между собой, не далек день, когда возникнет конфликтная ситуация пересечения полномочий пользователей бизнес-функций, являющихся нежелательными (критичными), или избыточными, с чьей-либо стороны. Для выполнения анализа и выявления спорных ситуация (необязательно из числа представленных выше), можно воспользоваться инструментом, который позволяет определить критичные полномочия в системе SAP. Критичность в данном конкретном случае определяет консультант.
Настройка
Начало процесса настройки осуществляется посредством запуска программы RSUSR008_009_NEW
См. Examples of Using Critical Authorizations and Combinations
Какие опции предоставлены для настройки?
Доступны следующие опции для настройки:
- Сами критичные полномочия
- Комбинации критичных полномочий
В качестве дополнительных фильтров доступен поиск критичных полномочий/комбинаций в разрезе ролей или пользователей системы.
См. Analyzing Users with Critical Authorizations
With the following procedure, you first define critical authorizations and the associated authorization data. You then combine the critical authorizations into a variant with which you then perform the evaluation.
Также стоит отметить, что для различных группировок критичных полномочий возможно определить цветовую схему. Мелочь, а уже не так сермяжно будет выглядеть.
Пример 1. Критические полномочия
На следующем видеофрагменте представлен пример определения критических авторизаций на объектах полномочий P_ORGIN и P_ABAP
Проверяю, что получилось
См. Evaluation of the Result List
The result lists are different, depending on the type of the selection variant
— For critical authorizations
The selected users are grouped by the IDs of critical authorizations.
To check which critical data is represented by an ID, choose the name of the ID.
To analyze the authorization data of a user master record, select the user by double-clicking it.The other fields provide additional information about the user.
Use the Profiles and Roles pushbuttons to display lists of profiles and roles assigned to the selected users.
All other functions are standard functions of the ALV grid control
— For critical combinations
The selected users are grouped by critical combinations. If you select a combination name, the corresponding critical data is displayed.
The other functions correspond to those for critical authorizations.
Пример 2. Комбинации критических полномочий
Настроив группы критичных полномочий, которые вас интересуют, можно скомбинировать их, предварительно выбрав цветовую легенду. Каждая комбинация — свой цвет, отражающийся в результатах работы программы.
На следующем видеофрагменте представлен пример настройки двух комбинаций объектов полномочий, один набор которых состоит из представленных ранее объектов (P_ORGIN и P_ABAP) с добавлением еще одного (S_DEVELOP)
Базовая методика аудита полномочий пользователей в системе SAP ERP — ISO27000.ru
Важнейшая корпоративная информация и связанные с ней автоматизируемые процессы имеют тенденцию постепенно перебираться из разрозненных файловых систем, баз данных и отдельных приложений в единые системы управления предприятием, наиболее распространенной из которых является SAP ERP. При этом в качестве одной из ключевых задач аудита информационной безопасности становится аудит безопасности данной ERP-системы, т.е. акцент смещается с общесистемного аудита на внутрисистемый. Наиболее трудоемкой задачей такого аудита ERP-системы, является аудит распределения полномочий пользователей.
Методика аудита полномочий в SAP ERP, которую нам пришлось разрабатывать, опираясь на зарубежные руководства, включает в себя много чего и, вообще говоря, довольно сложна. Чтобы как-то упростить и удешевить процесс я разбиваю данную методику на две части: базовую и расширенную. Базовая часть методики включает в себя: анализ концепции авторизации, анализ состава пользователей, обзор назначенных пользователям профилей и ролей, анализ авторизаций (объектов, транзакций и уровней доступа) внутри профилей, проверка установленных лимитов.
Далее приведу основные шаги базовой методики в сокращенном виде. Основная цель — дать общее представления о том, что и в какой последовательности надо делать, т.е. в общих чертах как выгружать информацию из SAP и на что смотреть. Поскольку в открытых русскоязычных источниках я такой информации не встречал, это должно быть полезно нашему проф. сообществу.
Расширенную методику анализа полномочий в SAP ERM приведу в следующей статье данного цикла. Ее имеет смысл использовать в случае, если все проблемы, выявленные на базовом уровне, устранены.
Анализ концепции авторизации SAP
Концепция авторизации устанавливает взаимосвязь между объектами авторизации SAP (таблицами, транзакциями и программами ABAP/4) и субъектами – пользователями SAP. Механизмом реализации модели ролевого доступа в SAP выступают пользовательские профили, группы и роли. Концепция авторизации должна обеспечивать правильное определение профилей и групп, ролей их состав и соответствие функциональным ролям пользователей в бизнес-процессах. При определении полномочий пользователя в системе должен соблюдаться принцип минимизации привилегий и принцип разделения критичных ролей в бизнес-процессах. При анализе концепции авторизации проверяется наличие в организации необходимых внутренних нормативных документов, подходов и процессов, определяющих концепцию авторизации в системе SAP и позволяющих поддерживать систему авторизации в актуальном состоянии.
Анализ концепции авторизации охватывает следующий круг вопросов:
- В каких внутренних нормативных документах определена концепция авторизации?
- Каким образом осуществляется оценка и обработка рисков, связанных с некорректной авторизацией?
- Кто и каким образом разрабатывал концепцию авторизации?
- Кто и каким образом реализовывал концепцию авторизации?
- Кто, каким образом и когда тестировал концепцию авторизации?
Анализ состава пользователей SAP
При анализе списка пользователей SAP выявляем:
- Лишние пользователи, которым не должно предоставляться доступа к SAP (третьи лица, уволенные сотрудники, сотрудники, которым по должности не положен доступ к SAP)
- Групповые (совместно используемые, неперсонифицированные) учетные записи пользователей.
Шаг 1. Выгрузка пользователей и групп
Способ выгрузки данных SAP:
- AIS system -> User Administration -> IS Users and Authorizations -> User -> By User ID
- Транзакция: SA38, Отчет: RSUSR002
Шаг 2. Сравнение списка пользователей SAP со списком сотрудников компании
Выявляем:
- Действующих сотрудников
- Уволенных сотрудников
- Сотрудников, допущенных работе в SAP
- Третьих лиц
Обзор профилей и ролей, назначенных пользователям SAP
Проверка назначенных пользователям профилей включает в себя следующие шаги:
- Критичные стандартные системные профили (super, administration, development) должны быть назначены только ограниченной группе системных администраторов, среди этих администраторов нет лишних людей, и данные профили соответствуют их должностным обязанностям.
- В системе не используется стандартных функциональных профилей SAP, не обеспечивающих достаточной степени разграничения полномочий (например, в бухгалтерии).
- Именование и описание профилей в системе должно соответствовать концепции авторизации.
- Назначенные пользователям профили соответствуют их должностным обязанностям, определяемым штатным расписанием и ролями пользователей в бизнес-процессах.
- Назначенные одному пользователю профили не нарушают принципа разделения критичных ролей (например, бухгалтера и казначея).
Шаг 1. Выгрузка пользователей и групп
Исходные данные:
- Матрица полномочий
- Выгрузка из системы списка пользователей
Способ выгрузки данных SAP:
- AIS system -> User Administration -> IS Users and Authorizations -> User -> By User ID
- Транзакция: SA38, Отчет: RSUSR002
Шаг 2. Выявление «общих учетных записей»
Критичные системные функции должны назначаться пользователям на индивидуальной основе. Все пользователи должны быть индивидуализированы. Не должно использоваться «общих» учетных записей (User ID) группой пользователей, таких как Admin, Operator, Author, Developer, Accountant, Buyer и т.п.
Шаг 3. Проверка состава пользовательских групп
На данном шаге устанавливается:
- В какие группы входит пользователь?
- Соответствуют ли данные группы его функциональным обязанностям?
- Где и кем определено назначение конкретных групп и какие пользователи должны входить в данные группы?
Шаг 4. Проверка назначенных пользователям профилей
Способ выгрузки данных SAP:
- AIS system -> User Administration -> IS Users and Authorizations -> User -> By User ID
- Транзакция: SA38, Отчет: RSUSR002
- Кнопка Profiles.
На данном шаге осуществляется сравнение матрицы полномочий со списком назначенных пользователю профилей:
- Все назначенные пользователю профили должны быть определены в матрице полномочий.
- Имена профилей должны соответствовать установленным правилам.
- Не должны использоваться стандартные профили SAP, особенно в бизнес-подразделениях (например, F_BUCH_ALL)
Шаг 5. Выявление пользователей, не имеющих авторизаций
В системе не должно быть пользователей без авторизаций. Пользователи без авторизаций выявляются путем сортировки списка пользователей и назначенных им профилей.
Шаг 6. Проверка стандартных профилей SAP
Рекомендуется:
- Замена на профили с урезанными правами
- Ограничение использования до 2-3 администраторов
- Не должны назначаться бизнес-пользователям
- Не должны назначаться группам пользователей
- Не должны назначаться разработчикам и внешним консультантам
Анализ авторизаций внутри профилей SAP
Для анализа авторизаций в рамках конкретных профилей используется случайная выборка из наиболее критичных профилей. В качестве критериев выбора используются следующие признаки:
- Выделяющиеся профили и роли (не описанные в матрице полномочий, имеющие отклонения от принятых правил именования, описание профиля свидетельствует о его общем (типовом) предназначении, либо использовании профиля для разработки)
- Профили с некритичными авторизациями (например, Display)
- Случайная выборка профилей из оставшихся, не вошедших в первые два пункта
В ходе анализа профиле определяется:
- Соответствуют ли авторизации профиля его назначению?
- Не предоставляет ли профиль расширенных полномочий, которые могут быть использованы для злоупотреблений?
Анализ сгенерированных профилей
Способ выгрузки списка сгенерированных профилей SAP:
- AIS system -> System Audit -> User Administration -> IS Users and Authorizations -> Profiles -> by activity group
- Транзакция: SA38, Отчет: RSUSR020
- Edit -> All selections
- Selection criteria: active versions, generated profiles
Анализ выбранных профилей:
- AIS system -> System Audit -> User Administration -> Profile Generator -> Activity group maintenance
- Транзакция: PFCG
- Выбирается группа для анализа кнопкой Display
Выполняемые проверки:
- Осмысленное описание профиля
- Цель и назначение профиля должны быть определены
- Диапазоны полномочий пользователей
- Транзакции, назначенные профилю (должны быть назначены только те транзакции, которые описаны в концепции)
- Назначенные профилю авторизации (не должно быть лишних авторизаций, особое внимание уделяется критичным авторизациям)
- Пользователи, назначенные в данную группу (не должно быть лишних людей)
Анализ запрограммированных профилей
Данный вид анализа также используется для сгенерированных профилей.
Способ выгрузки данных SAP:
- system -> System Audit -> User Administration -> IS Users and Authorizations -> Profiles -> by profile name or text
- Транзакция: SA38, Отчет: RSUSR020
- Кнопка where used list. Вывод списка пользователей, которым назначен профиль.
Выполняемые проверки:
- Достаточность описания назначения профиля и авторизаций
- Проверка авторизаций транзакций для объекта S_TCODE (какие транзакции можно выполнять?). Лишних транзакций быть не должно.
- Проверка авторизаций для объектов, имеющих организационные ограничения (если профиль предназначен для работы во определенном коде компании, то в объекты должны быть включены только авторизации, имеющие данный код компании)
- Проверка соответствия значений активности (поле ACTVT) назначению профиля. Если профиль предназначен только для просмотра, то в каждом объекте профиля поле ACTVT должно содержать значение 03 (Display)
- Все авторизации и объекты должны соответствовать назначению профиля. (Например, для бухгалтерии авторизации должны относится к классу объектов F_XXX).
- Пользователи, которым назначен данный профиль (не должно быть лишних людей).
Анализ авторизаций на установленные лимиты
Необходимо проанализировать орг. структуру организации, определяемую в SAP ERP, на предмет того, какие лимиты денежных средств и прочие ограничения установлены для подразделений и должностных лиц. Затем сопоставить данные лимиты с соответствующими нормативными документами организации.
Оракл для начинающих | Oracle for beginners (18+): Роли и полномочия (привилегии) в Oracle
После аутентификации пользователя в базе данных, ему разрешается выполнять в ней действия над данными. Но какие действия? Над какими данными? Ответы на
эти вопросы зависят от полномочий, предоставленных пользователю.
Не имея никаких полномочий, пользователь не может выполнять никакие действия с БД, даже установить соединение с ней. Поэтому для работы, пользователь как
минимум должен иметь право на подключение к БД. С другой стороны, большинству пользователей не требуется создавать или удалять таблицы БД, поэтому
привилегии на создание и удаление таблиц они не имеют.
Полномочия могут назначаться как отдельным пользователям, так и ролям. Роль – это именованный набор полномочий. Использование ролей существенно облегчает
управление привилегиями. Вместо того, чтобы предоставлять десятки полномочий каждому пользователю, можно создать несколько типичных ролей (например —
пользователь, администратор, …), наделить их необходимыми полномочиями и назначить пользователям их роли. В дальнейшем, будет гораздо легче лишить
пользователя роли, нежели отобрать у него список нежелательных полномочий.
И полномочия, и роли предоставляются пользователям оператором GRANT, а отбираются соответственно — REVOKE.
GRANT INSERT, UPDATE, DELETE, SELECT ON ZVEZDA.MY_TABLE TO SCOTT;
— Даст пользователю SCOTT полномочия на вставку, изменение, удаление и выборку данных из таблицы MY_TABLE схемы ZVEZDA.
REVOKE DBA FROM SCOTT;
— Лишит пользователя SCOTT полномочий роли DBA.
Создаются, изменяются и удаляются роли стандартными операторами DDL – CREATE, ALTER и DELETE.
CREATE ROLE ZVEZDA_MANAGER IDENTIFIED BY xyz123;
— Создаст защищенную паролем «xyz123» роль ZVEZDA_MANAGER;
GRANT SELECT ON ZVEZDA.CUSTOMERS TO ZVEZDA_MANAGER;
— Предоставит полномочия на выборку данных из таблицы ZVEZDA.CUSTOMERS роли ZVEZDA_MANAGER;
GRANT ZVEZDA_MANAGER TO SCOTT;
— Предоставит полномочия роли ZVEZDA_MANAGER пользователю SCOTT.
— обзор
Специальные методы обоснования
Стандартные DL Логисты могут отвечать на сложные вопросы и проверять структурные и неструктурные ограничения. Более того, выразительность языка на основе DL часто превосходит классические решения (такие как UML для проектирования и SQL для моделей хранения данных). Это поддерживает описание и проверку более сложных структурных ограничений. Например, если мы рассмотрим подход, использованный Finin et al. [50], в котором роли представлены как отдельные лица класса Role, роль roleHierarchy : Role → Role Свойство 3 используется для подключения каждой роли к ее прямым подролям, а canHaveRole +: Identity → Role Свойство используется для представления ролей, которые каждый идентификатор (пользователь) может активировать, прямо или косвенно, благодаря наличию положительных авторизаций ролей.Таким образом, roleHierarchy ( r 1 , r 2 ) означает, что роль r 1 является надролью r 2 . Его транзитивное закрытие canBe +: Роль → Роль может использоваться для идентификации всех прямых или косвенных подроли. Отношение подроли (а также ее обратной суперроли) не является сдерживающим фактором и не определяет таксономию идентичностей (суперроль роли R должна быть более привилегированной, чем R, и доступна для более ограниченного набора идентичностей).
С помощью этих инструментов можно, например, предложить немедленное управление ограничениями SoD. Отношение назначения ролей пользователя представлено с помощью полномочий ролей, которые специализируют авторизации с указанием роли, которую принципалу разрешено или запрещено принимать. Ограничение SoD между ролью r 1 и r 2 затем может быть выражено с помощью отрицательной авторизации роли r auth , которая запрещает роли r 1 вводить в действие роль r 2 .Ограничения SoD применяются как на уровне иерархии ролей (таким образом, мы напрямую предотвращаем объявление роли r 1 над ролями другой роли r 2 , так что r 1 и r 2 находятся в ограничении SoD) и на уровне иерархии пользователей (чтобы две роли r 1 и r 2 не были прямо или косвенно назначены пользователю, который участвует в Ограничение SoD).
Чтобы показать более конкретный пример, мы предполагаем, что класс RoleAuthorization ⊆ Authorization представляет полномочия ролей, а свойства grantTo : RoleAuthorization → Principal и enabledRole : Используется RoleAuthorization 5 → 9000 для представления, соответственно, роли, разрешенной авторизацией роли, и принципала, которому назначена роль. Чтобы отслеживать все конфликты SoD в ролях, мы можем определить класс SoDOnRole ⊆ Role .Ограничения SoD на иерархию ролей могут быть выражены добавлением к онтологии следующего набора аксиом:
∀auth∈RoleAuthorization: sign (auth, -), grantTo (auth, r1), enabledRole (auth, r2) SoDOnRole≡∃canBe + . {r1} ∩∃canBe +. {r2}
Интерпретация этих аксиом заключается в том, что для каждой авторизации отрицательной роли существует экземпляр в классе SoDOnRole, только если существует единственная роль, которая принадлежит r 1 и к r 2 . Таким образом, мы можем обеспечить соблюдение SoD на уровне иерархии ролей, просто добавив в онтологию аксиому SoDOnRole ⊆ ⊥, которая объявляет онтологию согласованной только в том случае, если класс пуст.
Аналогично тому, что мы сделали для идентификации конфликтов SoD на уровне иерархии ролей, мы можем определить класс SoDOnUser ⊆ Identity , который отслеживает конфликты в иерархии пользователей. Затем мы выражаем ограничения SoD, используя следующие аксиомы:
∀auth∈RoleAuthorization: sign (auth, -), givenTo (auth, r1), enableRole (auth, r2) SoDOUser≡∃canHaveRole +. {R1} ∩∃canHaveRole +. { r2}
и для обеспечения соблюдения ограничений SoD нам просто нужно добавить в онтологию аксиому SoDOnUser ⊆ ⊥.
Этот подход может быть легко расширен для обработки других видов ограничений SoD, таких как SoD на основе разрешений (который требует, чтобы ни один пользователь не мог выполнять оба действия a 1 и a 2 ) или Объектно-ориентированный SoD (который требует, чтобы ни один пользователь не имел доступа к Ресурсам res 1 и res 2 ). Однако системы DL, а также инструменты Semantic Web в целом разработаны и реализованы с упором на услуги управления знаниями, такие как интеграция знаний, сопоставление схем и поиск экземпляров.Такая специализация накладывает некоторые ограничения на использование чистого рассуждения DL в реальных сценариях, в которых рассуждение должно проводиться на основе четко определенного и полного описания закрытой системы.
Предположение о закрытом мире
Рассуждения о предположении о закрытом мире (CWA) является общепринятым требованием в модельно-управляемых системах. И наоборот, рассуждающие о DL обычно работают в соответствии с Допущением открытого мира. Это означает, что факты, заявленные в модели (о топологии макета или политиках авторизации), не считаются полными.Очевидно, это может стать проблемой, если характеристики модели описываются в терминах существования некоторых свойств или некоторых отношений между элементами модели.
Рассуждения о сложных путях свойств
Рассуждения о сложных путях свойств (коммутативно нетривиальных графов) создает неопределенность формальной логики, на которой основан язык. Проверка закрытия сложных путей выходит за рамки выразительных возможностей классических систем баз данных, но, к сожалению, иногда необходимо проверять структурные ограничения.Так обстоит дело, например, с циклом согласованности на рис. 55.14, в котором указано, что:
Рис. 55.14. Простое ограничение согласованности.
разрешение на выполнение действия должно быть назначено ресурсу (базе данных), который работает в системе (СУБД), совместимой с типом действия (Выбрать, Создать, Удалить).
Допущение уникального имени
Допущение уникального имени — общепринятое допущение в большинстве инструментов, управляемых моделями. Он состоит из предположения, что разные имена всегда будут обозначать разные элементы в модели.Обычно это неверно для рассуждающих о DL из-за существенного характера проблем интеграции знаний. Фактически, в сценарии семантической паутины разные авторы могут описывать одни и те же объекты (как общие концептуализации, так и физические объекты), присваивая новое имя, как правило, в форме универсального идентификатора ресурса, определенного независимо от других пользователей.
Эти свойства необходимо тщательно учитывать при применении инструментов DL и семантической сети для обнаружения конфликтов политик.Введенные препятствия можно устранить, если на них уделять внимание. В противном случае можно наблюдать неправильное поведение системы.
Роли и полномочия — SAP-документация
SAP предоставляет стандартные роли PFCG, которые можно изменять в соответствии со своими требованиями, вырезая и вставляя соответствующие разделы в роль PFCG для конкретного клиента. Стандартные роли предназначены для использования в NetWeaver Business Client (NWBC). В следующей таблице приведены примеры стандартных Роли PFCG:
Роль |
Область применения |
---|---|
SAP_SAWE_UNIVERSAL |
Экономичный персонал |
SAP_CATS_LEAN_STAFFING |
Роль для перехода к приложению CATS WD |
Примечание
Роль SAP_CATS_LEAN_STAFFING предназначена только для использования при определении цели навигации (OBN) для CATS приложения Web Dynpro.Эта навигация происходит в списке работ Назначения персонала на сотрудника
, который более подробно описан в Power
Составьте список назначений сотрудников на каждого сотрудника. Роль SAP_CATS_LEAN_STAFFING не содержит видимых пунктов меню.
Конец заметки.
Использовать
Роль PFCG SAP_SAWE_UNIVERSAL содержит профиль полномочий, который можно использовать в качестве шаблона для разработки полномочий для конкретного клиента. Дополнительные сведения об этих объектах авторизации см. В Руководстве по безопасности SAP for Professional Services по адресу http: // help.sap.com под SAP ERP
SAP ERP Central Component
Межприложения SAP ERP Функции
Руководства по безопасности mySAP ERP
SAP ECC Industry Extension Professional Services
Commercial
Начало проекта и бережливое укомплектование персоналом
.
Чтобы использовать функции Lean Staffing и Forecasting, вы создаете и применяете роли PFCG, которые обрабатываются во внутренней системе с помощью транзакции PFCG. Роли PFCG определяют объем полномочий для предоставления пользователям (например, для изменения или отображения данных о персонале) в соответствии с бизнес-роль, назначенная пользователю, как описано в следующей таблице.
Бизнес-роль |
Объем авторизации |
---|---|
Сотрудник |
Изменение или отображение только собственных данных . |
Офисный помощник |
Ведение данных прогноза для определенной группы сотрудников с прямым или косвенным подчинением менеджеру. |
Менеджер проекта, менеджер по консультированию, менеджер по доставке |
Ведение как собственных данных прогноза, так и данных прогноза конкретной группы сотрудников с использованием прямых или косвенных линий отчетности. |
Суперпользователь |
Ведение данных прогноза для всех сотрудников. |
Стол | Описание |
AGRR2 | Передаточная структура R2 |
AGRR2T | R2 Структура передачи ролей Тексты |
AGR_1016 | Название профиля группы действий |
AGR_1016B | Название профиля группы действий |
AGR_1250 | Данные полномочий для группы действий |
AGR_1251 | Данные полномочий для группы действий |
AGR_1252 | Организационные элементы для авторизации |
AGR_1253 | Данные авторизации для статических объектов группы действий |
AGR_AGRS | Роли в составных ролях |
AGR_AGRS2 | Определение роли |
AGR_ATTS | Ролевые атрибуты |
AGR_BOR_DTL | Расширенная информация о BOR для узлов меню |
AGR_BUFFI | Интернет-ссылки для роли |
AGR_BUFFI2 | Таблица Интернет-ссылок Клиентская версия ролей SAP |
AGR_BUFFI3 | Таблица Интернет-ссылок Версии SAP ролей SAP |
AGR_CATS | Структура передачи для категорий / начало PFCG |
AGR_CUSTOM | Роль Настройка объектов |
AGR_DATEU | Персональные настройки для ролей |
AGR_DEFINE | Определение роли |
AGR_EXT_DTL | Расширенная информация для узлов меню |
AGR_FAVOS | Персональные настройки для PFCG |
AGR_FILT | Фильтр таблицы передачи для PRGN_TREE_START |
AGR_FLAGS | Ролевые атрибуты |
AGR_FLAGSB | Ролевые атрибуты |
AGR_HIER | Таблица структурной информации для меню |
AGR_HIER2 | Информация о структуре меню Клиентская версия SAP роли |
AGR_HIER3 | Информация о структуре меню Версия SAP ролей SAP |
AGR_HIERT | Тексты меню ролей |
AGR_HIERT2 | Тексты меню ролей Клиентская версия объектов SAP |
AGR_HIERT3 | Тексты меню ролей SAP Original |
AGR_HIER_BOR | Таблица для объектно-ориентированной навигации (OBN) |
AGR_HPAGE | Домашняя страница ролей |
AGR_HPAGET | Описание домашней страницы для роли |
AGR_ICON | Отображение значка состояния в генераторе профилей |
AGR_INFO | Значения фильтра из цикла генерации |
AGR_LOGSYS | Логическая система |
AGR_LSD | Ролевые атрибуты |
AGR_MAP | MiniApp и текст |
AGR_MAPP | Мини-приложения в роли |
AGR_MAP_KNUMA | Таблица преобразования AG_GUID CRM <> KNUMA |
AGR_MARK | Таблица для отчета SAPPROFC_NEW |
AGR_MEM_INITIAL | Соглашения: буфер для начальной загрузки |
AGR_MINI | Мини-приложения в роли |
AGR_MINI2 | Мини-приложения в роли |
AGR_MINIT | Ролевые мини-тексты |
AGR_MINIT2 | Тексты ролевых мини-приложений |
AGR_NSPCE | Пространство имен |
AGR_NUMBER | Внутренний счетчик для присвоения имен профилей |
AGR_NUM_2 | Внутренний счетчик для присвоения имен профилей |
AGR_OBJ | Назначение узлов меню роли |
AGR_POPUP | Структура диалогового окна |
AGR_POPUP2 | Структура для присвоения транзакции |
AGR_POPUP3 | Вспомогательная структура для ввода объектов полномочий |
AGR_PROF | Имя профиля для роли |
AGR_REL_KNUMA_CM | Назначение: Соглашение> Кампания |
AGR_SELECT | Назначение ролей кодам |
AGR_SHIER | Структура для инструмента перетаскивания |
AGR_SHIERT | Структура для инструмента перетаскивания |
AGR_SHIER_BOR | Структура для дополнительных сведений без поля STRING |
AGR_SMENU | Структура передачи для ведения роли |
AGR_SPRTXT | Структура для инструмента перетаскивания |
AGR_START | Ведение стартовой роли: структура для дерева |
AGR_STRING | Структура для инструмента перетаскивания |
AGR_STRUC | Структура для передачи Tcodes в генератор профилей |
AGR_ST_NAME | Имя роли |
AGR_TAB | Структура передачи стартового дерева PFCG |
AGR_TCDTXT | Назначение ролей кодам |
AGR_TCODE3 | Назначение ролей кодам |
AGR_TCODES | Назначение ролей кодам |
AGR_TCODES_TEXTS | Коды транзакций с текстами из AGR |
AGR_TEXTS | Файловая структура для клиента с иерархическим меню |
AGR_TIME | Отметка времени для роли (меню, профиль, авторизации) |
AGR_TIMEB | Отметка времени для роли (создание профиля) |
AGR_TIMEC | Отметка времени для роли (назначение пользователя) |
AGR_TIMED | Отметка времени для роли (сравнение профилей, распространение RFC) |
AGR_TRAN | Транспортные модули внешних объектов персонализации |
AGR_TRANS | Структура справки для перевода |
AGR_TXT | Роль и текст |
AGR_UPLO | Структура для типов узлов загрузки |
AGR_UPLT | Структура для типов узлов загрузки |
AGR_UPLTX | Структура для текста описания загрузки |
AGR_USERS | Назначение ролей пользователям |
AGR_USERT | Назначение ролей пользователям |
USH02 | История изменений для данных входа в систему |
USH02_ARC_TMP | История изменений для данных входа в систему: последние записи из архива |
USH04 | История изменений авторизаций |
USH04_ARC_TMP | История изменений авторизаций: последние записи из архива |
УШ20 | История изменений профилей авторизации |
УШ20_ARC_TMP | История изменений данных профиля: последние записи из архива |
УШ22 | История изменений значений полномочий |
УШ22_ARC_TMP | История изменений авторизаций: последние архивные записи |
УСР01 | Основная запись пользователя (данные времени выполнения) |
УСР02 | Данные для входа в систему (использование на стороне ядра) |
УСР03 | Данные адреса пользователя |
УСР04 | Права доступа пользователя к мастеру |
USR05 | ID главного параметра пользователя |
USR06 | Дополнительные данные на пользователя |
USR06SYS | Системная классификация пользователей (в связи с лицензией) |
УСР07 | Объект / значения последней неудачной проверки авторизации |
USR08 | Таблица для записей меню пользователя |
USR09 | Записи для пользовательских меню (рабочие области) |
USR10 | Основные профили авторизации пользователей |
ЕСР11 | Пользовательские мастер-тексты для профилей (USR10) |
УСР12 | Значения авторизации главного пользователя |
USR13 | Краткие тексты для авторизации |
ЕГР14 | Дополнительные языковые версии на пользователя |
USR15 | Имя внешнего пользователя (заменено таблицей USRACL) |
USR16 | Значения переменных для авторизации пользователей |
USR20 | Дата последней реорганизации основного пользователя |
УСР21 | Назначить имя пользователя адресным ключом |
УСР21С | Теневая таблица: присвоение имени пользователя адресному ключу |
USR22 | Данные входа в систему без доступа к ядру |
USR30 | Дополнительная информация для меню пользователя |
USR40 | Таблица нелегальных паролей |
УСР41 | Мастер пользователя: дополнительные данные |
USR41_MLD | Данные транзакции для USR41 |
USRACCNTV | Сгенерированная таблица для просмотра USRACCNTV |
USRACL | Список управления доступом SNC (ACL): пользователь |
USRACLEXT | Расширенный список управления доступом SNC (ACL) для пользователей |
USRARCSTAT | Повторно загруженные архивные прогоны |
USRATTR | Дополнительные атрибуты для пользователей |
УСРБФ | Содержимое пользовательского буфера для быстрого входа в систему RFC |
УСРБФ2 | Содержимое пользовательского буфера для быстрого входа в систему RFC новый |
УСРБФ3 | Содержимое пользовательского буфера для быстрого входа в систему RFC Новый |
USRCD | Структура для просмотра документов изменений в RSUSR100 |
USRCDT | Структура документов изменений (технический ракурс) |
USRCOBJ | Фильтры объектов для разнесения структур продукта |
USRCOMB | Критические комбинации разрешений |
USRCOMBT | Краткие тексты для критических комбинаций полномочий |
USRCRCOMB | Список вариантов для критических комбинаций аутентификаций |
USRDFLT | Комбинация полей / значений пользовательских настроек |
USRDFLT_KEY | Ключ для пользовательских настроек |
USRDFLT_PERS | Настройки пользователя |
USRDFLT_PERS_ALV | Настройки пользователя ALV Display |
USREF | Структура переноса для функциональных модулей перекрестных ссылок |
USREFUS | Эталонный пользователь интернет-приложений |
USREFUSVAR | Назначение переменной справочного пользователя справочнику |
УСРЭЛ_2 | Администрирование пользователей: взаимосвязь между двумя объектами |
УСРЭЛ_3 | Администрирование пользователей: взаимосвязь между тремя объектами |
USREL_AT | Администрирование пользователей: пользователь во взаимосвязи (со временем) |
USREL_SA | GUM: назначение роли / должности системе (тип) |
USREL_UA | GUM: назначение роли пользователю |
USREL_US | GUM: назначение пользователя (группы) системе (тип) |
USREL_USA | Администрирование пользователей: группа активности системы пользователей |
USREL_UT | Администрирование пользователей: пользователь во взаимосвязи (со временем) |
USREL__A | Администрирование пользователей: группа активности системы |
USREL__S | Администрирование пользователей: система во взаимоотношениях |
USREL__U | Администрирование пользователей: взаимосвязанный пользователь |
USREXTID | Назначение внешнего идентификатора пользователям |
USREXTIDH | Внешний идентификатор (доступ с использованием значения хэша) |
USREXTIDT | Таблица значенийдля типа внешнего идентификатора |
USREXTIDTT | Таблица значений для типа внешнего идентификатора (тексты) |
USRFIELD | Централизованное обслуживание пользователя: разрешено обслуживание на месте или не |
USRFLD | CUA: Определение логических полей |
USRFLDDEF | CUA: Определение имен логических полей распределенного ALE Пользователи |
USRFLDGRP | CUA: Группы выбора полей |
USRFLDSEL | CUA: Атрибуты поля |
USRFLDT | CUA: Текстовая таблица для определения логических полей |
USRFLDTSEL | Выбор полей |
USRFLDVAL | CUA: критерии выбора для атрибутов поля |
УСРГЕНПРС | Таблица общих данных персонализации рабочего места |
USRGETFTR | Структура передачи |
USRGETSTRC | Структура для передачи пользователя |
USRGIFAV | Интерфейс iPPE: Favorite |
USRGIFOL | Интерфейс iPPE: папка |
УСРГИПРОФИЛ | Назначение пользователя профилю iPPE |
USRGIPROFIL_DYNP | Структура диалогового окна: назначение пользователя Инструментальные средства iPPE |
USRGIPROFIL_WTY | Назначить профиль пользователя |
USRGISETING | Пользовательские настройки для iPPE Workbench |
USRGISTACK | Инструментальные средства iPPE: стек |
УСРИНФО | Расширенная информация пользователя для SM04 |
УСРИНКОН | Справочная таблица FM для определения несоответствий |
USRLISTPROFILE | Определение списка переменных в среде PDM |
USRLUIPROFILE | Назначение пользователей профилям в iPPE Workbench Express |
USRLUIPROFILE_DYNP | Назначения пользователей профилям |
УСЛУГИ | Пользовательские настройки iPPE Workbench Express |
USRLUISETTINGS_DYNP | Пользовательские настройки для профиля |
УСРМ0 | Пользовательские настройки основных записей материалов: экранный справочник пользователя |
УСРМ1 | Пользовательские настройки основных записей материалов: организационные уровни |
УСРМ2 | Пользовательские настройки для основных записей материалов: логические экраны |
УСРМ3 | Основные пользовательские настройки материалов: Розничная торговля Уровни |
USRMETHOD | Метод, который вызывается при распределении пользователей |
УСРММ | Пользовательские настройки: основная запись материала |
УСРОБЕКТЫ | Таблица предыдущего исходного объекта в обзоре структуры |
УСРПДМ | Пользовательские данные в среде PDM |
ИСТОРИЯ USRPWD | История паролей |
USRSETTINGS_DYNP | Настройки пользователя: структура диалогового окна дерева навигации |
USRSTAMP | Отметка времени для всех изменений пользователя |
USRSYSACT | CUA: роли в распределенных системах |
USRSYSACTT | CUA: роли в распределенных системах |
USRSYSLNG | Язык пользователей в системе |
USRSYSPRF | CUA: Профили в распределенных системах |
USRSYSPRFT | CUA: Текст профиля в распределенных системах |
USRSYSUPL | CUA: прайс-листы в системе SAP |
USRSYSUPPL | CUA: присвоение типов пользователей прайс-листам |
USRSYSUTPA | CUA: Измерение системы: типы пользователей с атрибутами |
USRSYSUTYP | CUA: тексты для типов пользователей в системе SAP |
USRSYSUZUS | CUA: Тексты для специальных версий |
USRSYSVTYP | Сгенерированная таблица для просмотра USRSYSVTYP |
USRTICLASS | Назначение класса для табличного обслуживания iPPE |
USRTREECOL | Пользовательские перестановки столбцов для каждого типа массива |
USRURLPRS | Таблица персонализации услуг |
USRURLSVR | Логические веб-серверы для логических систем (для конкретных пользователей) |
УСРВАР | Варианты критических разрешений |
УСРВАРКОМ | Варианты критических комбинаций разрешений |
USRVARCOMT | Краткие тексты вариантов критических разрешений |
USRVARID | Список вариантов для критических разрешений |
УСРВАРТ | Краткие тексты вариантов критических разрешений |
USRVIEWCOL | Пользовательский столбец |
USRVIEWTAB | Просмотр полосок вкладок для конкретного пользователя |
УСР_АУФК | Пользовательские поля AUFK |
USR_FLAGS | Различные флаги для программ авторизации |
USR_FLGNT | Персональные настройки пользователя / без транспорта |
USR_LIST | Сгенерированная таблица для представления USR_LIST |
USR_QUERY | Запрос BW |
USR_TREESNODE | Узловая структура простого дерева (отчет SAPTREX3) |
USR_VALUES | Структура передачи для выбора в соотв.в авт. значения |
Управление доступом на основе ролей
Управление доступом на основе ролей (RBAC) относится к идее назначения разрешений пользователям в зависимости от их роли в организации. Он предлагает простой и управляемый подход к управлению доступом, который менее подвержен ошибкам, чем индивидуальное назначение разрешений пользователям.
При использовании RBAC вы анализируете потребности своих пользователей и группируете их по ролям на основе общих обязанностей. Затем вы назначаете одну или несколько ролей каждому пользователю и одно или несколько разрешений для каждой роли.Отношения «пользователь-роль» и «роль-разрешения» упрощают выполнение назначений пользователей, поскольку пользователям больше не нужно управлять индивидуально, а вместо этого они имеют привилегии, соответствующие разрешениям, назначенным их ролям.
Например, если вы использовали RBAC для управления доступом к HR-приложению, вы могли бы дать HR-менеджерам роль, которая позволяет им обновлять сведения о сотрудниках, в то время как другие сотрудники смогут просматривать только свои собственные данные.
При планировании стратегии управления доступом рекомендуется назначать пользователям наименьшее количество разрешений, позволяющих им выполнять свою работу.
С RBAC управление доступом становится проще, если вы строго придерживаетесь требований к ролям. RBAC помогает:
-
создавать систематические, повторяемые назначения разрешений
-
легко проверять права пользователей и исправлять выявленные проблемы
-
быстро добавлять и изменять роли, а также реализовывать их через API
-
сокращать о возможности возникновения ошибки при назначении разрешений пользователей
-
интегрируйте сторонних пользователей, давая им заранее определенные роли
-
более эффективно соблюдайте нормативные и законодательные требования по конфиденциальности и конфиденциальности
По сути, роль набор разрешений, которые вы можете применять к пользователям.Использование ролей упрощает добавление, удаление и настройку разрешений, чем назначение разрешений пользователям по отдельности. По мере увеличения масштабов и сложности вашей пользовательской базы роли становятся особенно полезными.
Вы также можете использовать роли для сбора разрешений, определенных для различных API. Например, предположим, что у вас есть маркетинговый модуль, который позволяет пользователям создавать и распространять информационные бюллетени для клиентов. Ваш специалист по маркетинговому контенту создает все информационные бюллетени и готовит их к распространению.Точно так же у вас есть модуль событий, который позволяет пользователям создавать, публиковать и управлять регистрацией событий. Ваш координатор событий создает события. Как только вице-президент по маркетингу утверждает информационные бюллетени и события, его помощник публикует события и распространяет информационные бюллетени. В этом случае ваш API информационных бюллетеней может иметь разрешение distribute: newsletters
, а ваш API событий может иметь разрешение publish: events
. Затем эти разрешения можно собрать в роли Marketing Publisher
и назначить помощнику вице-президента по маркетингу.
Кроме того, для членов организации можно добавить роли организации и использовать их для разрешения доступа в вашем приложении в зависимости от организаций, в которых конечный пользователь входит в систему. Это особенно полезно при поддержке продуктов с несколькими арендаторами и SaaS, где конкретный пользователь может иметь привилегированную роль в одной организации, но не в других.
RBAC — это аддитивная модель, поэтому, если у вас есть перекрывающиеся назначения ролей, ваши действующие разрешения являются объединением назначений ролей.
Например, предположим, что у вас есть API, который предоставляет данные для приложения событий. Вы создаете роль Организатор
и назначаете ей разрешения, которые позволяют ему просматривать, создавать и редактировать события. Вы также создаете роль Регистранта
и назначаете ему разрешения, которые позволяют ему просматривать и регистрироваться для событий. Любые пользователи с ролями Организатор
и Регистрант
смогут просматривать, создавать, редактировать и регистрироваться на мероприятиях.
В настоящее время мы предоставляем два способа реализации контроля доступа на основе ролей (RBAC), которые вы можете использовать вместо или в сочетании с собственной системой внутреннего контроля доступа вашего API:
Мы расширяем наш набор функций ядра авторизации, чтобы он соответствовал функциональность Расширения авторизации.Наша новая базовая реализация RBAC улучшает производительность и масштабируемость и в конечном итоге предоставит более гибкую систему RBAC, чем расширение авторизации.
На данный момент оба реализуют ключевые функции RBAC и позволяют ограничивать настраиваемые области, определенные для API, теми, которые были назначены пользователю в качестве разрешений. Для сравнения см. Ядро авторизации и расширение авторизации.
Набор функций ядра авторизации и расширение авторизации — это совершенно разные функции.Для управления группами, ролями или разрешениями вам нужно будет использовать функцию, в которой они были изначально созданы.
Вы можете обеспечить больший контроль, используя правила для ограничения доступа на основе комбинации атрибутов, таких как отдел пользователя, время суток , местонахождение доступа или любой другой атрибут пользователя или API (например, имя пользователя, уровень допуска или имя API).
Для получения дополнительной информации об использовании правил с политиками авторизации см. Правила с политиками авторизации.
Авторизация с использованием ролевого контроля доступа
Управление доступом на основе ролей (RBAC) — это метод управления доступом к системе. на основе ролей, назначенных пользователям в организации.RBAC определяется вокруг предопределенных ролей и привилегий связанные с этими ролями (также известные как привязки ролей ). Роли — это коллекция разрешений, которые вы можете привязать к ресурсу; эта привязка позволяет выполнять привилегии, связанные с этой ролью, на этом ресурсе. Вы должны предоставить роль принципалу во время привязки ресурса к роли.
Используя RBAC, вы можете управлять доступом к определенным ресурсам Confluent Platform и действиями пользователь может работать с этим ресурсом.RBAC использует службу метаданных Confluent Platform для настройки и управления реализацией RBAC из централизованной конфигурации контекст, тем самым упрощая управление доступом к ресурсам Confluent Platform.
Перед внедрением RBAC вы должны оценить потребности пользователей в безопасности в вашем организации и, исходя из ресурсов, которые им необходимы для выполнения своих обязанностей, группируйте пользователей в роли, удовлетворяющие этим требованиям. См. Примеры использования ролей RBAC для примера этой задачи планирования.Рекомендуется ограничивать пользователей минимально необходимая роль, необходимая им для выполнения поставленных задач.
Как и ACL, RBAC использует принципалов, поэтому вы можете связать любого принципала с клиент использует роль RBAC, которая авторизована Confluent Server Authorizer для связи как с RBAC, так и с ACL. Для получения дополнительной информации о Confluent Server Authorizer см. Обзор. Роли RBAC не поддерживают ОТКАЗАТЬ правила, и нет никакой разницы в том, как вы создаете и используете устаревшие на основе ZooKeeper ACL при использовании RBAC.Однако, если вы собираетесь продолжать использовать ACL, мы рекомендуем вам перейти на централизованные ACL, которые хранят информацию ACL в MDS, как и привязки ролей. Наследие ZooKeeper на основе Тем временем ACL будут продолжать работать.
Дополнительные сведения о включении и настройке RBAC см. В разделах Параметры конфигурации службы метаданных и Настройка службы метаданных (MDS).
Преимущества RBAC
RBAC поможет вам:
- Управляйте безопасным доступом через платформу Confluent (Kafka, ksqlDB, Connect, Schema Registry, Confluent Control Center) с помощью детализированные разрешения для управления доступом пользователей и групп.Например, с RBAC вы можете указать разрешения для каждого соединителя в кластере, что упростит и быстрее установить и запустить несколько разъемов.
- Управляйте авторизацией в масштабе. Администраторы могут централизованно управлять назначение предопределенных ролей, а также делегирование ответственности управления доступом и разрешениями для различных отделов или бизнес-единиц кто являются настоящими владельцами и наиболее знакомы с этими ресурсами.
- Централизованное управление аутентификацией и авторизацией для нескольких кластеров, которые включает: MDS, кластер Kafka, Connect, ksqlDB, кластеры реестра схем и единый экземпляр Confluent Control Center.
Как работает RBAC
Предопределенные назначения ролей определяют, кто может получить доступ к определенным ресурсам Confluent Platform и какие
действия, которые отдельный пользователь может выполнять в пределах этого ресурса. Администратор
назначает заранее определенные роли пользователям и группам на различных ресурсах; каждый пользователь может
получить несколько ролей на каждом ресурсе. Определенные привилегированные пользователи (например,
UserAdmin
или SystemAdmin
) назначают роли пользователям и группам, а затем
сопоставить определенные ресурсы с этими ролями пользователей.Например, ResourceOwner
в
финансовый отдел может предоставить членам отдела доступ ко всем темам, которые используют
префикс finance_
, который упрощает управление ресурсами
с которым они наиболее знакомы.
Администраторы пользователей могут добавлять пользователей и группы LDAP, делая это быстрее и проще. для централизованной настройки аутентификации и авторизации для различных ресурсов Confluent Platform используется в организации.
Обзор RBAC
С помощью RBAC администратор пользователей может назначать роли пользователям LDAP. и группы, привязанные к определенным ресурсам (привязка ролей).После роли привязка устанавливается с помощью Confluent CLI confluent iam rolebinding create команда, пользователи не могут перейти к API или Confluent Control Center для обхода и получения доступа к ресурсам. Привязка ролей к группам позволяет администраторам клиентов избегать предоставления явного доступа к каждому пользователь по каждому компоненту. Подробнее о просмотре привязок ролей см. Confluent CLI confluent iam rolebinding list команда. Обратите внимание, что привязка ролей не поддерживает подстановочные знаки. соответствие в основных именах. Дополнительные сведения см. В разделе Принципы подстановки.
Примечание
При настройке привязок ролей ( confluent iam rolebinding create
), если вы
необходимо устранить неполадки, может быть полезно просматривать журналы аудита на лету, чтобы определить
события авторизации для определенных участников, ресурсов или операций. Для
подробности см. в разделе «Просмотр журналов аудита на лету».
Confluent Platform позволяет администраторам кластера централизованно регистрировать Кластеры Kafka в службе метаданных (MDS) для обеспечения более удобного использования RBAC опыт привязки ролей.Дополнительные сведения см. В разделе «Реестр кластеров».
RBAC и ACL
RBAC служит дополнительным уровнем обеспечения авторизации наверху списков ACL и не меняет способ создания списков ACL или удалось. При рассмотрении вопроса о том, использовать ли RBAC или ACL для управления доступом, следует предлагается использовать RBAC по умолчанию из-за простоты использования и управляемости. в масштабе, но для крайних случаев, когда вам нужно иметь более детальный контроль доступа, или желаете явно запретить доступ, ACL могут иметь больше смысла.Например, вы может использовать RBAC для разрешения доступа группе пользователей, но ACL для запрета доступа для конкретного члена этой группы.
RBAC добавляет дополнительный механизм авторизации, который касается следующих проблемы с авторизацией при использовании ACL:
-
Без RBAC нельзя использовать ACL для предоставления доступа к соединителям. С RBAC каждый У коннектора есть собственный принципал, который определяет доступ к ресурсам. У пользователей есть доступ только для соединителей, для которых им явно предоставлено разрешение.Если вам нужен контроль доступа к коннектору, необходим RBAC.
-
RBAC предоставляет возможность предлагать пользователям Confluent Control Center детальный доступ к ресурсам; до RBAC, любой пользователь, имеющий доступ к Confluent Control Center, имел полный или доступ только для чтения к темам и ресурсам. Если требуется детальный контроль доступа в Confluent Control Center, рекомендуется использовать RBAC.
-
RBAC обеспечивает согласованный механизм аутентификации и авторизации для пользователей доступ ко всей платформе Confluent, что невозможно при использовании только ACL.
-
До RBAC создание и управление списками ACL могло быть трудным для управления и поддерживать, а в организациях с тысячами ресурсов и пользователей настройку ACL может занять много времени. С RBAC делегирование ответственности различным ресурсы управляются с помощью роли
ResourceOwner
.Например, скажем, вы отвечаете за управление доступом пользователей к 1000 темам. Используя RBAC, вы можете предоставить
ResourceOwner
другим пользователям для управления темами. принадлежат определенным бизнес-единицам, и, в свою очередь, эти пользователи могут управлять доступом для других в их собственных командах.Используя ACL в этом сценарии, вы нужно будет централизованно управлять доступом ко всем темам, что было бы время и ресурсоемкая задача.
Параметры аутентификации RBAC
Параметры аутентификации, используемые до внедрения RBAC, могут потребовать дополнительная конфигурация, или вам может потребоваться использовать другой метод аутентификации все вместе.
Важно
КомпонентыConfluent Platform, которые имеют конечную точку REST (например, реестр схем и Центр управления Confluent), не поддержка использования принципала, полученного из аутентификации mTLS, при использовании RBAC.Итак, если вы раньше полагались на проверку подлинности сертификата SSL на платформе Confluent Platform, настраивая RBAC, при использовании RBAC вы также должны предоставить HTTP Basic Учетные данные для аутентификации (например, пользователь LDAP) для аутентификации в других компонентах или конечные точки REST API.
HTTP Basic Auth представляет учетные данные для входа в другие компоненты Confluent Platform и
компонент использует эти учетные данные для получения OAuth
токен для пользователя с MDS (который проверяет учетные данные
против LDAP), а затем компонент использует токен OAuth для авторизации
запросы в МДС.Вы должны указать токен на предъявителя
для проверки подлинности HTTP Basic и, более конкретно, необходимо указать
basic.auth.user.info
и basic.auth.credentials.source
.
При настройке компонентов Confluent Platform (например, Confluent Control Center, ksqlDB и REST Proxy) для RBAC, используйте OAuth для аутентификации с кластерами MDS и Kafka. Для аутентификации с другими компонентами Confluent Platform используйте аутентификацию HTTP Basic.
При использовании RBAC с реестром схем и подключением вы можете использовать любой из методы аутентификации, поддерживаемые Confluent Platform для связи с кластерами Kafka и MDS.Для аутентификации с другой платформой Confluent компоненты, используйте базовую аутентификацию HTTP.
При использовании RBAC с клиентами Kafka вы можете использовать любой из методы аутентификации, поддерживаемые Confluent Platform , кроме OAUTHBEARER . Подробнее см. Настройка клиентов Kafka.
Опции аутентификации RBAC
Терминология
В RBAC используются следующие термины:
- Контроль доступа
- Доступ — это способность отдельного пользователя или приложения выполнять определенную задачу, например просматривать, создавать или изменять ресурс (например,грамм. темы). Контроль доступа обеспечивает безопасный доступ к сервисам и ресурсам Confluent Platform.
- Директор
- Идентификационные данные пользователя или программного обеспечения, запрашивающего разрешение на выполнение определенного действия с определенным ресурсом. Принципалы могут быть аутентифицированы или не аутентифицированы (АНОНИМНО).
- Принципал пользователя
- Единый идентификатор, привязанный к конкретному пользователю или программе.
- Принципал группы
- Общий идентификатор, который объединяет список участников-пользователей и / или других участников группы.
- роль
- Набор разрешений, позволяющих принципалам выполнять определенные операции.
- Ресурс
- Ресурс может быть темой Apache Kafka®, группой потребителей, идентификатором транзакции, кластером, реестром схемы, ksqlDB и любым другим компонентом Confluent Platform.
- Привязка ролей
- Комбинация принципала-роли-ресурса, которая позволяет принципалу для выполнения операций с ресурсом или набором ресурсов, как определено ролью.
- Управление доступом на основе ролей (RBAC)
- В RBAC разрешения связаны с ролями, а пользователям или группам назначаются соответствующие роли.Роли определяется в соответствии с должностными полномочиями, полномочиями и ответственностью на предприятии. Пользователи и группы легко переназначен с одной роли на другую. Разрешения, назначенные ролям, как правило, изменяются относительно медленно по сравнению с изменения в членстве пользователей в ролях.
Ограничения RBAC
Для оптимальной производительности вашей конфигурации RBAC мы рекомендуем придерживаться до этих пределов.
Ресурс | Предел |
---|---|
Привязки ролей | 1000 |
запросов в секунду (RPS) вызовов API для добавления, удалить или найти привязки ролей | 15 |
Централизованные ACL | До 1000 на кластер |
Важно
ID пользователя, указанный в привязках групповых ролей, зависит от случая и должен соответствовать случай, указанный в записи AD.Также обратите внимание, что при входе в систему как суперпользователь идентификатор входа также зависит от регистра и должен соответствовать регистру, указанному для пользователя. ID в привязках ролей.
коды ошибок RBAC
Для RBAC используются следующие коды ошибок HTTP-доступа пользователей:
Примечание
В некоторых случаях, когда учетные данные пользователя верны, но у пользователя нет правильные разрешения, вы ожидаете ошибку 403 вместо ошибки 404. В таких случаях возвращается код ошибки 403, чтобы избежать раскрытия подробностей о конкретные ресурсы.
- 401
- Не удалось войти в систему из-за отсутствия или недостаточности учетных данных (у пользователя отсутствуют достаточные разрешения).
- 403
- Учетные данные пользователя могут быть правильными, но не удалось войти, потому что у пользователя нет необходимые разрешения для определенного ресурса (например, Schema Registry или Connect).
- 404
- Not Found: пользователь имеет правильные учетные данные и доступ к ресурсу (например,
пользователь имеет роль
ResourceOwner
), но ресурс (например, Connect) не существует. - 502
- MDS недоступен. Обратитесь к администратору безопасности.
Schema Registry имеет много детализированных кодов ошибок, выходящих за рамки контекста RBAC. Видеть Справочник по API реестра схемы для описания ошибок HTTP реестра схемы (например, 40401) здесь не рассматривается.
Контрольный список внедрения RBAC
В этом разделе представлен контрольный список, который поможет вам спланировать внедрение RBAC.
Примечание
Ansible предлагает более простой способ настройки и развертывания RBAC и MDS.Обратитесь к настройкам Ansible RBAC для подробностей.
Для настройки RBAC:
☐ Установите Confluent Platform.
☐ Работайте со своей командой безопасности, чтобы оценить потребности пользователей в вашем организации и, исходя из ресурсов, которые им требуются для выполнения своих обязанности, определите, какие роли следует назначить пользователям и группам.
Описание некоторых типичных сценариев использования и требуемых ролей для каждого из них см. в сценарии использования ролей RBAC.
Для начальной загрузки RBAC необходимо определить супер-уровень уровня ACL.пользователь
в
Файл server.properties
брокера Kafka в кластере, на котором размещается MDS. Этот
super.user
может затем назначить роль SystemAdmin другому пользователю, который может создавать
требуемые кластеры и область требуемых привязок ролей для пользователей и групп.
Обязательно укажите, какой пользователь будет выполнять роль начальной загрузки super.user
. Для
подробности см. в разделе Предопределенные роли управления доступом на основе ролей.
☐ Настройте службу метаданных (MDS).
MDS реализует основные функции RBAC и связывается с LDAP для получения информации о пользователях и группах и аутентифицировать пользователей.После настройки MDS можно переходить к роли привязки и конфигурация других компонентов Confluent Platform.
См. Настройте поставщика удостоверений LDAP, чтобы просмотреть конфигурацию LDAP для MDS.
☐ После того, как вы определили, какие роли должны быть назначены пользователям и группам, создать соответствующие привязки ролей для пользователи для доступа к ресурсам (например, Schema Registry, ksqlDB, Connect и Confluent Control Center) они необходимы для выполнения своих обязанностей.
☐ Подтвердите роли пользователя и группы, которые вы определили с помощью конфлюентный список привязки ролей iam команда.
☐ Настройте компоненты Confluent Platform для связи с MDS для аутентификации и авторизация. Подробнее см .:
Демо
Чтобы увидеть рабочий пример управления доступом на основе ролей (RBAC), ознакомьтесь с демонстрацией Confluent Platform. Эта демонстрация и сопутствующее руководство показывают пользователям, как развернуть приложение потоковой передачи событий Apache Kafka®. Все компоненты в демонстрации имеют сквозную безопасность, включая RBAC.
Авторизация— Дополнительные понятия | Архитектура
В дополнение к ресурсам RBAC, которые управляют тем, что пользователь может сделать, OpenShift Container Platform предоставляет ограничений контекста безопасности (SCC), которые контролируют действия, которые может выполнять модуль выполнять и к чему у него есть доступ.Администраторы могут управлять SCC с помощью интерфейса командной строки.
SCCтакже очень полезны для управления доступом к постоянному хранилищу.
SCC — это объекты, которые определяют набор условий, с которыми модуль должен работать в чтобы быть принятым в систему. Они позволяют администратору контролировать следующее:
-
Запуск привилегированный контейнеры.
-
Возможности, которые контейнер может запросить для добавления.
-
Использование каталогов хоста в качестве томов.
-
Контекст SELinux контейнера.
-
ID пользователя.
-
Использование пространств имен хостов и сети.
-
Распределение
FSGroup
, которому принадлежат тома контейнера -
Настройка допустимых дополнительных групп
-
Требуется использование корневой файловой системы только для чтения
-
Контроль использования типов томов
-
Настройка допустимых профилей seccomp
Семь SCC добавляются в кластер по умолчанию и доступны для просмотра в кластере. администраторы, использующие CLI:
Пример вывода
ИМЯ PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES
anyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny 10 false [configMap downwardAPI emptyDir persistentVolumeClaim secret]
hostaccess false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <нет> false [configMap downwardAPI emptyDir hostPath persistentVolumeClaim secret]
hostmount-anyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny <нет> false [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim secret]
hostnetwork false [] MustRunAs MustRunAsRange MustRunAs MustRunAs false [configMap downwardAPI emptyDir persistentVolumeClaim secret]
nonroot false [] MustRunAs MustRunAsNonRoot RunAsAny RunAsAny false [configMap downwardAPI emptyDir persistentVolumeClaim secret]
привилегированный true [*] RunAsAny RunAsAny RunAsAny RunAsAny <нет> false [*]
ограничено false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <нет> false [configMap downwardAPI emptyDir persistentVolumeClaim secret]
Не изменяйте SCC по умолчанию.Настройка SCC по умолчанию может привести к проблемам при обновлении платформы OpenShift Container Platform. Вместо, Создайте новые SCC. |
Определение каждого SCC также доступно для просмотра администраторами кластера с помощью CLI. Например, для привилегированного SCC:
$ oc get -o yaml --export scc / привилегированный
Пример вывода
allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegedContainer: true
allowedCapabilities: (1)
- '*'
apiVersion: v1
defaultAddCapabilities: [] (2)
fsGroup: (3)
тип: RunAsAny
группы: (4)
- система: администраторы кластера
- система: узлы
вид: SecurityContextConstraints
метаданные:
аннотации:
кубернетес.io / description: 'привилегированный разрешает доступ всем привилегированным и хост-компьютерам
функции и возможность работать от имени любого пользователя, любой группы, любой fsGroup и с
любой контекст SELinux. ВНИМАНИЕ: это наиболее расслабленный SCC, и его следует использовать
только для администрирования кластера. Грант с осторожностью.
createTimestamp: нуль
имя: привилегированный
приоритет: ноль
readOnlyRootFilesystem: ложь
requiredDropCapabilities: [] (5)
runAsUser: (6)
тип: RunAsAny
seLinuxContext: (7)
тип: RunAsAny
seccompПрофили:
- '*'
дополнительныеГруппы: (8)
тип: RunAsAny
Пользователи: (9)
- система: serviceaccount: по умолчанию: реестр
- system: serviceaccount: по умолчанию: маршрутизатор
- система: serviceaccount: openshift-infra: build-controller
тома:
- '*'
1 | Список возможностей, которые могут быть запрошены модулем.Пустой список означает
что ни одна из возможностей не может быть запрошена, а специальный символ *
позволяет любые возможности. |
2 | Список дополнительных возможностей, которые будут добавлены к любому модулю. |
3 | Стратегия FSGroup , которая определяет допустимые значения для
Контекст безопасности. |
4 | Группы, имеющие доступ к этому SCC. |
5 | Список возможностей, которые будут удалены из модуля. |
6 | Тип стратегии «Запуск от имени пользователя», который определяет допустимые значения для Контекст безопасности. |
7 | Тип контекстной стратегии SELinux, определяющий допустимые значения для контекст безопасности. |
8 | Стратегия дополнительных групп, которая диктует допустимые дополнительные группы для контекста безопасности. |
9 | Пользователи, у которых есть доступ к этому SCC. |
пользователь
и группирует
поля в элементе управления SCC, которые можно использовать.
По умолчанию администраторам кластера, узлам и контроллеру сборки предоставляется
доступ к привилегированному SCC. Всем авторизованным пользователям предоставляется доступ к
ограниченный SCC.
Docker имеет
По умолчанию
список возможностей, которые разрешены для каждого контейнера модуля.В
контейнеры используют возможности из этого списка по умолчанию, но авторы манифеста модуля
может изменить его, запросив дополнительные возможности или отказавшись от некоторых из
невыполнение обязательств. allowedCapabilities
, defaultAddCapabilities
и
requiredDropCapabilities
поля используются для управления такими запросами от
pods, и чтобы указать, какие возможности могут быть запрошены, какие из них должны быть
добавлены в каждый контейнер, и какие из них должны быть запрещены.
-
допускает привилегированные поды.
-
позволяет монтировать каталоги хоста как тома.
-
позволяет модулю работать от имени любого пользователя.
-
позволяет модулю работать с любой меткой MCS.
-
позволяет модулю использовать пространство имен IPC хоста.
-
позволяет модулю использовать пространство имен PID хоста.
-
позволяет модулю использовать любую группу FSGroup.
-
позволяет модулю использовать любую дополнительную группу.
-
позволяет модулю использовать любые профили seccomp.
-
позволяет модулю запрашивать любые возможности.
-
гарантирует, что поды не могут работать с привилегиями.
-
гарантирует, что модули не могут использовать тома каталога хоста.
-
требует, чтобы модуль запускался от имени пользователя в заранее выделенном диапазоне UID.
-
требует, чтобы модуль работал с заранее выделенной меткой MCS.
-
позволяет модулю использовать любую группу FSGroup.
-
позволяет модулю использовать любую дополнительную группу.
Для получения дополнительной информации о каждом SCC см. kubernetes.io/description аннотация доступна на SCC. |
SCC состоят из настроек и стратегий, которые управляют функциями безопасности. модуль имеет доступ к. Эти настройки делятся на три категории:
Управляется логическим |
Поля этого типа по умолчанию имеют самое ограничивающее значение.Например,
|
Управляется допустимым набором |
Поля этого типа проверяются по набору, чтобы убедиться, что их значение разрешается. |
Контролируется стратегией |
Предметы, у которых есть стратегия создания ценности, обеспечивают:
|
Стратегии SCC
RunAsUser
-
MustRunAs — требуется настроить
runAsUser
. Использует настроенныйrunAsUser
по умолчанию. Проверяет настроенныйrunAsUser
. -
MustRunAsRange — Требует определения минимального и максимального значений, если нет с использованием заранее назначенных значений. По умолчанию используется минимум.Проверяет против весь допустимый диапазон.
-
MustRunAsNonRoot — требует, чтобы пакет был отправлен с ненулевым
runAsUser
или директивуUSER
, определенную в образе. По умолчанию нет при условии. -
RunAsAny — По умолчанию не предусмотрено. Позволяет указать любой
runAsUser
.
SELinuxContext
-
MustRunAs — Требуется
seLinuxOptions
для настройки, если не используется предварительно назначенные значения.По умолчанию используетсяseLinuxOptions
. Проверяет противseLinuxOptions
. -
RunAsAny — По умолчанию не предусмотрено. Позволяет любому
seLinuxOptions
быть указано.
Дополнительные группы
-
MustRunAs — Требуется указать хотя бы один диапазон, если не используется предварительно назначенные значения. По умолчанию используется минимальное значение первого диапазона. Проверяет по всем диапазонам.
-
RunAsAny — По умолчанию не предусмотрено. Позволяет любым
дополнительным группам
быть указано.
FSGroup
-
MustRunAs — Требуется указать хотя бы один диапазон, если не используется предварительно назначенные значения. По умолчанию используется минимальное значение первого диапазона. Проверяется по первому идентификатору в первом диапазоне.
-
RunAsAny — По умолчанию не предусмотрено. Позволяет указать любой идентификатор
fsGroup
.
Контрольные объемы
Использование определенных типов томов можно контролировать, задав тома
поле SCC. Допустимые значения этого поля соответствуют объему
источники, которые определены при создании тома:
Рекомендуемый минимальный набор разрешенных томов для новых SCC: configMap , вниз, API , emptyDir , persistentVolumeClaim , secret и прогнозируемый .
Список допустимых типов томов не является исчерпывающим, так как новые типы добавляется с каждым выпуском OpenShift Container Platform. |
Для обратной совместимости использование |
Ограничение доступа к FlexVolumes
OpenShift Container Platform обеспечивает дополнительный контроль FlexVolumes на основе их
Водитель. Когда SCC разрешает использование FlexVolumes, модули могут запрашивать любые
FlexVolumes. Однако, когда администратор кластера указывает имена драйверов в
поле AllowedFlexVolumes
, модули должны использовать FlexVolumes только с этими
драйверы.
Пример ограничения доступа только двумя FlexVolumes
томов:
- flexVolume
allowedFlexVolumes:
- драйвер: example / lvm
- драйвер: example / cifs
Seccomp
SeccompProfiles перечисляет разрешенные профили, которые могут быть установлены для модуля или модуля.
аннотации seccomp контейнера.Неустановленное (ноль) или пустое значение означает, что нет
профили указываются в пакете или контейнере. Используйте подстановочный знак *
, чтобы разрешить
все профили. Когда используется для генерации значения для модуля, первый не подстановочный знак
профиль используется по умолчанию.
Прием
Контроль доступа с SCC позволяет контролировать создание ресурсов на основе возможностей, предоставленных пользователю.
С точки зрения SCC это означает, что контроллер допуска может проверять информация о пользователе, доступная в контексте для получения соответствующего набора SCC.Это гарантирует, что модуль уполномочен делать запросы о своих операционной среде или для создания набора ограничений для применения к модулю.
Набор SCC, которые допуск использует для авторизации модуля, определяется идентификатор пользователя и группы, к которым принадлежит пользователь. Кроме того, если стручок указывает учетную запись службы, набор допустимых SCC включает любые ограничения доступный для учетной записи службы.
Admission использует следующий подход для создания окончательного контекста безопасности для капсула:
-
Получить все доступные для использования SCC.
-
Сгенерировать значения полей для параметров контекста безопасности, которые не были указаны по запросу.
-
Проверьте окончательные настройки на соответствие доступным ограничениям.
Если найден соответствующий набор ограничений, то пакет принимается. Если запрос не может быть сопоставлен с SCC, модуль отклонен.
Модуль должен проверять каждое поле на соответствие SCC. Ниже приведены примеры для только два поля, которые необходимо проверить:
Эти примеры относятся к стратегии, использующей предварительно выделенные значения. |
A FSGroup SCC Стратегия MustRunAs
Если модуль определяет идентификатор fsGroup
, то этот идентификатор должен быть равен значению по умолчанию.
fsGroup
Идентификатор. В противном случае пакет не будет подтвержден этим SCC и следующим SCC.
оценивается.
Если поле SecurityContextConstraints.fsGroup
имеет значение RunAsAny
а в спецификации модуля не указан Pod.spec.securityContext.fsGroup
,
то это поле считается действительным.Обратите внимание, что возможно, что во время
проверки, другие настройки SCC отклонят другие поля модуля и, таким образом, вызовут
стручок, чтобы выйти из строя.
A SupplementalGroups Стратегия SCC обязательного выполнения
Если спецификация модуля определяет один или несколько идентификаторов дополнительных групп
, то
идентификаторы модуля должны совпадать с одним из идентификаторов в пространстве имен
openshift.io/sa.scc.supplemental-groups аннотация. В противном случае капсула не
проверяется этим SCC, и оценивается следующий SCC.
Если поле SecurityContextConstraints.supplementalGroups
имеет значение RunAsAny
а в спецификации модуля опущен Pod.spec.securityContext.supplementalGroups
,
то это поле считается действительным. Обратите внимание, что возможно, что во время
проверки, другие настройки SCC отклонят другие поля модуля и, таким образом, вызовут
стручок, чтобы выйти из строя.
Приоритизация SCC
SCC имеют поле приоритета, которое влияет на порядок при попытке проверить запрос контроллера допуска.Более высокий приоритет При сортировке SCC перемещается в переднюю часть набора. Когда полный комплект из доступных SCC определены, они упорядочены по:
-
Сначала наивысший приоритет, nil считается приоритетом 0
-
Если приоритеты равны, SCC будут отсортированы от наиболее строгих к наименее строгим
-
Если и приоритеты, и ограничения равны, SCC будут отсортированы по имени
По умолчанию Anyuid SCC, предоставленный администраторам кластера, имеет приоритет.
в их наборе SCC.Это позволяет администраторам кластера запускать модули как любые
пользователь без указания RunAsUser
в SecurityContext
модуля. В
администратор может по-прежнему указать RunAsUser
, если желает.
Ролевой доступ к SCC
Начиная с OpenShift Container Platform 3.11, вы можете указать SCC как ресурс, который обрабатывается RBAC. Это позволяет вам ограничить доступ к вашим SCC до определенного проекту или всему кластеру. Назначение пользователей, групп или учетных записей служб напрямую в SCC, сохраняет область действия в масштабе всего кластера.
Чтобы включить доступ к SCC для вашей роли, вы указываете следующее правило в определение роли: .Ролевой доступ к SCC
правила:
- apiGroups:
- security.openshift.io (1)
Ресурсы:
- securitycontextconstraints (2)
глаголы:
- Создайте
- Удалить
- deletecollection
- получать
- список
- пластырь
- Обновить
- смотреть
resourceNames:
- myPermittingSCC (3)
1 | Группа API, которая включает ресурс securitycontextconstraints |
2 | Имя группы ресурсов, которая позволяет пользователям указывать имена SCC в
resourceNames поле |
3 | Пример имени SCC, к которому вы хотите предоставить доступ |
Локальная или кластерная роль с таким правилом позволяет субъектам, связанным с ней, с помощью привязка ролей или кластера привязка ролей для использования определяемого пользователем SCC, называемого myPermittingSCC .
Поскольку RBAC предназначен для предотвращения эскалации, даже администраторы проекта будут невозможно предоставить доступ к SCC, потому что они не разрешены по умолчанию, чтобы использовать команду , используйте для ресурсов SCC, включая с ограниченным доступом SCC. |
Общие сведения о предварительно назначенных значениях и ограничениях контекста безопасности
Контроллер доступа осведомлен об определенных условиях в контексте безопасности. ограничения, которые запускают поиск заранее выделенных значений из пространства имен и заполните ограничение контекста безопасности перед обработкой модуля.Каждый SCC стратегия оценивается независимо от других стратегий с заранее выделенными значения (где разрешено) для каждой политики, агрегированные со значениями спецификации модуля чтобы получить окончательные значения для различных идентификаторов, определенных в работающем модуле.
Следующие SCC заставляют контроллер доступа искать заранее выделенные значения, когда в спецификации модуля не определены диапазоны:
-
A
RunAsUser
стратегия MustRunAsRange без минимального или максимального набора.При приеме необходимо заполнить аннотацию openshift.io/sa.scc.uid-range . поля диапазона. -
Стратегия
SELinuxContext
для MustRunAs без установленного уровня. Допуск ищет аннотацию openshift.io/sa.scc.mcs для заполнения уровня. -
A
FSGroup
стратегия MustRunAs . Прием ищет openshift.io/sa.scc.supplemental-groups аннотация. -
A
SupplementalGroups
стратегия MustRunAs .Прием ищет openshift.io/sa.scc.supplemental-groups аннотация.
На этапе генерации провайдер контекста безопасности по умолчанию значения, которые специально не установлены в модуле. Значение по умолчанию основано на используемая стратегия:
-
RunAsAny
иMustRunAsNonRoot стратегии
не обеспечивают значение по умолчанию значения. Таким образом, если для модуля требуется определенное поле (например, идентификатор группы), этот Поле должно быть определено в спецификации модуля. -
MustRunAs
(одно значение) стратегии предоставляют значение по умолчанию, которое всегда использовал. Например, для идентификаторов групп: даже если спецификация модуля определяет его собственное значение идентификатора, поле пространства имен по умолчанию также появится в модуле группы. -
MustRunAsRange
иMustRunAs
(на основе диапазона) стратегии обеспечивают минимальное значение диапазона. Как и в случае стратегии с одним значениемMustRunAs
, значение по умолчанию для пространства имен появится в работающем модуле.Если на основе диапазона стратегия настраивается с несколькими диапазонами, она предоставит минимальное значение первого настроенного диапазона.
|
По умолчанию стратегия |
В аннотации openshift.io/sa.scc.supplemental-groups можно использовать запятую.
список блоков с разделителями в формате |
Использование авторизации RBAC | Kubernetes
Контроль доступа на основе ролей (RBAC) - это метод регулирования доступа к компьютеру или сетевые ресурсы на основе ролей отдельных пользователей в вашей организации.
авторизация RBAC использует rbac.authorization.k8s.io
Группа API для авторизации
решения, позволяющие динамически настраивать политики через Kubernetes API.
Чтобы включить RBAC, запустите сервер API
с флагом --authorization-mode
, установленным в список, разделенный запятыми, который включает RBAC
;
например:
kube-apiserver --authorization-mode = Пример, RBAC --other-options --more-options
Объекты API
RBAC API объявляет четыре типа объекта Kubernetes: Role , ClusterRole ,
RoleBinding и ClusterRoleBinding .Ты можешь
описывать объекты,
или исправьте их, используя такие инструменты, как kubectl,
, как и любой другой объект Kubernetes.
Роль и ClusterRole
Роль RBAC или ClusterRole содержит правила, представляющие набор разрешений. Разрешения чисто аддитивные (нет правил запрета).
Роль всегда устанавливает разрешения в определенном пространстве имен; при создании роли необходимо указать пространство имен, которому она принадлежит.
ClusterRole, напротив, не является ресурсом без пространства имен.Ресурсы имеют разные названия (Роль и ClusterRole), потому что объект Kubernetes всегда должен быть либо в пространстве имен, либо без него; не может быть и того, и другого.
ClusterRoles имеет несколько применений. Вы можете использовать ClusterRole для:
- определения разрешений на ресурсы с пространством имен и предоставления в пределах отдельных пространств имен
- определения разрешений на ресурсы с пространством имен и предоставления во всех пространствах имен
- определения разрешений на ресурсы с областью имен
вы хотите определить роль в пространстве имен, используйте Role; если вы хотите определить роль для всего кластера используйте ClusterRole.
Пример роли
Вот пример Роль в пространстве имен «по умолчанию», которую можно использовать для предоставления доступа на чтение к pods:
apiVersion: rbac.authorization.k8s.io/v1
kind: Роль
метаданные:
пространство имен: по умолчанию
имя: pod-reader
правила:
- apiGroups: [""] # "" указывает основную группу API
ресурсы: ["стручки"]
глаголы: ["получить", "посмотреть", "список"]
Пример ClusterRole
ClusterRole может использоваться для предоставления тех же разрешений, что и роль. Поскольку роли ClusterRoles относятся к кластеру, вы также можете использовать их для предоставления доступа к:
-
ресурсам в кластере (например, узлам)
-
конечным точкам без ресурсов (например,
/ healthz
) -
ресурсам с пространством имен (например, Pods), во всех пространствах имен
Например: вы можете использовать ClusterRole, чтобы разрешить конкретному пользователю запускать
kubectl get pods --all-namespaces
Вот пример ClusterRole, который можно использовать для предоставления доступа на чтение к секреты в любом конкретном пространстве имен, или во всех пространствах имен (в зависимости от того, как они связаны):
apiVersion: rbac.authorization.k8s.io/v1
вид: ClusterRole
метаданные:
# "namespace" опущено, поскольку ClusterRoles не имеет пространства имен
имя: секрет-читатель
правила:
- apiGroups: [""]
#
# на уровне HTTP имя ресурса для доступа к Secret
# объект "секреты"
ресурсы: ["секреты"]
глаголы: ["получить", "посмотреть", "список"]
Имя роли или объекта ClusterRole должно быть допустимым. имя сегмента пути.
RoleBinding и ClusterRoleBinding
Привязка роли предоставляет пользователю или группе пользователей разрешения, определенные в роли.Он содержит список из субъектов (пользователи, группы или учетные записи служб) и ссылку на роль предоставляется. RoleBinding предоставляет разрешения в определенном пространстве имен, тогда как ClusterRoleBinding предоставляет доступ к кластеру.
RoleBinding может ссылаться на любую роль в том же пространстве имен. В качестве альтернативы RoleBinding может ссылаться на ClusterRole и связывать эту ClusterRole с пространством имен RoleBinding. Если вы хотите привязать ClusterRole ко всем пространствам имен в вашем кластере, вы используете ClusterRoleBinding.
Имя объекта RoleBinding или ClusterRoleBinding должно быть допустимым. имя сегмента пути.
Примеры RoleBinding
Вот пример RoleBinding, который предоставляет роль «pod-reader» пользователю «jane». в пространстве имен "по умолчанию". Это позволяет «Джейн» читать модули в пространстве имен «по умолчанию».
apiVersion: rbac.authorization.k8s.io/v1
# Эта привязка роли позволяет "jane" читать модули в пространстве имен "default".
# У вас уже должна быть роль с именем "pod-reader" в этом пространстве имен.вид: RoleBinding
метаданные:
имя: стручки чтения
пространство имен: по умолчанию
предметы:
# Вы можете указать более одного "предмета"
- вид: Пользователь
name: jane # "name" чувствительно к регистру
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" указывает привязку к роли / роли кластера
kind: Role # это должна быть Role или ClusterRole
name: pod-reader # это должно совпадать с именем роли или ClusterRole, к которой вы хотите привязать
apiGroup: rbac.authorization.k8s.io
RoleBinding может также ссылаться на ClusterRole для предоставления разрешений, определенных в этом ClusterRole к ресурсам внутри пространства имен RoleBinding.Такая ссылка позволяет определить набор общих ролей в кластере, а затем повторно использовать их в несколько пространств имен.
Например, даже если следующее RoleBinding относится к ClusterRole, "dave" (субъект, чувствительный к регистру) сможет читать "Секреты" только в "development" пространство имен, потому что пространство имен RoleBinding (в его метаданных) - «разработка».
apiVersion: rbac.authorization.k8s.io/v1
# Эта привязка роли позволяет «dave» читать секреты в пространстве имен «development».# У вас уже должна быть ClusterRole с именем "secret-reader".
вид: RoleBinding
метаданные:
name: секреты чтения
#
# Пространство имен RoleBinding определяет, где предоставляются разрешения.
# Это дает разрешения только в пространстве имен "разработка".
пространство имен: разработка
предметы:
- вид: Пользователь
name: dave # Имя чувствительно к регистру
apiGroup: rbac.authorization.k8s.io
roleRef:
вид: ClusterRole
имя: секрет-читатель
apiGroup: rbac.authorization.k8s.io
Пример ClusterRoleBinding
Чтобы предоставить разрешения для всего кластера, вы можете использовать ClusterRoleBinding.Следующая ClusterRoleBinding позволяет любому пользователю в группе «менеджер» читать секреты в любом пространстве имен.
apiVersion: rbac.authorization.k8s.io/v1
# Эта привязка роли кластера позволяет любому члену группы «менеджер» читать секреты в любом пространстве имен.
вид: ClusterRoleBinding
метаданные:
имя: секреты чтения глобальный
предметы:
- вид: Группа
name: manager # Имя чувствительно к регистру
apiGroup: rbac.authorization.k8s.io
roleRef:
вид: ClusterRole
имя: секрет-читатель
apiGroup: rbac.authorization.k8s.io
После создания привязки нельзя изменить роль или роль кластера, на которую она ссылается.
Если вы попытаетесь изменить привязку roleRef
, вы получите ошибку проверки. Если ты хочешь
чтобы изменить роль roleRef
для привязки, необходимо удалить объект привязки и создать
замена.
Это ограничение вызвано двумя причинами:
- Создание неизменяемой
roleRef
позволяет предоставить кому-либо разрешение на обновление - Привязка к другой роли - это принципиально иная привязка.
Требование удаления / воссоздания привязки для изменения роли
Ссылка
гарантирует, что полный список предметов в привязке предназначен для предоставления новая роль (в отличие от включения или случайного изменения только roleRef без проверки всем существующим субъектам следует дать новую роль разрешения).
Утилита командной строки kubectl auth reconcile
создает или обновляет файл манифеста, содержащий объекты RBAC,
и обрабатывает удаление и воссоздание объектов привязки, если это необходимо для изменения роли, на которую они ссылаются.См. Использование команд и примеры для получения дополнительной информации.
Обращение к ресурсам
В Kubernetes API большинство ресурсов представлено и доступно с помощью строкового представления
имя их объекта, например pod
для Pod. RBAC относится к ресурсам, использующим точно такие же
имя, которое отображается в URL-адресе соответствующей конечной точки API.
Некоторые API Kubernetes включают
подресурс , например журналы для Pod. Запрос журналов модуля выглядит так:
GET / api / v1 / namespaces / {namespace} / pods / {name} / log.
В этом случае pod
- это ресурс с пространством имен для ресурсов Pod, а журнал
- это
подресурс pod
.Чтобы представить это в роли RBAC, используйте косую черту (/
) для
разграничить ресурс и подресурс. Разрешить субъекту читать под
и
также обращайтесь к подресурсу log
для каждого из этих модулей, вы пишете:
apiVersion: rbac.authorization.k8s.io/v1
kind: Роль
метаданные:
пространство имен: по умолчанию
имя: pod-and-pod-logs-reader
правила:
- apiGroups: [""]
ресурсы: ["блоки", "блоки / журнал"]
глаголы: ["получить", "список"]
Вы также можете ссылаться на ресурсы по имени для определенных запросов через список resourceNames
.Если указано, запросы могут быть ограничены отдельными экземплярами ресурса.
Вот пример, который ограничивает его предмет только получить
или обновить
a
ConfigMap с именем my-configmap
:
apiVersion: rbac.authorization.k8s.io/v1
kind: Роль
метаданные:
пространство имен: по умолчанию
имя: configmap-updater
правила:
- apiGroups: [""]
#
# на уровне HTTP имя ресурса для доступа к ConfigMap
# объект "configmaps"
ресурсы: ["configmaps"]
resourceNames: ["my-configmap"]
глаголы: ["обновить", "получить"]
Примечание: Вы не можете ограничить запросы
create
илиdeletecollection
по resourceName.Длясоздайте
, это ограничение связано с тем, что имя объекта неизвестно во время авторизации.
Агрегированные роли кластера
Можно агрегировать нескольких ролей кластера в одну объединенную роль кластера.
Контроллер, работающий как часть плоскости управления кластером, наблюдает за ClusterRole.
объекты с набором aggregationRule
. Правило агрегации
определяет метку.
селектор, что контроллер
используется для сопоставления с другими объектами ClusterRole, которые должны быть объединены в правила
поле этого.
Вот пример агрегированной роли ClusterRole:
apiVersion: rbac.authorization.k8s.io/v1
вид: ClusterRole
метаданные:
имя: мониторинг
aggregationRule:
clusterRoleSelectors:
- matchLabels:
rbac.example.com/aggregate-to-monitoring: "правда"
rules: [] # Уровень управления автоматически заполняет правила
Если вы создаете новую ClusterRole, которая соответствует селектору меток существующей агрегированной ClusterRole,
это изменение запускает добавление новых правил в агрегированную ClusterRole.Вот пример, который добавляет правила к «контролирующей» ClusterRole, создавая еще одну
ClusterRole с меткой rbac.example.com/aggregate-to-monitoring: true
.
apiVersion: rbac.authorization.k8s.io/v1
вид: ClusterRole
метаданные:
имя: конечные точки мониторинга
ярлыки:
rbac.example.com/aggregate-to-monitoring: "правда"
# При создании ClusterRole "конечных точек мониторинга",
# приведенные ниже правила будут добавлены в ClusterRole "мониторинг".
правила:
- apiGroups: [""]
ресурсы: ["службы", "конечные точки", "модули"]
глаголы: ["получить", "список", "смотреть"]
Пользовательские роли по умолчанию используют агрегацию ClusterRole.Это позволяет вам, как администратор кластера, включите правила для настраиваемых ресурсов, например, обслуживаемых CustomResourceDefinitions или агрегированные серверы API, чтобы расширить роли по умолчанию.
Например: следующие ClusterRoles позволяют ролям "admin" и "edit" по умолчанию управлять настраиваемым ресурсом.
с именем CronTab, тогда как роль «просмотра» может выполнять только действия чтения на ресурсах CronTab.
Вы можете предположить, что объекты CronTab названы "crontabs"
в URL-адресах, видимых сервером API.
apiVersion: rbac.authorization.k8s.io/v1
вид: ClusterRole
метаданные:
имя: агрегат-cron-вкладки-редактировать
ярлыки:
# Добавьте эти разрешения к ролям по умолчанию "admin" и "edit".
rbac.authorization.k8s.io/aggregate-to-admin: "правда"
rbac.authorization.k8s.io/aggregate-to-edit: "правда"
правила:
- apiGroups: ["stable.example.com"]
ресурсы: ["crontabs"]
глаголы: ["получить", "список", "смотреть", "создать", "обновить", "патч", "удалить"]
---
вид: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
метаданные:
имя: агрегат-cron-tabs-view
ярлыки:
# Добавьте эти разрешения к роли по умолчанию "просмотр".
rbac.authorization.k8s.io/aggregate-to-view: "правда"
правила:
- apiGroups: ["stable.example.com"]
ресурсы: ["crontabs"]
глаголы: ["получить", "список", "смотреть"]
Примеры ролей
Следующие ниже примеры представляют собой выдержки из объектов Role или ClusterRole, показывающие только
раздел правил
.
Разрешить чтение «подов»
ресурсов в ядре
Группа API:
правила:
- apiGroups: [""]
#
# на уровне HTTP имя ресурса для доступа к Pod
# объект "капсулы"
ресурсы: ["стручки"]
глаголы: ["получить", "список", "смотреть"]
Разрешить чтение / запись Развертывания (на уровне HTTP: объекты с «развертываниями»
в ресурсной части своего URL-адреса) в "расширениях"
и "приложениях"
группы API:
правила:
- apiGroups: ["расширения", "приложения"]
#
# на уровне HTTP имя ресурса для доступа к Deployment
# объект "развертывания"
ресурсы: ["развертывания"]
глаголы: ["получить", "список", "смотреть", "создать", "обновить", "патч", "удалить"]
Разрешить чтение модулей в основной группе API, а также чтение или запись задания
ресурсы в «партии»
или «расширениях»
Группы API:
правила:
- apiGroups: [""]
#
# на уровне HTTP имя ресурса для доступа к Pod
# объект "капсулы"
ресурсы: ["стручки"]
глаголы: ["получить", "список", "смотреть"]
- apiGroups: ["пакет", "расширения"]
#
# на уровне HTTP имя ресурса для доступа к Job
# объект "вакансии"
ресурсы: ["вакансии"]
глаголы: ["получить", "список", "смотреть", "создать", "обновить", "патч", "удалить"]
Разрешить чтение ConfigMap с именем "my-config" (должен быть связан с RoleBinding для ограничения одной ConfigMap в одном пространстве имен):
правила:
- apiGroups: [""]
#
# на уровне HTTP имя ресурса для доступа к ConfigMap
# объект "configmaps"
ресурсы: ["configmaps"]
resourceNames: ["my-config"]
глаголы: ["получить"]
Разрешить чтение ресурса «узлов»
в основной группе (поскольку
Узел имеет кластерную область видимости, он должен быть в ClusterRole, привязанном к
ClusterRoleBinding):
правила:
- apiGroups: [""]
#
# на уровне HTTP имя ресурса для доступа к Node
# объект - это «узлы»
ресурсы: ["узлы"]
глаголы: ["получить", "список", "смотреть"]
Разрешить запросы GET и POST к конечной точке без ресурсов / healthz
и
все подпути (должны быть в ClusterRole, привязанном к ClusterRoleBinding
для вступления в силу):
правила:
- nonResourceURLs: ["/ healthz", "/ healthz / *"] # '*' в nonResourceURL - это совпадение с суффиксом glob
глаголы: ["получить", "опубликовать"]
Обращение к субъектам
RoleBinding или ClusterRoleBinding связывает роль с субъектами.Субъектами могут быть группы, пользователи или ServiceAccounts.
Kubernetes представляет имена пользователей в виде строк. Это могут быть: простые имена, такие как «алиса»; имена в стиле электронной почты, например "[email protected]"; или числовые идентификаторы пользователей, представленные в виде строки. Это зависит от вас как администратора кластера для настройки модулей аутентификации так что аутентификация производит имена пользователей в желаемом формате.
Внимание: Префикс
system:
зарезервирован для использования системой Kubernetes, поэтому вы должны убедиться, что что у вас нет пользователей или групп с именами, начинающимися сsystem:
by несчастный случай.Кроме этого специального префикса, система авторизации RBAC не требует никакого формата для имен пользователей.
В Kubernetes модули Authenticator предоставляют информацию о группах.
Группы, как и пользователи, представлены в виде строк, и эта строка не имеет требований к формату.
кроме этого префикс system:
зарезервирован.
ServiceAccounts имеют имена с префиксом
с system: serviceaccount:
и принадлежат к группам, имена которых имеют префикс system: serviceaccounts:
.
Примечание:
system: serviceaccount:
(единственное число) - это префикс для имен пользователей сервисных учетных записей.система: serviceaccounts:
(множественное число) - это префикс для групп учетных записей служб.
Примеры RoleBinding
Следующие примеры представляют собой фрагменты RoleBinding
, которые только
показать предмет
раздел.
Для пользователя с именем [email protected]
:
тем:
- вид: Пользователь
name: "alice @ example.com "
apiGroup: rbac.authorization.k8s.io
Для группы с именем frontend-admins
:
субъектов:
- вид: Группа
имя: "фронтенд-админы"
apiGroup: rbac.authorization.k8s.io
Для учетной записи службы по умолчанию в пространстве имен «kube-system»:
субъектов:
- вид: ServiceAccount
имя: по умолчанию
пространство имен: kube-system
Для всех учетных записей служб в группе «qa» в любом пространстве имен:
субъектов:
- вид: Группа
имя: система: serviceaccounts: qa
apiGroup: rbac.authorization.k8s.io
Для всех учетных записей служб в группе «dev» в пространстве имен «разработка»:
субъектов:
- вид: Группа
имя: система: сервисаккаунты: разработчик
apiGroup: rbac.authorization.k8s.io
пространство имен: разработка
Для всех учетных записей служб в любом пространстве имен:
субъектов:
- вид: Группа
имя: система: serviceaccounts
apiGroup: rbac.authorization.k8s.io
Для всех авторизованных пользователей:
субъектов:
- вид: Группа
имя: система: аутентифицирован
apiGroup: rbac.authorization.k8s.io
Для всех пользователей, не прошедших аутентификацию:
субъектов:
- вид: Группа
имя: система: не аутентифицировано
apiGroup: rbac.authorization.k8s.io
Для всех пользователей:
тем:
- вид: Группа
имя: система: аутентифицирован
apiGroup: rbac.authorization.k8s.io
- вид: Группа
имя: система: не аутентифицировано
apiGroup: rbac.authorization.k8s.io
Роли по умолчанию и привязки ролей
Серверы API создают набор объектов ClusterRole и ClusterRoleBinding по умолчанию.Многие из них относятся к системе : с префиксом
, что указывает на то, что ресурс напрямую
управляется плоскостью управления кластером.
Все роли ClusterRoles и ClusterRoleBindings по умолчанию помечены как kubernetes.io/bootstrapping=rbac-defaults
.
Внимание: Будьте осторожны при изменении ClusterRoles и ClusterRoleBindings с именами которые имеют систему
: префикс
. Изменения в этих ресурсах могут привести к нефункциональным кластерам.
Автоматическое согласование
При каждом запуске сервер API обновляет роли кластера по умолчанию с любыми недостающими разрешениями, и обновляет привязки ролей кластера по умолчанию с любыми недостающими субъектами.Это позволяет кластеру исправлять случайные изменения и помогает сохранить роли и привязки ролей. актуальна по мере изменения разрешений и тем в новых выпусках Kubernetes.
Чтобы отказаться от этого согласования, установите rbac.authorization.kubernetes.io/autoupdate
аннотация роли кластера по умолчанию или привязка роли к false
.
Имейте в виду, что отсутствие разрешений и субъектов по умолчанию может привести к нефункциональным кластерам.
Автоматическое согласование включено по умолчанию, если активен авторизатор RBAC.
Роли обнаружения API
Привязки ролей по умолчанию разрешают неаутентифицированным и аутентифицированным пользователям читать информацию API, которая считается безопасной для публичного доступа (включая CustomResourceDefinitions). Чтобы отключить анонимный доступ без аутентификации, добавьте --anonymous-auth = false
в конфигурацию сервера API.
Чтобы просмотреть конфигурацию этих ролей через kubectl
, запустите:
kubectl get clusterroles system: discovery -o yaml
Примечание: Если вы измените эту роль ClusterRole, ваши изменения будут перезаписаны при перезапуске сервера API. через автоматическое согласование.Чтобы избежать перезаписи, либо не редактируйте роль вручную, либо отключите автосогласование.
ClusterRole по умолчанию | ClusterRoleBinding по умолчанию | Описание | |||||
---|---|---|---|---|---|---|---|
система: аутентифицированный | 6 | 3 | 3 903 доступ только для чтения к основной информации о себе. До v1.14, эта роль также была привязана к системе: по умолчанию не аутентифицирована. | ||||
система: обнаружение | система: аутентифицированная группа | Разрешает доступ только для чтения к конечным точкам обнаружения API, необходимым для обнаружения и согласования уровня API. До версии 1.14 эта роль также была привязана к системе: по умолчанию не аутентифицирована. | |||||
система: public-info-viewer | система: аутентифицирована и система: не аутентифицирована группы | Разрешает доступ только для чтения к несекретной информации о кластере.Представлено в Kubernetes v1.14. |
Роли, ориентированные на пользователя
Некоторые из ролей ClusterRoles по умолчанию не являются системными : с префиксом
. Это роли, ориентированные на пользователя.
Они включают роли суперпользователя ( администратор кластера
), роли, предназначенные для предоставления в масштабе всего кластера.
используя ClusterRoleBindings, и роли, предназначенные для предоставления в определенных
пространства имен с использованием RoleBindings ( admin
, edit
, view
).
Пользовательские роли ClusterRoles используют агрегацию ClusterRole, чтобы администраторы могли включать
правила для настраиваемых ресурсов в этих ClusterRoles.Чтобы добавить правила к admin
, edit
или view
ролям, создайте
ClusterRole с одной или несколькими из следующих меток:
метаданные:
ярлыки:
rbac.authorization.k8s.io/aggregate-to-admin: "правда"
rbac.authorization.k8s.io/aggregate-to-edit: "правда"
rbac.authorization.k8s.io/aggregate-to-view: "правда"
ClusterRole по умолчанию | ClusterRoleBinding по умолчанию | Описание | |
---|---|---|---|
cluster-admin | system: masters действие super- | 3 Разрешает доступ любой группе | 3 для любой группы ресурс.При использовании в ClusterRoleBinding он дает полный контроль над каждым ресурсом в кластере и во всех пространствах имен. При использовании в RoleBinding он дает полный контроль над каждым ресурсом в пространстве имен привязки ролей, включая само пространство имен. |
admin | Нет | Разрешает доступ администратора, предназначенный для предоставления в пространстве имен с помощью RoleBinding . Если используется в RoleBinding , разрешает доступ для чтения / записи к большинству ресурсов в пространстве имен, включая возможность создавать роли и привязки ролей в пространстве имен.Эта роль не разрешает доступ на запись к квоте ресурсов или к самому пространству имен. | |
редактировать | Нет | Разрешает доступ для чтения / записи к большинству объектов в пространстве имен. Эта роль не позволяет просматривать или изменять роли или привязки ролей. Однако эта роль позволяет получать доступ к секретам и запускать модули от имени любого ServiceAccount в пространство имен, поэтому его можно использовать для получения уровней доступа API любого ServiceAccount в пространство имен. | |
вид | Нет | Разрешает доступ только для чтения для просмотра большинства объектов в пространстве имен.Он не позволяет просматривать роли или привязки ролей. Эта роль не позволяет просматривать Секреты, так как чтение содержимое секретов обеспечивает доступ к учетным данным ServiceAccount в пространстве имен, что позволит получить доступ к API как любой ServiceAccount в пространстве имен (форма повышения привилегий). |
Роли основных компонентов
ClusterRole по умолчанию | ClusterRoleBinding по умолчанию | Описание | |
---|---|---|---|
система пользователя: kube- | система планировщика: kube- | Разрешает доступ к ресурсам, необходимым для компонента планировщика. | |
system: volume-scheduler | system: kube-scheduler user | Разрешает доступ к ресурсам тома, необходимым для компонента kube-scheduler. | |
system: kube-controller-manager | system: kube-controller-manager user | Разрешает доступ к ресурсам, необходимым для компонента диспетчера контроллеров. Разрешения, необходимые для отдельных контроллеров, подробно описаны в ролях контроллера. | |
система: узел | Нет | Разрешает доступ к ресурсам, необходимым для кублета, , включая доступ для чтения ко всем секретам и доступ для записи ко всем объектам статуса модуля . Вы должны использовать авторизатор узлов и подключаемый модуль допуска NodeRestriction вместо роли system: node и разрешить предоставление доступа API к кубелетам на основе запланированных на них подов. Роль система: узел существует только для совместимости с кластерами Kubernetes, обновленными с версий до v1.8. | |
system: node-proxier | system: kube-proxy user | Разрешает доступ к ресурсам, необходимым для компонента kube-proxy. |
Другие роли компонентов
ClusterRole по умолчанию | ClusterRoleBinding по умолчанию | Описание | |||
---|---|---|---|---|---|
аутентификация делегат проверяет | делегат | авторизация | делегирует | Это обычно используется дополнительными серверами API для унифицированной аутентификации и авторизации. | |
система: heapster | Нет | Роль для компонента Heapster (не рекомендуется). | |||
система: kube-aggregator | Нет | Роль для компонента kube-aggregator. | |||
system: kube-dns | kube-dns служебная учетная запись в пространстве имен kube-system | Роль для компонента kube-dns. | |||
система: kubelet-api-admin | Нет | Разрешает полный доступ к API kubelet. | |||
система: узел-загрузчик | Нет | Разрешает доступ к ресурсам, необходимым для выполнения kubelet самозагрузка TLS. | |||
система: детектор проблем узлов | Нет | Роль для компонента детектора проблем узлов. | |||
system: persistent-volume-provisioner | Нет | Разрешает доступ к ресурсам, необходимым большинству динамических инициализаторов томов. | |||
система: мониторинг | система: мониторинг группа | Разрешает доступ для чтения к конечным точкам мониторинга уровня управления (т.е. конечным точкам активности и готовности kube-apiserver (/ healthz, / livez, / readyz), индивидуальным конечные точки проверки работоспособности (/ healthz / *, / livez / *, / readyz / *) и / metrics). Обратите внимание, что отдельные конечные точки проверки работоспособности и конечная точка метрики могут предоставлять конфиденциальную информацию. |
Роли для встроенных контроллеров
Запускается диспетчер контроллеров Kubernetes
контроллеры, встроенные в Kubernetes
Плоскость управления.При вызове с --use-service-account-credentials
kube-controller-manager запускает каждый контроллер
используя отдельную учетную запись службы.
Для каждого встроенного контроллера существуют соответствующие роли с префиксом system: controller:
.
Если диспетчер контроллеров не запущен с --use-service-account-credentials
, он запускает все контуры управления.
используя свои собственные учетные данные, которым должны быть предоставлены все соответствующие роли.
Эти роли включают:
-
system: controller: attachdetach-controller
-
system: controller: certificate-controller
-
system: controller: clusterrole-aggregation-controller
-
system: controller: cronjob-controller
-
system: controller: daemon-set-controller
-
system: controller: deployment-controller
-
system: controller: disruption-controller
-
система: контроллер: конечный контроллер
-
system: controller: expand-controller
-
system: controller: generic-garbage-collector
-
system: controller: horizontal-pod-autoscaler
-
system: controller: job-controller
-
система: controller: namespace-controller
-
system: controller: node-controller
-
система: contro ller: persistent-volume-binder
-
система: контроллер: сборщик мусора pod
-
система: контроллер: pv-protection-controller
-
система: контроллер: pvc-protection-controller
-
система: контроллер: replicaset-controller
-
система: контроллер: контроллер репликации
-
система: контроллер: resourcequota-controller
-
система: контроллер: root-ca-cert-publisher
-
система: controller: route-controller
-
system: controller: service-account-controller
-
system: controller: service-controller
-
system: controller: statefulset-controller
-
система: контроллер: ttl- контроллер
Предотвращение повышения привилегий и начальная загрузка
API RBAC не позволяет пользователям повышать привилегии путем редактирования ролей o r привязки ролей.Поскольку это применяется на уровне API, оно применяется даже тогда, когда авторизатор RBAC не используется.
Ограничения на создание или обновление роли
Вы можете создать / обновить роль, только если верно хотя бы одно из следующих условий:
- У вас уже есть все разрешения, содержащиеся в роли, в той же области, что и объект модифицируется (на уровне кластера для ClusterRole, в том же пространстве имен или на уровне кластера для роли).
- Вам предоставлено явное разрешение на выполнение глагола
эскалации
дляролей
илиресурса clusterroles
вrbac.authorization.k8s.io
Группа API.
Например, если user-1
не имеет возможности перечислить секреты для всего кластера, они не могут создать ClusterRole
содержащее это разрешение. Чтобы разрешить пользователю создавать / обновлять роли:
- Предоставьте ему роль, которая позволяет им создавать / обновлять объекты Role или ClusterRole по желанию.
- Предоставьте им разрешение на включение определенных разрешений в роли, которые они создают / обновляют:
- неявно, предоставляя им эти разрешения (если они попытаются создать или изменить роль или ClusterRole с разрешениями, которые им самим не предоставлены, запрос API будет запрещено)
- или явно разрешить указание любого разрешения в роли
ClusterRole
, дав им разрешение на выполнение командыэскалации
дляролей
илиclusterroles
ресурсов вrbac.authorization.k8s.io
Группа API
Ограничения на создание или обновление привязки ролей
Вы можете создать / обновить привязку роли, только если у вас уже есть все разрешения, содержащиеся в указанной роли
(в той же области, что и привязка роли) или , если вы авторизованы для выполнения команды привязки
для указанной роли.
Например, если пользователь-1
не имеет возможности перечислить секреты для всего кластера, они не могут создать привязку ClusterRoleBinding.
роли, предоставляющей это разрешение.Чтобы разрешить пользователю создавать / обновлять привязки ролей:
- Предоставьте им роль, которая позволяет им создавать / обновлять объекты RoleBinding или ClusterRoleBinding по желанию.
- Предоставьте им разрешения, необходимые для привязки определенной роли:
- неявно, предоставив им разрешения, содержащиеся в роли.
- явно, дав им разрешение на выполнение глагола
привязки
для конкретной роли (или ClusterRole).
Например, эта ClusterRole и RoleBinding позволят user-1
предоставлять другим пользователям права admin
, edit
и просматривать
ролей в пространстве имен user-1-namespace
:
apiVersion: rbac.authorization.k8s.io/v1
вид: ClusterRole
метаданные:
имя: роль-праводатель
правила:
- apiGroups: ["rbac.authorization.k8s.io"]
ресурсы: ["ролевые привязки"]
глаголы: ["создать"]
- apiGroups: ["rbac.authorization.k8s.io"]
ресурсы: ["clusterroles"]
глаголы: ["связывать"]
# опустить resourceNames, чтобы разрешить привязку любой ClusterRole
resourceNames: ["админ", "редактировать", "просмотр"]
---
apiVersion: rbac.authorization.k8s.io/v1
вид: RoleBinding
метаданные:
имя: привязка лица, предоставившего роль
пространство имен: user-1-namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
вид: ClusterRole
имя: роль-праводатель
предметы:
- apiGroup: rbac.authorization.k8s.io
вид: Пользователь
имя: пользователь-1
При загрузке первых ролей и привязок ролей необходимо, чтобы начальный пользователь предоставил разрешения, которых у него еще нет. Для начальной загрузки ролей и привязок ролей:
- Используйте учетные данные с группой «system: masters», которая привязана к роли суперпользователя «cluster-admin» привязками по умолчанию.
- Если ваш сервер API работает с включенным небезопасным портом (
--insecure-port
), вы также можете выполнять вызовы API через этот порт, который не требует проверки подлинности или авторизации.
Утилиты командной строки
kubectl create role
Создает объект Role, определяющий разрешения в пределах единого пространства имен. Примеры:
-
Создайте роль с именем «pod-reader», которая позволяет пользователям выполнять
get
,смотреть
исписок
на подах:kubectl create role pod-reader --verb = get - глагол = список --verb = смотреть --resource = pods
-
Создайте роль с именем «pod-reader» с указанными resourceNames:
kubectl create role pod-reader --verb = get --resource = pods --resource-name = readablepod --resource-name = другая капсула
-
Создайте роль с именем «foo» с указанными apiGroups:
kubectl create role foo --verb = get, list, watch --resource = replicasets.Программы
-
Создайте роль с именем «foo» с разрешениями на подресурсы:
kubectl create role foo --verb = get, list, watch --resource = pods, pods / status
-
Создайте роль с именем «my-component-lease-holder» с разрешениями на получение / обновление ресурса с определенным именем:
kubectl create role my-component-lease-holder --verb = get, список, смотреть, обновить --resource = lease --resource-name = my-component
kubectl create clusterrole
Создает ClusterRole.Примеры:
-
Создайте ClusterRole с именем «pod-reader», которая позволяет пользователю выполнять
get
,смотреть
иlist
на подах:kubectl create clusterrole pod-reader --verb = get, list , смотрите --resource = pods
-
Создайте ClusterRole с именем «pod-reader» с указанными resourceNames:
kubectl create clusterrole pod-reader --verb = get --resource = pods --resource-name = readablepod --resource-name = другая капсула
-
Создайте ClusterRole с именем «foo» с указанными apiGroups:
kubectl create clusterrole foo --verb = get, list, watch --resource = replicasets.Программы
-
Создайте ClusterRole с именем «foo» с разрешениями на подресурсы:
kubectl create clusterrole foo --verb = get, list, watch --resource = pods, pods / status
-
Создайте ClusterRole с именем «foo» с указанным nonResourceURL:
kubectl create clusterrole «foo» --verb = get --non-resource-url = / logs / *
-
Создайте ClusterRole с именем «мониторинг» с указанным правилом агрегации:
kubectl create clusterrole monitoring --aggregation-rule = "rbac.example.com/aggregate-to-monitoring=true "
kubectl create rolebinding
Предоставляет роль или ClusterRole в определенном пространстве имен. Примеры:
-
В пространстве имен «acme» предоставьте разрешения в ClusterRole «admin» пользователю с именем «bob»:
kubectl create rolebinding bob-admin-binding --clusterrole = admin --user = bob --namespace = acme
-
В пространстве имен «acme» предоставьте разрешения в «представлении» ClusterRole учетной записи службы в пространстве имен «acme» с именем «myapp»:
kubectl create rolebinding myapp-view-binding --clusterrole = просмотр --serviceaccount = acme: myapp --namespace = acme
-
В пространстве имен «acme» предоставьте разрешения в «представлении» ClusterRole учетной записи службы в пространстве имен «myappnamespace» с именем «myapp»:
kubectl create rolebinding myappnamespace-myapp-view-binding - -clusterrole = просмотр --serviceaccount = myappnamespace: myapp --namespace = acme
kubectl create clusterrolebinding
Предоставляет роль ClusterRole для всего кластера (всех пространств имен).Примеры:
-
Для всего кластера предоставить разрешения в ClusterRole «cluster-admin» пользователю с именем «root»:
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole = cluster-admin --user = корень
-
Во всем кластере предоставьте разрешения в «system: node-proxier» ClusterRole пользователю с именем «system: kube-proxy»:
kubectl create clusterrolebinding kube-proxy-binding --clusterrole = система: node-proxier --user = system: kube-proxy
-
Во всем кластере предоставьте разрешения в «представлении» ClusterRole учетной записи службы с именем «myapp» в пространстве имен «acme»:
kubectl create clusterrolebinding myapp-view-binding --clusterrole = view --serviceaccount = acme: myapp
kubectl auth согласовать
Создает или обновляет rbac.authorization.k8s.io/v1
Объекты API из файла манифеста.
Создаются отсутствующие объекты, и при необходимости создается содержащее пространство имен для объектов с пространством имен.
Существующие роли обновлены, чтобы включить разрешения во входных объектах,
и удалите лишние разрешения, если указано --remove-extra-permissions
.
Существующие привязки обновляются для включения субъектов во входные объекты,
и удалите лишние предметы, если указано --remove-extra-subject
.
Примеры:
-
Тестирование применения файла манифеста объектов RBAC, отображение изменений, которые будут внесены:
kubectl auth reconcile -f my-rbac-rules.yaml --dry-run = client
-
Примените файл манифеста объектов RBAC с сохранением любых дополнительных разрешений (в ролях) и любых дополнительных субъектов (в привязках):
kubectl auth reconcile -f my-rbac-rules.yaml
-
Примените файл манифеста объектов RBAC, удалив все дополнительные разрешения (в ролях) и любые дополнительные субъекты (в привязках):
kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-темы --remove-extra-permissions
Разрешения ServiceAccount
Политики RBAC по умолчанию предоставляют разрешения с заданной областью для компонентов, узлов уровня управления, и контроллеры, но не предоставлять разрешений для сервисных учетных записей вне пространства имен kube-system (помимо разрешений на обнаружение, предоставленных всем аутентифицированным пользователям).
Это позволяет вам при необходимости назначать определенные роли определенным ServiceAccounts. Детализированные привязки ролей обеспечивают большую безопасность, но требуют больше усилий для администрирования.Более широкие гранты могут предоставить ненужный (и потенциально расширяющийся) доступ API к ServiceAccounts, но их легче администрировать.
В порядке от наиболее безопасного к наименее защищенному подходы следующие:
-
Предоставить роль учетной записи службы для конкретного приложения (передовой опыт)
Это требует, чтобы приложение указывало
serviceAccountName
в своей спецификации модуля, и для создаваемой учетной записи службы (через API, манифест приложения,kubectl create serviceaccount
и т. д.).Например, разрешить только чтение в my-namespace учетной записи службы my-sa:
kubectl create rolebinding my-sa-view \ --clusterrole = просмотр \ --serviceaccount = мое-пространство имен: мое-са \ --namespace = мое-пространство имен
-
Предоставить роль учетной записи службы «по умолчанию» в пространстве имен
Если приложение не указывает
serviceAccountName
, оно использует учетную запись службы «по умолчанию».Примечание: Разрешения, предоставленные учетной записи службы «по умолчанию», доступны для любого модуля. в пространстве имен, которое не указывает
serviceAccountName
.Например, предоставить доступ только для чтения в «my-namespace» учетной записи службы «по умолчанию»:
kubectl create rolebinding default-view \ --clusterrole = просмотр \ --serviceaccount = мое-пространство имен: по умолчанию \ --namespace = мое-пространство имен
Многие надстройки работают как Учетная запись службы «default» в пространстве имен
kube-system
. Чтобы эти надстройки запускались с правами суперпользователя, предоставьте cluster-admin разрешения для учетной записи службы «по умолчанию» в пространстве именkube-system
.Внимание: Включение этого параметра означает, что пространство имен
kube-system
содержит секреты которые предоставляют суперпользовательский доступ к API вашего кластера.kubectl create clusterrolebinding add-on-cluster-admin \ --clusterrole = администратор кластера \ --serviceaccount = kube-system: по умолчанию
-
Предоставить роль всем учетным записям служб в пространстве имен
Если вы хотите, чтобы все приложения в пространстве имен имели роль, независимо от того, какую учетную запись службы они используют, вы можете предоставить роль группе учетных записей службы для этого пространства имен.
Например, предоставить разрешение только на чтение в «my-namespace» всем учетным записям служб в этом пространстве имен:
kubectl create rolebinding serviceaccounts-view \ --clusterrole = просмотр \ --group = system: serviceaccounts: my-namespace \ --namespace = мое-пространство имен
-
Предоставить ограниченную роль всем учетным записям служб в масштабе кластера (не рекомендуется)
Если вы не хотите управлять разрешениями для каждого пространства имен, вы можете предоставить роль в масштабе кластера всем учетным записям служб.
Например, предоставить разрешение только на чтение для всех пространств имен всем учетным записям служб в кластере:
kubectl create clusterrolebinding serviceaccounts-view \ --clusterrole = просмотр \ --group = system: serviceaccounts
-
Предоставить суперпользователю доступ ко всем сервисным учетным записям в масштабе кластера (настоятельно не рекомендуется)
Если вас вообще не интересуют разрешения на разделение, вы можете предоставить суперпользовательский доступ ко всем сервисным учетным записям.
Предупреждение: Это разрешает любому приложению полный доступ к вашему кластеру, а также предоставляет любой пользователь с доступом для чтения к Секретам (или возможностью создавать любые модули) полный доступ к вашему кластеру.
kubectl create clusterrolebinding serviceaccounts-cluster-admin \ --clusterrole = администратор кластера \ --group = system: serviceaccounts
Обновление с ABAC
Часто используются кластеры, на которых изначально были запущены более старые версии Kubernetes разрешительные политики ABAC, включая предоставление полного доступа к API для всех сервисные аккаунты.
Политики RBAC по умолчанию предоставляют разрешения с определенной областью действия компонентам, узлам уровня управления, и контроллеры, но не предоставлять разрешений для сервисных учетных записей вне пространства имен kube-system (помимо разрешений на обнаружение, предоставленных всем аутентифицированным пользователям).
Хотя это намного безопаснее, это может нарушить работу существующих рабочих нагрузок, которые ожидают автоматического получения разрешений API. Вот два подхода к управлению этим переходом:
Параллельные авторизаторы
Запустите авторизаторы RBAC и ABAC и укажите файл политики, содержащий устаревшая политика ABAC:
--authorization-mode = ..., RBAC, ABAC --authorization-policy-file = mypolicy.json
Чтобы подробно объяснить этот первый параметр командной строки: если более ранние авторизаторы, такие как Node, отклонить запрос, то авторизатор RBAC пытается авторизовать запрос API.Если RBAC также отклоняет этот запрос API, затем запускается авторизатор ABAC. Это означает, что любой запрос разрешено или разрешены политики RBAC или ABAC.
Когда kube-apiserver запущен с уровнем журнала 5 или выше для компонента RBAC
( --vmodule = rbac * = 5
или --v = 5
), вы можете увидеть отказы RBAC в журнале сервера API
(с префиксом RBAC
).
Вы можете использовать эту информацию, чтобы определить, какие роли должны быть предоставлены каким пользователям, группам или учетным записям служб.
После назначения ролей сервисным учетным записям и рабочим нагрузкам работают без сообщений об отказе RBAC в журналах сервера, вы можете удалить авторизатор ABAC.
Разрешающие разрешения RBAC
Вы можете реплицировать разрешающую политику ABAC, используя привязки ролей RBAC.
Предупреждение:Следующая политика позволяет ВСЕМ учетным записям служб действовать в качестве администраторов кластера. Любое приложение, работающее в контейнере, автоматически получает учетные данные учетной записи службы, и может выполнять любые действия с API, включая просмотр секретов и изменение разрешений.Это не рекомендуемая политика.
kubectl create clusterrolebinding permissive-binding \ --clusterrole = администратор кластера \ --user = admin \ --user = кубелет \ --group = system: serviceaccounts
После перехода на использование RBAC необходимо настроить элементы управления доступом.