The team-based and role-based security model in IBM UrbanCode Deploy v6.x can be described as slightly intricate. Its intricacies give it the flexibility and capability to satisfy a broad range of requirements though. This guide is an outline of how to configure the security model in core UrbanCode Deploy. It is supplemental to the Knowledge Center’s description of Deploy’s security model. My intent is to give direction on how to adapt the model based on individual requirements, so please share your comments, questions, and feedback so I can continuously improve the guide.
The content in this post revolves around these items, which are all visible in UrbanCode Deploy on the Settings tab:
Getting Started with LDAP/SSO
Immediately after installation of the server, the only available ID for use is the default administrator ID (admin). This password is set during the server installation process. Most organizations will then opt to configure LDAP or SSO as an Authorization Realm and Authentication Realm in the tool. An authorization realm in UrbanCode Deploy is used to search for an ID and determine which groups it belongs to. An authorization realm works in conjunction with an authentication realm, which is used to confirm a user’s identity upon login using a password. With both realms defined, there is no need to manage user IDs and group membership in the tool outside of an existing corporate directory. When properly configured, users can login to UrbanCode using their existing corporate credentials, and any applicable groups/IDs will be auto-imported as needed. Most importantly for this portion of the setup is to engage an LDAP/SSO administrator ahead of time, in order to figure out all the connection details and search strings which are needed. The administrator should also be available while testing the configuration.
Integrating UrbanCode with LDAP is arguably the easiest part of the security configuration. Next we come to Teams and Roles. Keep in mind that UrbanCode Deploy is an enterprise-class solution, purposefully built to scale and enablement self-serve deployments for all applications/teams in the organization. From a hierarchical perspective, teams and roles are at the top of the security model so if these are not defined carefully, it can make things difficult in the future.
Every team in UrbanCode Deploy (a “System Team” exists by default) has all roles available to it. The tool assumes common roles across your application development teams, but it doesn’t require any role to be filled. While planning, think of teams and roles in the context of the entire organization. Ask yourself these questions:
- What application development teams exist across my organization? Do an assessment if that is what’s required to answer this question.
- What are some of the common roles that are played in application development teams across the company? In most cases, there are developers, testers, release engineers, DBAs, stakeholders, and operations/production support engineers. There may be others in your organization.
- Does my organization want to centrally manage application deployments and the underlying processes, or allow the development teams to manage this themselves? This will naturally impact how permissions are granted to various roles. Most organizations with a central DevOps strategy will predefine all deployment processes using templates. Think about how much freedom you can afford to grant to your development teams, and the pros and cons of doing so.
- What permissions should be granted to a stakeholder versus a developer or a production support engineer, for example? Confer with key stakeholders and decide what permissions should be granted to each role. For example, developers may have the ability to create new components and applications from a template and deploy at will to upstream development and test environments, but perhaps they shouldn’t be able to deploy any applications to more stable environments such as SIT or UAT. Support engineers may not be given permission to create new components or applications at all, nor edit the processes associated with them, but they may have the ability to deploy existing applications to more stable environments. This list goes on.
You may find the need to create very similar but slightly different roles to accommodate how different teams work in your organization. You may also need to look closely at the application development teams you have identified and see if it makes sense to decompose any of them into smaller teams. Whatever the case, once you reach a consensus about teams and roles, document the information and review it again before implementing anything in the tool.
Creating Teams and Roles, and Setting Permissions on Roles
Defining new teams in the tool is pretty simple. Click a button, pick a name, and save. Defining new roles and setting the correct permissions for each is a bit more involved. By default, new roles that are created have no permissions at all. The only role that is predefined in UrbanCode Deploy is the Administrator role, which has all permissions. Also, recall that users and groups can have different roles on different teams.
The UrbanCode Deploy Knowledge Center provides a complete reference for permissions. Spend an hour or two familiarizing yourself with the permissions that are available and what they mean. This is a prerequisite to participating in the discussion about how to grant permissions to various roles. A useful approach for deciding which permissions to grant to each role is to use a spreadsheet or even a checklist that contains all the items listed in the reference. For each role, run through the complete list of items and use a highlighter to indicate the permissions that should be granted to that role. Once you have repeated this process for all roles, review the results as a team before implementing it in the tool.
If you are going to use Security Types in the tool (see next section), include this in your discussion about permissions before doing any implementation.
Using Security Types
UrbanCode Deploy distinguishes between object types and security types. There are ten distinct object types (listed vertically in the next screenshot). Object types can have multiple security types, which allows administrators to set different permissions on object types based on security classification. For example, take the “Environment” object type. Administrators can create additional security types beneath this object type to set different permissions on DEV environments versus QA or PROD environments. This works similarly for agents, components, templates, or other objects. A default security type called “Standard” exists for all objects and cannot be deleted. New security types can be created for each object type using the “Type Configuration” sub-tab (on the Settings page):
Once additional security types have been created, they are visible on the “Role Configuration” sub-tab, which is where permissions are configured.
It is sometimes useful to define a separate role called “Team Lead” (or something similar) if there will be someone other than Administrator managing users and roles for any team. With this approach, the primary Deploy administrators do not have to get involved with managing individual team membership. The key difference between Team Lead and the Administrator role is the “Manage Security” permission under Server Configuration. Users with the “Manage Security” permission in UrbanCode Deploy can grant themselves any additional permission they want. Effectively, the “Manage Security” permission allows users to do ANYTHING in the tool, so the Team Lead role is also used to limit the number of users with that permission. The “Add Team Members” permission should remain enabled for the Team Lead role:
In order for Team Leads to manage team membership without the “Manage Security” permission, they must click their username in the top-right of the web UI and select My Profile → My Teams:
The user acting as Team Lead should also be assigned to all other roles on the team (except Administrator), in order to be able to add/remove users or groups to other roles. This is really just a simplification exercise. UrbanCode Deploy will look at the permissions granted to each role and forbid the current user from managing roles which have more permissions than he/she does. In other words, if the Team Lead has less permissions than any other role you have defined, he/she will not be able to manage that role and Deploy will return an error if an attempt to do so is made. Thus, to simplify, the user acting as Team Lead should also be assigned to all other roles on the team (except Administrator).
Mapping Users/Groups to Roles
At this point in the configuration, the foundation of the security model is set. One of two important steps that remain is to build out the team by mapping users and/or groups to various roles. This is relatively straightforward. If there are groups in LDAP that align closely with the roles that have been defined in Deploy for a particular team, this may also go fairly quick. Map users and groups to a particular team by clicking “Add Users & Groups” on the Team sub-tab. This reveals a side-panel that allows Team Leads and Administrators to drag-and-drop new users/groups onto a role.
Team Object Mappings
Users and groups are mapped to roles in the context of a team. Team roles and security types determine what permissions are granted to a user/group. In addition to mapping users and groups to a role for every team, you must also map objects to each team. For newly created objects, users can set default team mappings by clicking their username and selecting My Profile → Preferences. If users do not set this preference, newly created objects will map to all teams for a user.
For existing objects in UrbanCode Deploy, these can be mapped to a team under the “Team Object Mappings” section on the Teams sub-tab. This requires the “Manage Security” permission:
Select the object type using the View drop-down, then select a security type using the Type drop-down. Click Add to see a pop-up similar to the following:
This is a list of all available objects of the selected object type and security type that are not already mapped to the team. Select the objects you want to add and click OK.
Save the Administrator role for just a few users or a small group. There should only be a few roles which have the “Manage Security” permission. You do not need to fill the Administrator role on each team.
When mapping users/groups to roles, it is possible to shift some of this administrative overhead back to LDAP by maintaining separate LDAP groups for each role on each team. In UrbanCode Deploy, only a single group then is mapped to each role on a team.
In order to take full advantage of the team-based and role-based security model in Deploy, first decide which teams you are going to create. From a strategic standpoint, think specifically about what you want to get out of the tool. Take some time to carefully plan how you want to build your team structure, then think about what roles may exist on all of those teams. During this process, consult the Knowledge Center’s permissions reference to understand what permissions can be granted per role on various objects (and their security types). Remember that roles are common to every team in the tool but not all roles will be filled on each team.
Users and groups must be mapped to roles for every team. Integrating UrbanCode Deploy with LDAP allows organizations to leverage an existing corporate directory for user identity and group membership.
There are ten object types in the tool including applications, components, processes, agents, various templates, and others. Objects must be mapped to one or more teams in order for them to be used. Users should set default team mappings for newly created objects in their profile preferences.
New security types can be defined for each object type in UrbanCode Deploy. This will allow you to set different permissions on objects based on security classification (i.e. applications, agents, environments, etc. in PROD versus those in DEV).
Once again, if you have questions, comments, or feedback, please connect with me somehow. I am happy to engage in additional discussion on this topic.