On Tuesday, June 09, 2015 17:47:36 Heiko W.Rupp wrote:
Hey,
we have said that we do no longer want the very strict resource types
that
we had in RHQ. We also identified that we need resource types to define
capabilities like metric types with their units etc. The newest addition
now
are operations and resource config.
I believe that for a certain kind of resource - e.g. "WildFly 8.2", that
"we" manage
we should not have the agent/feed supply the types, but Hawkular should
do so.
A user may still decide to extend that to supply its own data, but we
need to be
careful when dealing with it.
This can be the first capability that the agents can declare. Even today,
nothing prevents anyone with enough permissions to create the resource types a
priori in the inventory. A glue component could listen on the bus and if it
sees a new tenant created, it can add the to-be-predefined resource and metric
types.
We already have a crude "proof-of-concept" of this way of doing things with
our "TemporaryHacks" class that adds the resource types needed for pinger
automagically. TemporaryHacks is in the REST API overlay and therefore has
direct access to the classloader and CDI "environment" of the REST API and
thus can do this using the low level API calls.
There is a question whether the glue component should be written in the same
way as TemporaryHacks - using low level API and circumventing any auth or if
it should be made a true remote component with the implication that it needs
to authenticate against inventory's REST API.
IMHO, we will need to figure out how auth will work in the distributed
scenario anyway - either by for example having some "trusted" interface which
would not be available externally but could be used by the distributed
hawkular components or maybe by just really requiring every component having
controlled access. I am for the latter even if it means more work because it
will provide the users with the ability to lock down the perms of individual
components which is good to minimize the impact in case of security breach in
one of the distributed components.
For security relevant things we can not let the client/feed just provide
resource
type data, as otherwise it is too easy to work around checks.
This could be another agent capability - to support SSO - the auth token would
flow all the way down from the browser to the agent which would execute the
operation as the user on the managed resource. Not sure how feasible this is
but it sounds nice ;)
For WildFly there are a bunch of RBAC roles [1,2] that need to map
to
what
we (will) have in Hawkular, which we may define as just what WildFly
has.
I think we do that - roles in accounts are the same as roles in Wildfly.
In fact that will be beneficial, as users will already know how
WildFly
RBAC works
and can apply it to Hawkular. Plus if the user already has its org
members in
a central KeyCloak with role mappings, we can hook up to that instance
and get the mappings "for free".
Now for operations on WildFly (not only the classic RHQ-operations, but
also modifying
resource config), RBAC in WildFly is "hiding" whole sub-trees, but also
(iiuc) individual attributes
if you do not have the right role:
role=SuperUser:
[standalone@localhost:9990 /] cd /core-service=management/access
[standalone@localhost:9990 access] ls
audit authorization
role=Monitor:
[standalone@localhost:9990 /] cd /core-service=management/access
[standalone@localhost:9990 access] ls
audit
With enough privileges it is possible to see the access definitions
under /core-service=management/access=authorization/constraint=*
While it is possible for WildFly to obtain the security levels
(automatically)
from the WildFly Metadata, we still need to find a good way to add this
information
into our resource types, as the UI may need to react to them and not
show a
restart button for user that only has the Monitoring role.
If these constraints are configurable then I think resource type is not the
right place to have them. IMHO they would better fit into the resources
themselves.
In theory we
could
just issue the operation with the user perms and see it fail on WildFly
side, but that
is certainly not user-friendly and thus not desired.
For other kinds of resource like Tomcat we probably need to encode the
roles
to the best of our knowledge.
Heiko
[1]
http://blog.arungupta.me/role-based-access-control-wildfly-8/
[2]
http://www.dzone.com/articles/configuring-rbac-jboss-eap-and
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev