[Hawkular-dev] Resourcetype again

[Heiko W.Rupp]

Hey,

>> 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.
>
> This can be the first capability that the agents can declare. Even

Which "this"? :)

> 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.

I would even go further and have that base WF8 type or whatever
be defined for the whole Hawkular system and not per tenant.
I.e. keeping that definition only once in the system.
If that is not possible, we can certainly have that listener install
it in each new tenant.

> 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

Yes.
In fact for more complex scenarios we not only need inventory
be populated "server side", but the feeds (hawkular-monitor) also
need to be able to consume this.

> 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

Yes. I think so.

> 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.

There is certainly a point in this. Could we actually just shut down
a certain api inside inventory (for a certain caller)?


>>
>> 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 ;)

Again: two things. We must not allow a malicious feed (i.e. one where
an attacker has modified resource type definitions to say "every one
can execute") to be uploaded in the server and then prevent any
RBAC checks inside the server.

The other part which you mention is certainly SSO and "run as" for
operations in the agent, which will allow WF to do its own security
checking instead of relying that Hawkular has everything
correctly set up.

>> 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.

Right, if you see the combination of <role(user), WF_Operation> as
a runtime property of such a resource.
Certainly makes sense, but also makes things more complicated
and bloated.
That is probably the price for not running inside the target server
(like the WF-console).