Permissões RBAC no console Wildfly 8
Acesso controlado por permissões no wildfly 8
No JBoss AS 7 (AS7), o usuário de acesso ao console de administração web (GUI) ou por linha de comando (CLI), possuem acesso completo, como um root, pode fazer todas as tarefas de gerenciamento no servidor de aplicativos, como: deploy/undeploy de aplicações, criação de datasources, iniciar/parar servidores, etc.
A partir de sua adoção, foi verificado a necessidade de controlar as permissões para estas tarefas no AS7, por exemplo, ter um grupo de usuários que só podem fazer deploy/undeploy, outro grupo apenas para monitorar, outro grupo para fazer manutenções de rotina, etc.
Então foi criado o suporte a RBAC (Role Based Access Control) no AS7. De fato, com a mudança de nomes do servidor de aplicativos, o AS7 já não recebe atualizações, agora o nome é Wildfly. Então no wildfly 8, que está na versão release candidate, já suporta o RBAC. É o que vou explicar como ele funciona e como configurar e usar esta funcionalidade no wildfly 8.
O suporte a RBAC está disponível no JBoss EAP 6.2. O nome EAP (Enterprise Application Platform), é o nome comercial do servidor de aplicativos wildfly. Ele possui uma interface GUI para associar os usuários com os papéias, bem como as permissões.
O wildfly contém duas formas de controlar as permissões, pelo mecanismo “simple” e “rbac”. O padrão habilitado é o “simple”.
Sobre o RBAC
O RBAC possui os seguintes conceitos:
- Papéis: São os agrupamentos de permissões
- Dados sensíveis: São as informações como nome de usuário e senha, bem como a configuração do RBAC.
- Log de auditoria: É o log das operações, gravadas em um arquivo no formato json.
- Elevação: Um usuário SuperUser pode assumir outro papel para executar operações.
O RBAC contém 7 papéis (roles):
- Monitor: Permissões: Possui as menores permissões. Pode ler configurações e estado do servidor. Não consegue alterar configurações. Não podem acessar dados sensíveis.
- Deployer: Permissões: Mesmas permissões do Monitor, e também pode efetuar deploy e undeploy.
- Operator: Estende o papel monitor. Permissões: Capaz de iniciar/parar um servidor.
- Maintainer: Permissões: Capaz de modificar as configurações, exceto as informações sensíveis.
- Administrator: Permissões: Capaz de modificar configurações, incluindo as informações sensíveis. Tem acesso irrestrito, exceto acesar os logs de auditoria.
- Auditor: Permissões: Mesmas permissões do Monitor, pode ler (sem modificar) dados sensíveis. Pode ler os logs de auditoria.
- SuperUser: Permissões: Possui acesso irrestrito. Pode assumir outro papel sem efetuar logou. É op equivalente de usar o AS7 sem o RBAC.
Documentação sobre log de auditoria
Adicionar usuários
O RBAC usa os usuários já cadastrados no mgmt-users.properties, portanto é necessário adicionar os usuários.
No nosso exemplo, será criado 3 usuários, todos com a mesma senha admin123@
- admin: super usuário
- murilo: usuário deployer
- rafael: usuário maintainer
Vá ao diretório $JB_HOME/bin e reproduza os comandos:
./add-user.sh -p admin123@ -u admin ./add-user.sh -p admin123@ -u murilo ./add-user.sh -p admin123@ -u rafael
Habilitar o RBAC
Por padrão o wildfly 8 está com o RBAC desabilitado. Para habilitar, pode fazer por CLI ou alterar o arquivo xml. Vou usar o modo domínio nos exemplos.
Por linha de comando (CLI)
Para usar jboss-cli, conecte com
$JB_HOME/bin/jboss-cli.sh -c
Nota2: Quando usa-se o jboss-cli para conectar no mesmo servidor (localhost), a autenticação é do tipo “local user” e tem papel de SuperUser (ver item 10.8.3 do guia de administração)
Use o seguinte comando para habilitar o modo RBAC.
/core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
É necessário recarregar as configurações:
reload --host=master
Por editar o domain.xml
Nota: Para alterar o arquivo xml, o wildfly deverá estar parado.
Abrir o domain.xml, procurar pelas configurações abaixo e alterar o “simple” para “rbac”
<management> <access-control provider="rbac"> <role-mapping> <role name="SuperUser"> <include> <user name="$local"/> </include> </role> </role-mapping> </access-control> </management>
Associar usuários e permissões
Neste momento ao tentar efetuar login na GUI, dará erro: Access denied. Pois nenhum usuário está associado com os papéis.
Então vamos associar o usuário admin com o papel SuperUser. Isso é necessário para o primeiro usuário administrador.
Por CLI
/core-service=management/access=authorization/role-mapping=SuperUser/include=user-admin:add(name=admin,type=USER)
Ou pelo domain.xml
<management>
<access-control provider="rbac">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
<user name="admin"/
</include>
</role>
</role-mapping>
</access-control>
</management>
Inicie o wildfly, acesse o console em http://localhost:9990 e faça login como admin e navegue até a estrutura Administration.
Agora o usuário admin já está pronto para gerenciar outros usuários e permissões.
Usar a GUI para associar usuários e permissões
Acesse o endereço http://localhost:9990 e faça login com o usuário admin.
Veja que existe a aba “Administration” que serve para gerenciar a associação de usuários, grupos e papéis.
Nota: O botão de adicionar usuário, é para associar um usuário já existente no mgmt-users.properties com um papel. Ele não cria novos usuários.
A tela de associar usuários, não valida o nome de usuário com o banco de dados de usuários. Sempre confira o nome correto existente no mgmt-users.properties, se o usuário associado não existir, não terá um erro avisando.
Associe o usuário rafael com Maintainer, será usado logo em seguida.
Associe o usuário murilo com Deployer.
Teste
Faça logout, efetue login com o usuário rafael.
Navegue na esgrutura Administration, veja que o usuário não possui permissões.
Navegue na estrutura Profiles -> Connector -> Datasource ExampleDS -> Security. Veja que não possui permissão para ver/editar o login/senha.
Faça logout, efetue login como murilo.
Navegue nas estruturas Runtime -> Overview. Veja que este usuário não tem permissão para iniciar serviços.
Navegue em Profiles -> Datasources, etc. Veja que este usuário não tem permissão para modificar configurações, não há botões Add, Edit, Remove.
Este usuário deployer, pode efetuar deploy de aplicações. Habilitar/Desabilitar aplicações.
Associação de usuário com grupos de servidores ou servidor
É possível associar tarefas administrativas para um grupo de servidores ou um servidor específico.
Nos cenários onde um domínio, possui diversos grupos, como: desenvolvimento contabilidade, desenv financeiro, etc.
No nosso exemplo, vamos permitir que o usuário murilo faça deploy apenas no grupo main-server-group.
Logado como admin, navegue na estrutura Administration -> Roles -> Scoped Roles
Adicione uma role, e preencha:
Name: grupo-main-server-group
base role: deployer
type: server group
scope: main-server-group
Include all: marcado
Salve.
Vá na aba Users, selecione o usuário murilo, clique em Edit.
– na caixa Assigned Roles, clique em Deployer e clique na seta a mover para a caixa Available Roles
– na caixa Available roles, clique em grupo-main-server-group e clique na seta a mover para Assigned Roles, salve.
faça logou e login como murilo.
Faça o deploy de um jar qualquer. Ao associar com um grupo de servidores, veja que não é mostrado o grupo other-server-group.
Logs de auditoria
Com diversos usuários acessando e alterando as configurações do servidor, isso é uma certeza de que problemas podem surgir, “quem fez o deploy ?”, “quem removeu o datasource”, etc. Por isso é necessário manter um log de auditoria das ações dos usuários.
Esse log existe, ele é desabilitado por padrão. O log de auditoria é configurado por host controller ou por servidor. Veja como habilitar.
com o Wildfly iniciado.
Habilitar o log de auditoria apenas para o host controller.
/host=master/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
Habilitar o log de auditoria para todo os servidores de um host controller.
/host=master/core-service=management/access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)
Acima “master” é o nome do seu host controller.
com o wildfly desligado
Abra o host.xml e edite a seção
<management> <security-realms> ... <audit-log> <formatters> <json-formatter name="json-formatter"/> </formatters> <handlers> <file-handler name="host-file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.domain.data.dir"/> <file-handler name="server-file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/> </handlers> <logger log-boot="true" log-read-only="false" enabled="true"> <handlers> <handler name="host-file"/> </handlers> </logger> <server-logger log-boot="true" log-read-only="false" enabled="true"> <handlers> <handler name="server-file"/> </handlers> </server-logger> </audit-log> <management-interfaces> .... </management>
O log de auditoria não tem relação com o subsistema de log, não é possível criar um handler e relacionar com o log de auditoria.
Nesta versão, o formato de saída do log é Json, não tem outro. (ver se existe rfe para outros formatos e configurações)
NOTA: pelo formato ser json, e pela quantidade de operações administrativas no domínio, o arquivo de auditoria pode ficar grande, então pense nisso quando ativar o log de auditoria.
Veja um exemplo do log de auditoria, mostra a adição de uma categoria de log “br.com.teste.empresa” no profile “full” pelo usuário “admin”.
2014-01-31 22:07:35 - {
"type" : "core",
"r/o" : false,
"booting" : false,
"version" : "8.0.0.Final-SNAPSHOT",
"user" : "admin",
"domainUUID" : null,
"access" : "HTTP",
"remote-address" : "127.0.0.1/127.0.0.1",
"success" : true,
"ops" : [{
"address" : [
{
"profile" : "full"
},
{
"subsystem" : "logging"
},
{
"logger" : "mne"
}
],
"operation" : "add",
"category" : "mne",
"use-parent-handlers" : true,
"level" : "FINEST",
"operation-headers" : {
"access-mechanism" : "HTTP",
"domain-uuid" : "6485c914-b071-4c6f-aeac-feac7da0835e",
"push-to-servers" : null
}
}]
}
O formato json, permite que se use scripts de formatação de saída, caso desejem formatar em colunas por exemplo. Isso fica para outro blog.
Quando usar controle de permissão
Estas permissões no console só são úteis se o cliente realmente precisa dar acesso a outros usuários e garantir uma segurança de acesso e atividades.
Com o uso do controle de acesso por roles, aumentam as tarefas de administração do servidor, de associação de roles, usuários, grupos, servidores, etc.
Deixe um comentário