Forum Discussion

ecce_297791's avatar
ecce_297791
Icon for Altocumulus rankAltocumulus
Apr 06, 2018

Health monitor security

I've read in the study guide for the 301a exam that instances of health monitors are not partitioned objects. So if I give a user access to partition A he can manage objects within that partition, but also for example stop a monitor associated with a pool member in the Common partition? The study guide goes on saying "You can prevent this unexpected behavior by ensuring that all pools and pool members associated with monitor instances reside in the same partition." (bottom of page 38)

 

I don't get it. The instance of the monitor is still partition unaware, right? How does this work and how do I prevent one user from messing with resources in another partition?

 

2 Replies

  • I dont think it applies to every version out there. It should have been bug on fewer version ? Maybe !

    I tried out on creating a dummypool with dummymonitor on Common partition.

    For example, a user with the Manager role, who  can access partition AppA only, can enable or disable monitor instances for a pool that resides in partition Common

    Created an AppA partition, created an user with role Manager and assigned AppA partition alone. Tried going to the instance section, I dont even see a check box. There's no option to delete the instance.

    Have you tested out ?

  • Hello,

     

    Indeed, the manner in which the sentence is confusing tour that's what the documentation tells us:

     

    -> A user with the "Manager role", who can access partition "COMMON_A" only, can enable or disable monitor instances for a pool that resides in partition "Common". Quite simply, because of instances of monitors are not partitioned objects (these objects can be seen from any partition). And I speak well of "monitors instances"

     

    However, user with the "Manager role" cannot perform operations on the pool or pool members that are associated with the monitor (we are talking about objects and no instance). So he will not be able to remove the monitor from the pool or pool members that are associated with the monitor.

     

    In documentaiton we can see that we can prevent this unexpected behavior by ensuring that all pools and pool members associated with monitor instances reside in the same partition. it's rare to see a user disable an monitor instance of another parition, to tell you the truth, I've never encountered this... On the other hand documentation tells that you can prevent this unexpected behavior by ensuring that all pools and pool members associated with monitor instances reside in the same partition.

     

    So if you create pool and pool memebers for specific OU (So specific partition), ensure that you create your object on the correct and same partition. So that a user can not make changes to this object unintentionally.

     

    however you have to keep in mind that of instances of monitors are not partitioned objects so potentially alterable what never happens ...

     

    Hope that help you. Regards