В этой записи блога я рассмотрю основы настройки управления доступом на основе ролей (RBAC) в EAP и Wildfly.
RBAC был представлен в EAP 6.2 и WildFly 8, поэтому вам понадобится любой из них, если вы хотите использовать RBAC.
Для целей этого блога я буду использовать следующее:
ОС — Ubuntu 14
Java — 1.7.0_67
JBoss — EAP 6.3
Хотя я использую EAP, эти инструкции должны работать точно так же на Wildfly.
Что такое RBAC?
Управление доступом на основе ролей предназначено для ограничения доступа к системе путем указания разрешений для пользователей управления. Каждому пользователю с правами управления предоставляется роль, и эта роль определяет, что он может и не может получить к нему доступ.
В EAP 6.2+ и Wildfly 8+ есть семь предопределенных ролей, каждая из которых имеет разные разрешения. Подробности о каждой из ролей можно найти здесь:
Для аутентификации пользователей должен использоваться один из трех стандартных провайдеров аутентификации. Это:
Локальный пользователь. Локальный пользователь автоматически добавляется в качестве суперпользователя, поэтому у пользователя на сервере есть полный доступ. Этот пользователь должен быть удален в производственной системе и доступ должен быть закрыт для именованных пользователей.
Имя пользователя / пароль — используя файл mgmt-users.properties или сервер LDAP.
Сертификат клиента — использование доверенного хранилища
Для целей этого блога и для простоты мы будем использовать имя пользователя / пароли и файл mgmt-users.properties
Зачем нам нужен RBAC?
Самый простой способ показать это — практическая демонстрация.
Конфигурирование может быть выполнено либо через консоль управления, либо через интерфейс командной строки (CLI). Однако через консоль управления можно выполнить только ограниченный набор задач, тогда как все задачи доступны через CLI. Поэтому для целей этого блога я буду делать все настройки через CLI.
В нашем тестовом сценарии у нас есть 4 пользователя:
Энди — этот пользователь является главным системным администратором, и поэтому мы хотим, чтобы он мог получить доступ ко всему.
Боб — этот пользователь является ведущим разработчиком и поэтому должен иметь возможность развертывать приложения и вносить изменения в определенные ресурсы приложения.
Клэр и Дэйв — эти пользователи являются стандартными разработчиками и должны иметь возможность просматривать ресурсы приложения, но не должны иметь возможность вносить изменения.
Прежде всего, мы настроим ряд пользователей.
Для этого мы будем использовать скрипт add-user.sh, который можно найти в:
<JBOSS_INSTALL_DIR>/bin
Создайте следующих пользователей в указанных группах. (Введите Нет для окончательного вопроса для всех пользователей)
Энди — нет группы
Боб — ведущий разработчик
Клэр — разработчики стандартов
Дейв — разработчики стандартов
В <JBOSS_INSTALL_DIR> / domain / configuration вы найдете файл с именем mgmt-users.properties.
Внизу этого файла вы увидите список созданных нами пользователей, подобный этому:
Andy = 82153e0297590cceb14e7620ccd3b6ed
Боб = 06a61e836d9d2d5be98517b468ab72cc
Clare = 63a8ff615a122c56b1d47fc098ff5124
Dave = 2df8d1e02e7f3d13dcea7f4b022d0165
В том же каталоге вы найдете файл с именем mgmt-groups.properties, в нижней части этого файла вы увидите список пользователей и группы, в которых они находятся, например:
Andy =
Боб = лид-разработчики
Clare = разработчикам
Dave = разработчикам
Теперь наведите браузер на
http: // localhost: 9990 и войдите как пользователь Dave. Перейдите вокруг, и вы увидите, что у вас есть полный доступ ко всему.
Именно поэтому необходим RBAC! Разрешение всем пользователям не только получать доступ к консоли управления, но и иметь возможность доступа и изменения чего-либо — это повод для катастрофы и гарантированно вызовет проблемы в дальнейшем. Часто пользователи не понимают последствий изменений, которые они внесли, это может быть просто быстрое решение для немедленного решения проблемы, но это может иметь долгосрочные последствия, которые не будут замечены до тех пор, пока не произойдут дальнейшие изменения. были забыты или не задокументированы. Как человек, работающий в службе поддержки, мы регулярно видим подобные проблемы, и их может быть трудно отследить без отслеживания аудита, а пользователи не понимают, что незначительные изменения, внесенные ими в одну часть системы, в настоящее время вызывают серьезную проблему. в какой-то другой части системы.
Итак, теперь у нас есть настроенные пользователи, но на данный момент они имеют полный доступ ко всему. Далее мы настроим этих пользователей и назначим их на роли.
Прежде всего, запустите CLI.
Запустите следующую команду:
<JBOSS_INSTALL_DIR>/bin/jboss-cli.sh -c
Изменить каталог на узел авторизации
cd /core-service=management/access=authorization
При выполнении следующей команды перечисляются текущие имена ролей и стандартные имена ролей, а также два других атрибута.
ls -l
Здесь нас интересуют две политики разрешения доступа и поставщик.
Политика разрешений-комбинаций определяет, как определяются разрешения, если пользователю назначено более одной роли. Настройка по умолчанию является разрешающей. Это означает, что если пользователю назначена какая-либо роль, которая разрешает определенное действие, то пользователь может выполнить это действие.
Противоположность этому — отклонение. Это означает, что если пользователю назначено несколько ролей, то все эти роли должны разрешать действие, чтобы пользователь мог выполнять это действие.
Другим интересным атрибутом здесь является поставщик. Это может быть либо простой (по умолчанию), либо rbac. В простом режиме все пользователи управления могут получить доступ ко всему и вносить изменения, как мы видели. В режиме rbac пользователям назначаются роли, и каждая из этих ролей имеет разные привилегии.
Включение RBAC
Хорошо, давайте включим RBAC …
Выполните следующие команды, чтобы включить RBAC
cd /core-service=management/access=authorization :write-attribute(name=provider, value=rbac)
Перезапустите JBoss
Теперь наведите браузер на
http: // localhost: 9990 и попробуйте войти в систему как пользователь Энди (который должен иметь доступ ко всему).
Вы должны увидеть следующее сообщение:
Недостаточно прав для доступа к этому интерфейсу.
Это потому, что в данный момент пользователь Энди не привязан ни к какой роли. Давайте исправим это сейчас:
Если вы посмотрите на domain.xml в элементе управления, вы увидите следующее:
<access-control provider="rbac">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
</include>
</role>
</role-mapping>
</access-control>
Это показывает, что на данный момент только локальный пользователь сопоставлен с ролью SuperUser.
Отображение пользователей и групп на роли
Нам необходимо сопоставить наших пользователей с соответствующими ролями, чтобы предоставить им доступ.
Для этого нам понадобится следующая команда:
role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
Если rolename является одной из предварительно настроенных ролей, псевдоним — это уникальное имя для сопоставления, а user — имя пользователя для сопоставления.
Итак, давайте сопоставим пользователя Andy с ролью SuperUser.
./role-mapping=SuperUser/include=user-Andy:add(name=Andy, type=USER)
В domain.xml вы увидите, что наш пользователь был добавлен в роль SuperUser:
<access-control provider="rbac">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
<user name="Andy"/>
</include>
</role>
</role-mapping>
</access-control>
Теперь наведите браузер на
http: // localhost: 9990 , теперь вы сможете войти в систему как пользователь Энди и иметь полный доступ ко всему.
Далее нам нужно добавить сопоставления для других ролей, которые мы хотим использовать.
./role-mapping=Deployer:add ./role-mapping=Monitor:add
Теперь нам нужно предоставить сопоставление ролей всем другим пользователям. Поскольку у нас они есть в группах, мы можем назначать группы ролям, а не отображать их пользователем.
Команда в основном такая же, как для пользователя, но типом является GROUP, а не user.
Здесь мы сопоставляем ведущих разработчиков с ролью Deployer и стандартных разработчиков с ролью Monitor.
./role-mapping=Deployer/include=group-lead-devs:add(name=lead-developers, type=GROUP) ./role-mapping=Monitor/include=group-standard-devs:add(name=developers, type=GROUP)
Если вы посмотрите на domain.xml, вы увидите следующее, показывающее, что пользователь Andy сопоставлен с ролью SuperUser, а две группы сопоставлены с ролями Deployer и Monitor.
<management>
<access-control provider="rbac">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
<user name="Andy"/>
</include>
</role>
<role name="Deployer">
<include>
<group alias="group-lead-devs" name="lead-developers"/>
</include>
</role>
<role name="Monitor">
<include>
<group alias="group-standard-devs" name="developers"/>
</include>
</role>
</role-mapping>
</access-control>
</management>
Вы также можете просмотреть сопоставления ролей в консоли администратора.
Нажмите на вкладку Администрирование.
Разверните элемент «Контроль доступа» слева и выберите «Назначение ролей».
Выберите вкладку «Пользователи» — здесь отображаются пользователи, которые сопоставлены с ролями.
Выберите вкладку Группы, и вы увидите соответствие между группами и ролями.
Войдите в систему как разные пользователи и увидите разницу между тем, что вы можете и не можете получить доступ.
Вывод
Итак, вот и все. Мы включили RBAC, настроили несколько пользователей и групп и сопоставили этих пользователей и группы с определенными ролями, чтобы предоставить им разные уровни доступа.
Во второй части этого блога я рассмотрю ограничения, которые позволяют более детально настраивать разрешения, роли с определенными областями, которые позволяют вам устанавливать разрешения для отдельных серверов, и ведение журнала аудита, который позволяет вам видеть, кто обращается к консоли управления, и видеть, какие изменения они вносят. решения.