Using CA AppLogic › Grid Administration Guide › Role-Based Access Control › Example Security Scheme with RBAC

Example Security Scheme with RBAC

CA AppLogic does not provide an extensive scheme of pre-defined groups and users. This allows grid administrators to set up users, groups and object access to suit each particular situation. In general, grid administrators follow these steps:

• Create local users.
• Create a set of local groups. These group may be used to segregate users by type of work (for example, grid administration, application development, QA, etc.), business structures (for example, by department or business unit so that different groups of users may share a grid for their development work) or other practical divisions. The same effect can be achieved also with global groups, which is especially useful when the same setup is used for two or more grids.
• Add users to groups, or groups to groups, as appropriate.
• Modify object ACLs to assign groups specific access level rights.

The following scenario provides a practical example of how this process can work to effectively control user access.

Ace Starships Incorporated (ASI) builds space craft. Each space craft includes software systems for life support and propulsion among many others. These two software systems are developed on a large shared CA AppLogic grid before being deployed to production grids on actual space craft. The development process on this grid includes the following parties:

• Life Support development team
• Propulsion development team
• Outsiders – specialists in middleware appliance development (common appliances)
• Auditors – ASI personnel who require non-destructive access to development
• QA – quality assurance personnel who test the products of both development teams and the Outsiders

In addition we also have:

• A global user john_adams who is a grid administrator – the person responsible for grid administration
• A global user jane_osprey who is a grid operator – the person responsible for the grid when the grid administrator is sleeping

Furthermore:

• ASI uses a company-wide LDAP based directory service for centralized user and group management. Everyone but the Outsiders has an account on this system.
• The propulsion team uses several applications created by the life support team, but does not modify the architecture of these applications.
• Both teams use appliances developed by the Outsiders, but do not modify these appliances.
• There are global catalogs which contain appliances specific to the different development efforts: life_support, propulsion and outsiders.

One of the first decisions to make in this scenario is whether to manage group membership using the company-wide directory, or whether to manage this membership using local groups. In this example we take the first approach:

• Using the ASI company-wide directory, create groups life_support, propulsion, QA and auditors and include in these groups the corresponding global users. This operation is performed outside of CA AppLogic.

Going forward with our example, the initial CA AppLogic user, who is a member of the local group admin, performs the following user and group set up:

• Create a local user account for each of the Outsiders.
• Create the following local groups:
  • outsiders
  • grid_operators
  • app_developers
• Set up group membership:
  • Add the created local users to the local group outsiders.
  • Add the global groups life_support, propulsion and QA to the app_developers group.
  • Add the local group outsiders to the app_developers group.
  • Add the global user john_adams to the admin group
  • Add the global user jane_osprey to the grid_operators group
• Modify object ACLs to set up object access:
  • Modify the grid ACL to:
    • Provide grid_operator access level rights to the local group grid_operators.
    • Provide app_developer access level rights to the local group app_developers.
    • Provide monitor access level rights to the global group auditors.
  • Modify global catalog ACLs to:
    • Provide full access level rights on the life_support catalog to the global group life_support, on the propulsion catalog to the global group propulsion, and on the outsiders catalog to the local group outsiders.
    • Provide configure access level rights on the outsiders catalog to the local group app_developers, and on the life_support catalog to the global group propulsion.

The following tables show group membership in our scenario:

The following table shows access level rights granted to principals for pertinent objects in our scenario:

The initial set up of users and groups is now complete. At this point global users belonging to the global groups life_support, propulsion, QA and auditors can all log in to the grid, and each user is automatically provided the necessary access level rights to perform their work.

Access to the global catalogs has also been set up so that appliances are accessible as required, but only members of the group which has full access level rights on a catalog can perform destructive operations on that catalog.

When a user creates a new application, that user becomes the application owner and is granted full access level rights on that application. At some point, the user may want to modify the application ACL to give other members of his development team, or of another team, access to the application. For example:

• A member of the life support team can grant the local group life_support full access level rights on the application so that other team members can modify it at will.
• A member of the life support team can grant the local group propulsion configure access level rights to the application so that members of this group can configure or use the application but cannot modify its architecture.
• A member of the life support team can grant the global group QA whatever access level rights are necessary for testing the application (for example, read access to make a copy of the application for separate testing, configure access to configure or use the application without modifying its architecture, etc.).

Secure Access to Grid Controller for Applications

There are cases where an application will want to control itself on a grid (introspective control). For example, the SLA controller appliance, which enables the creation of elastic stacks, accesses the grid controller in order to start/stop additional appliances to accommodate the load.

In many cases, the appliance that issues control commands also has some form of user interface that can be exposed for public access. As a result, if someone exploits a vulnerability (e.g., in Apache) and manages to obtain access to the private key for accessing the grid controller, they could be affecting other applications.

With the introduction of role-based access controls (RBAC) in CA AppLogic 3.0, there are some important changes to how access to the controller can be configured for improved security. While there are several approaches, here is the simplest and most secure one.

Create a user for each application that needs introspective control and name that user as a derivative name of the application. For example, for application myapp, you can call the control user myapp_sla. Then, give that user specific control over the myapp application and no other application. This includes two important limitations:

• Only this application - this user will not be able to affect other applications
• Control only - this user will not be able to perform configuration, export/migration or editing of the application

Follow these steps:

1. Create a private key for the application's introspective access. For example, use ssh-keygen inside the SLA controller appliance. Export (or copy to clipboard) the public key.
2. Create user myapp_sla without assigning it to any specific group. For example:

   user create myapp_sla pwd=- sshkey="ssh-rsa xxxxxxxxx="
   

   Note: Enter a very complex unguessable password when prompted, then paste the public key from step 1.

3. Configure the role of the new user as application operator (as opposed to monitor, grid administrator or application developer)

   grid modify_acl myapp_sla=app_operator
   

4. Modify application's ACL to give this user control-only access to this application

   app modify_acl myapp myapp_sla=control
   

Create a Group

If there are many instances that need this type of control (more than 5), it is better to set up the control users as a group rather than adding each of them to the grid ACL separately. This will also work faster on the grid, keeping the grid ACL smaller.

Follow these steps:

1. Create a new group for control users:

   group create sla_users
   

2. Set the role for sla_users:

   grid modify_acl sla_users=app_operator
   

Do this for each separate app instance you want to have isolated control user (instead of the steps in the original post, changes in bold):

1. Create a private key for application's introspective access. For example, use ssh-keygen inside the SLA controller appliance. Export (or copy to clipboard) the public key.
2. Create user myapp_sla and set its primary group to be the control users group. For example:

   user create myapp_sla group=sla_users pwd=- sshkey="ssh-rsa xxxxxxxxx="
   

   Note: Enter a very complex unguessable password when prompted; paste the public key from step 1.

3. Omit this step - the new user inherits the control role from the sla_users group.
4. Modify application's ACL to give this user control-only access to this application

   app modify_acl myapp myapp_sla=control
   

This setup requires two more steps initially (creating the group) but removes a step from each instance and creates a much more manageable configuration.