Список ролей полномочий: Как понять каких полномочий не хватает пользователю?

Содержание

Как понять каких полномочий не хватает пользователю?

В системе действует принцип «что не разрешено, то запрещено». То есть изначально пользователю не разрешено ничего, кроме входа (логина) в систему.

Минимальный набор операций для того или иного бизнес-процесса выделяется в роль, которая имеет описание и меню, в котором могут быть транзакции, отчеты или внешние ссылки. Для каждой роли генерируется профиль полномочий, который содержит набор полномочий (или разрешений) минимально достаточных для выполнения набора операций, для которого созадана роль (рис. 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.

Анализ полномочий, транзакция SU53, показал отсутствие уже совсем другого объекта полномочий (рис. 6). Кстати, если проверять полномочия из запущенной транзакции, то стоит вбивать «/nSU53«. Об этом я писал тут.

Рис. 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.

Стоит отметить, что все полномочия в 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

Вернуться в пресс-центр

Типы пользователей, роли и права доступа—Portal for ArcGIS

Участники

Просмотр

Это право доступа позволяет просматривать участников организации. Если отмечено, права доступа Просмотр позволяют участникам просматривать вкладку Участники на странице Организация. Если не отмечено, участники не могут видеть страницу Организация.

Группы

Создание, обновление и удаление

Это право доступа позволяет участникам создавать группы на портале и управлять ими.

Присоединение к группам организации

Участники ролей, которым предоставлено это право, могут направлять запрос на присоединение к группам в организации. Это право доступа полезно только в том случае, если вы также предоставляете роль право просмотра групп, доступных на портале. Если у роли нет этого права, участники не будут видеть группы и, следовательно, не смогут направлять запрос на присоединение к ним.

Просмотреть группы, доступные на портале

Это право доступа позволяет участникам обнаруживать группы, настроенные таким образом, чтобы участники портала могли их просматривать.

Ресурсы

Создание, обновление и удаление

Это право доступа позволяет участникам создавать элементы на портале и управлять ими. Это право доступа необходимо, если вы предоставляете какие-либо права, позволяющие участникам публиковать, регистрировать хранилища данных или создавать Блокноты.

Публикация размещённых векторных слоёв

Это право доступа позволяет участникам публиковать размещенные векторные слои на портале как из самого портала, так и из других приложений, например 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, используя расширенные рабочие среды.

Пространственные объекты

Редактирование

Это право доступа позволяет редактировать объекты в зависимости от разрешений, настроенных для слоя.

Редактирование с полным доступом

Редактирование с полным доступом: добавление, удаление и обновление объектов и атрибутов в редактируемых размещенных векторных слоях, даже если операции редактирования в слоях ограничены.

Управление версиями

Управлять всеми (новое в версии 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 Свойство ³ используется для подключения каждой роли к ее прямым подролям, а canHaveRole +: Identity → Role Свойство используется для представления ролей, которые каждый идентификатор (пользователь) может активировать, прямо или косвенно, благодаря наличию положительных авторизаций ролей.Таким образом, roleHierarchy ( r ₁, r ₂) означает, что роль r ₁ является надролью r ₂. Его транзитивное закрытие canBe +: Роль → Роль может использоваться для идентификации всех прямых или косвенных подроли. Отношение подроли (а также ее обратной суперроли) не является сдерживающим фактором и не определяет таксономию идентичностей (суперроль роли R должна быть более привилегированной, чем R, и доступна для более ограниченного набора идентичностей).

С помощью этих инструментов можно, например, предложить немедленное управление ограничениями SoD. Отношение назначения ролей пользователя представлено с помощью полномочий ролей, которые специализируют авторизации с указанием роли, которую принципалу разрешено или запрещено принимать. Ограничение SoD между ролью r ₁ и r ₂ затем может быть выражено с помощью отрицательной авторизации роли r _auth , которая запрещает роли r ₁ вводить в действие роль r ₂.Ограничения SoD применяются как на уровне иерархии ролей (таким образом, мы напрямую предотвращаем объявление роли r ₁ над ролями другой роли r ₂, так что r ₁ и r ₂ находятся в ограничении SoD) и на уровне иерархии пользователей (чтобы две роли r ₁ и r ₂ не были прямо или косвенно назначены пользователю, который участвует в Ограничение 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 ₁ и к r ₂. Таким образом, мы можем обеспечить соблюдение 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 ₁ и a ₂) или Объектно-ориентированный SoD (который требует, чтобы ни один пользователь не имел доступа к Ресурсам res ₁ и res ₂). Однако системы 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 определяют объем полномочий для предоставления пользователям (например, для изменения или отображения данных о персонале) в соответствии с бизнес-роль, назначенная пользователю, как описано в следующей таблице.

Бизнес-роль	Объем авторизации
Сотрудник	Изменение или отображение только собственных данных .
Офисный помощник	Ведение данных прогноза для определенной группы сотрудников с прямым или косвенным подчинением менеджеру.
Менеджер проекта, менеджер по консультированию, менеджер по доставке	Ведение как собственных данных прогноза, так и данных прогноза конкретной группы сотрудников с использованием прямых или косвенных линий отчетности.
Суперпользователь	Ведение данных прогноза для всех сотрудников.

Имена таблиц безопасности SAP

Таблица USR * содержит основную информацию о пользователе. Таблицы
AGR * содержат данные о ролях. Таблица
USH * содержит информацию о документах изменений.

Таблица значений Структура диалогового окна

Стол	Описание
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 состоят из настроек и стратегий, которые управляют функциями безопасности. модуль имеет доступ к. Эти настройки делятся на три категории:
Управляется логическим
Поля этого типа по умолчанию имеют самое ограничивающее значение.Например, AllowPrivilegedContainer всегда имеет значение false , если не указано.
Управляется допустимым набором
Поля этого типа проверяются по набору, чтобы убедиться, что их значение разрешается.
Контролируется стратегией
Предметы, у которых есть стратегия создания ценности, обеспечивают:
Механизм генерации стоимости и
Механизм, гарантирующий, что указанное значение попадает в набор допустимых значения.
Стратегии 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.

Для обратной совместимости использование allowHostDirVolumePlugin переопределяет настройки в томах поле . Например, если allowHostDirVolumePlugin установлено значение false, но разрешено в поле тома , затем hostPath значение будет удалено из тома .
Ограничение доступа к 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 , значение по умолчанию для пространства имен появится в работающем модуле.Если на основе диапазона стратегия настраивается с несколькими диапазонами, она предоставит минимальное значение первого настроенного диапазона.

FSGroup и SupplementalGroups стратегии возвращаются к openshift.io/sa.scc.uid-range аннотация, если openshift.io/sa.scc.supplemental-groups аннотации не существует на пространство имен. Если ни один из них не существует, SCC не сможет создать.

По умолчанию стратегия FSGroup на основе аннотаций конфигурируется с единый диапазон, основанный на минимальном значении аннотации. Например, если ваш аннотация читает 1/3 , стратегия FSGroup сконфигурируется с минимум и максимум 1 . Если вы хотите разрешить принятие большего количества групп для поле FSGroup , вы можете настроить настраиваемый SCC, который не использует аннотация.

В аннотации openshift.io/sa.scc.supplemental-groups можно использовать запятую. список блоков с разделителями в формате <начало> / <длина или <начало> - <конец> . Аннотация openshift.io/sa.scc.uid-range принимает только один блок.
Использование авторизации 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. через автоматическое согласование.Чтобы избежать перезаписи, либо не редактируйте роль вручную, либо отключите автосогласование.
Роли обнаружения Kubernetes RBAC 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 необходимо настроить элементы управления доступом.