[Hawkular-dev] Resourcetype again

[Lukas Krejci]

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 at localhost:9990 /] cd /core-service=management/access
> [standalone at localhost:9990 access] ls
> audit          authorization
> 
> role=Monitor:
> 
> [standalone at localhost:9990 /] cd /core-service=management/access
> [standalone at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev