Control-M Role-based Administration RBA
Caracteristica de Control-M para delegar parte de la administración
Buenas a todx!
El que haya trabajado en la administración de Control-M se habrá dado cuenta que la gestión de permisos no va a la par con otras características que tiene este planificador. Es un poco confusa a mi parecer y bastante limitada, sobre todo me refiero a la hora de la posible delegación de roles.
Para muestra un botón: la delegación de permisos a la hora de la utilización del API. Es cierto que nos deja configurar muchas cosas y es una herramienta maravillosa a la par de potente para poder realizar la administración y/o planificación remotamente pero tenía problemas a la hora de poder gestionar permisos. El que pudiera usar el API teniendo permisos de CCM podía realizar todo tipo de acciones sobre él haciendo que fuera muy peligroso decantarse por esa opción. Pues bien, para ello llega el RBA, una mayor granularidad de permisos que nos permitirá acotar mucho más lo que pueden o no pueden hacer los usuarios.
El RBA introduce una nueva metodología permitiendo a los equipos tener el control total de su trabajo. Los usuarios pueden instalar, configurar y monitorizar sus propios Agentes de Control-m, plugins y perfiles de conexión usando la API, Control-M Web e incluso el cliente de control-M pesado.
La nueva granularidad de las autorizaciones permiten a los administradores de control-m delegar el control de una serie de tareas administrativas sobre ellos. Pudiendo decirles que perfiles de conexión pueden ver y/o editar, que plugins y con que usuarios pueden ejecutar los jobs, así como el nivel de permisos (browse /update / full).
Los privilegios y perfiles que existian antes todavia son validos y los nuevos perfiles RBA trabajan en conjutno con ellos (con relación OR). Esto quiere decir que añadir privilegios RBA a un usuario que ya tiene acceso a viejos privilegios no tiene efectos adicionales. Para adaptar este nuevo modelo, se recomienda poner los privelegios a «None».
Esta nueva capacidad solamente esta disponible cuando el modo de compatibilidad esta en estado off ( recordad que el modo de compaitbilidad esta on por defecto cuando se realiza una actualización ).
Ejemplo de perfil RBA de Control-M versión 20.
Vamos a poner un pequeño ejemplo para que se entienda mejor. Imaginaos que tenéis un grupo de ftp que queréis que pueda actuar sobre el agente de control-m de esa maquina donde esta instalado el módulo. Pues bien, ahora entra en juego el concepto de tags. Las tags son una agrupación lógica de agentes por un nombre determinado. Gracias a ello se puede asignar esa tag a un rol especifico para poder delegar esa parte de la administración. Veamos el ejemplo…
Si creamos un usuario en el grupo Browse podemos observar que no se ve ningun agente:
Ahora añadimos un tag a un agente, y damos browse en RBA a ese tag para ese usuario:
Como podeis ver en la siguiente imagen se puede ver el agente pero no se puede hacer nada con el (Browse):
Ahora modificamos el usuario para darle rol update y comprobamos los permisos:
Ahora probamos con permisos de Full que nos dejara tambien borrar el agente:
Como podéis ver a grosso modo se pueden delegar muchas cosas y nos dan una posibilidad de diseccionar permisos que echábamos en falta en versiones anteriores de Control-M. Bien hecho!
¿Qué os ha parecido? ¿La habéis usado? Cualquier comentario animaros y no os de vergüenza. Animaros!
Esto esta genial!!!! gracias por compartir seguro lo pondre en practica 🙂