6 Replies Latest reply on May 1, 2015 6:31 AM by Bill Robinson

    How can I quickly edit the Policy Access Control List of an ACL Policy?

    Kai Hintze

      BladeLogic Server Automation Suite 8.5 SP1 P2, running on mixed Windows and Unix.


      As we expand our BladeLogic installation we are adding lots of Roles with their associated ACL Templates and ACL Policies. Most of the groups want very similar Roles, for example MX_Windows_Admin is just like US_Windows_Admin role except for the servers they can access. So to make the MX_Windows_Admin Role I just log into the Automation Console GUI with an RBAC Admin role,

      open the Roles tree,

      right click on US_Windows_Admins and select copy,

      right click on Roles and paste.

      Now I have Copy of US_Windows_Admin Role. I use the Properties pane to change its name, then open the new Role to clear the Users list. The Authorizations, Agent ACL, and Group mappings are all the same and the MX_Windows_Admin Role is ready to go.... except ... I need a matching Objects Permissions Template.


      So I go up to the ACL Templates tree and do the same sort of copy and paste to copy US_Windows_Admin_ACL_Template to MX_Windows_Admin_ACL_Template. Not difficult except that now I need a matching ACL Policy to go in the Template Access Control tab.


      So I go up to the ACL Policy tree, and do the same sort of copy and paste to copy US_Windows_Admin_ACL_Policy to MX_Windows_Admin_ACL_Policy. This is where it gets Ugly, because the ACL Policy has the Policy Access Control List tab, and that has *lots* of specific Role Authorizations, which loops me back where I started because every one of those Role Authorization has to be changed from US_Windows_Admin to MX_Windows_Admin. If it were just once I could take a few screenprints to show all of the Role Authorizations, clear them, and reproduce them in the GUI. It would be slow and error-prone, but it could be done.


      But once I'm done setting Mexico I need to set up Colombia and Brazil, and then we move to the UK and Europe....


      So my questions:


      1) Is there a pair of CLI loops that would let me copy the permissions out of one ACL Policy, edit them, and put them in another ACL Policy? It seems like there out to be, but I've spent a couple of weeks in the BLCLI documentation I've found and haven't been able to put together one that works yet.


      2) Is there a better way to do this whole process?



        • 1. Re: How can I quickly edit the Policy Access Control List of an ACL Policy?
          Bill Robinson

          blcli_execute BlAclPolicy showPolicyPermissions <policyName>

          should dump what's in the acl policy.


          and then some sed/awk/etc to switch out the role names.


          as far as a better way...

          1 - get away from the explicit permissions and use the authorization profiles to group together specific types of access, etc 'create a package' or 'browse a server'.  then you can update one object and affect everything it links to.


          2 - maintain something outside of bsa w/ the information you need and then script the creation of the roles and such. you could also script a check that all the rbac objects match your source of record so that adding some perms in to a class of roles - eg <SITE>_WIN_ADMINS is a single update to a csv and then a run of the script.


          3 - w/ #2 the objects are created from scratch so no chance for something you forgot to clean up.

          • 2. Re: How can I quickly edit the Policy Access Control List of an ACL Policy?
            Kai Hintze

            The three blcli commands are:

            blcli -r RBACAdmins BlAclPolicy showPolicyPermissions <policyName>

            blcli -r RBACAdmins BlAclPolicy createAclPolicy <policyName> "<description>"

            blcli -r RBACAdmins BlAclPolicy addPolicyPermission <policyName> <roleName> <authName>


            As Bill said, there is a bit of manipulation between, but it is very straightforward once I had all three commands.


            Related question:

            I can add Role permissions with

            blcli addAuthorizationToRoleByName <Role> <Type.Permission>


            But how do I get the list of Authorizations from an existing role to copy them across?


            I found a back-door that works for now.... If I open the source Role then the Summary tab has a table with the Authorizations in one column, and (at least in our setup) the word Direct in the second column. I suspect the second column is because we set the Authorizations directly rather than using the more sensible Authorization Profiles. The table is text, so I can cut and paste it. It seems like there out to be a programmatic way though, so that I can script the whole thing.




            • 3. Re: How can I quickly edit the Policy Access Control List of an ACL Policy?
              Bill Robinson

              but are you sure that you want to grant the same permissions w/ the acl policy that the role has ?  for example - the role has sever.*.  do you need to grant them server.* via the acl policy you are creating ?  or maybe only server.read and server.browse, because on the servers the acl policy is associated w/, that's all this role needs?


              to do the equivalent of the copypasta i think you can use RBACRole.getSetupSummary and scrape that for the authorizations.

              • 4. Re: How can I quickly edit the Policy Access Control List of an ACL Policy?
                Kai Hintze

                Precisely, that's why I need a way to dump the Role permissions, like I do the ACL Policy permissions.


                I had noticed the RBACRole.getSetupSummary command, but hadn't clicked that that would show the same thing I was cut and pasting from. I'll look into that. Thanks!

                • 5. Re: How can I quickly edit the Policy Access Control List of an ACL Policy?
                  Kai Hintze

                  I got a couple of mails asking for more detail and clarification. I'm replying back here to log the whole conversation, in case anyone else is in a similar situation.


                  I work for a large computer consulting firm. We have commercial, Federal, multiple State, and some US Military clients. Each of them needs to keep data separate from the others. One State client has multiple agencies that need their data segregated. We manage servers in both our own and client data centers. Some of the servers are owned by us and run infrastructure (such as BladeLogic). Many of the servers are owned by us but are dedicated to specific clients. Some are owned by clients, but they pay us to manage them. All in all it is quite an involved mix of ownership and access.


                  We are beginning to use BladeLogic to manage servers. Most of the clients are content to use the MyCompany Global BladeLogic Server instance, and use ACLs to make sure that only people authorized for that client can see their servers, ie, ClientA server and Role ACLs line up, ClientB server and Role ACLs line up, etc. (Yay ACLs!) But that means that we have a great many very similar roles:










                  And so on.


                  The Global roles manage infrastructure, and the Client roles have ACLs that limit access to only servers pertaining to that client. Each Global role is the definitive example of what that role should look like. So when we extend BL management to a new client I have to copy the Operator and multiple Admin Roles to set up that client's ACLs.


                  Further, some clients require an air gap between their servers and anyone else's servers. So we have multiple BladeLogic Server instances. (Where a "server instance" is a database server, a management head, and two or more application servers.) Most of the unique server instances needs further segregation, for example the State with multiple agencies. Frequently when we set up a new server instance we can use the same sort of ACL configuration the Global instance uses, just on new hardware. So I not only copy Roles and ACL policies (with many lines of permissions) to clone them in the Global instance, sometimes I copy them to completely new servers.


                  Obviously, the more we can automate this the better, both to save time and to reduce typing errors.

                  • 6. Re: How can I quickly edit the Policy Access Control List of an ACL Policy?
                    Bill Robinson

                    i did something like this for a customer a long time ago.  they have multiple lines of business and then multiple projects w/in each lob that needed rbac separation.  but each lob and each project had the same set of roles.  a rbac role to manage all of the objects in the 'project', deployer, admin, etc.  so we setup auth profiles to map out all the functions (edit software, deploy, patch, etc), then each 'template' role was some collection of the auth profiles.  then we had a script that would read some properties files that defined the 'template' objects (they didn't exist in bsa) and then you'd provide a csv w/ the project name and some other stuff and it would build out a workspace folder structure, property dictionary class structure, create users and setup all the roles.  at one point i think we stored the 'template' stuff in the property dictionary so you just needed the script and the csv of what you needed to create.



                    you might want to think about something like this if you need to make this portable between bsa installs.  one source of 'truth' that defines your roles (you could even have it reconcile all your roles that already exist if you need to make changes) and a script to enforce that truth in your envs.