Securing a Plastic SCM system
The two main motivations behind the Plastic SCM security system are:
- Provide a mechanism to control access to the repositories and restrict certain operations.
- Define custom policies for both development and deployment. Even in widely open organizations, the access to certain parts of a repository can be restricted, not only for security related reasons but to prevent mistakes.
After installing Plastic SCM, you can check that any authenticated user of the system will have full access granted.
The first step should be to assign a specific user (or group) as the repository server owner, and then, you can start defining your custom security restrictions. The repository server owner will be the “root” Plastic server user.
After that, it doesn´t matter if you, for some reason, misconfigure any permission because this user will be able to restore them again.
Whether they are to prevent unwanted access or enforce certain development policies, you should consider the following:
- Define the different users and groups that will have access to the Plastic SCM system, and give them the right access on the repository server. Later on, you can customize specific privileges to repositories, branches and even items if required.
- The next step should be to change the repository server permissions. Changing the permissions to the top level element in the security hierarchy will ensure that all the rest of the objects get secured.
ACL´s and Permission inheritance
Each user (SEcured IDentifier or SEID in Plastic terms) or group who has granted or denied permissions will have an entry in a given ACL. Each entry, will have allowed and denied permissions.
Permissions in Plastic SCM are inherited from the top object in the hierarchy (the server) down to the lower ones.
This way, it is very simple to set a group of permissions at the server level that will apply to all the inheriting objects: repositories, branches...
Disable or deny permission?
This is a question that you will probably need to answer when defining your permission policies. You need to take in account that disabling a permission is not the same as denying a permission.
Consider the following example: a certain user is a member of the developers group and at the same time of the integrators group. Developers are not allowed to commit at the main branch but integrator certainly are.
If we actively deny the checkin permission to the developers group on the main branch, this specific user won´t be allowed to perform the operation. The permission is granted due to he is an integrator but it’s denied because he is also a developer, the denied permission prevails over the granted.
On the contrary, if we disable the permission (but not deny it) to the developers group, he will be allowed to perform the checkin operation at the main branch because he also belongs to the integrators group, and combining a disabled permission with an allowed one results in an allowed permission.
Case studies
After this brief introduction to the Plastic SCM permissions system, I would like to review some examples that may help you to implement different permission policies based on your organizational needs.
Case 1: Restrict permissions for integration branches
Imagine you are developing your project using a branch per task branching pattern. Developers create task branches to perform their work.
There are two different groups of people involved in the development: integrators and developers (but certain developers can act as integrators too).
The recommended workflow is the following:
- Developers can’t checkin, applylabel or rmchangeset on the integration branches
- and only integrators can perform these operations.
To handle this scenario, the proposed permissions configuration is:
Disable the checkin, applylabel and rmchangeset permissions to developers (not deny but disable). Integrators will have these permissions allowed, but the developers won´t be able to execute the mentioned operations.
Remember that a user belonging to both groups will have the operations allowed: combining a disabled permission with an allowed one result in an allowed permission, meanwhile the users belonging only to developers won’t be able to perform the operations.
Case 2: Restrict access to branches
In this second scenario, we have a development team that has the following roles: a system administrator group, a development group and an integration group.
- Developers can only work on development branches.
- Integrators can only make changes on integration branches.
- Administrators have full access.
If a user belongs to several groups, he will have all the combined benefits (if a user is both a developer and administrator, he should be given full access).
Steps to set up the scenario:
- The mkbranch permission will be disabled at the repository level for both integrators and developers.
- Development branches: integrators will have the checkin and applylabel permissions disabled. Developers will have the permissions allowed.
- Integration branches: developers will have the checkin and applylabel permissions disabled. Integrators will have all permissions allowed.
Case 3: Restrict access to directories
In this case study, we have two different user profiles working on a branch: developers and artists. And we want to restrict the access to specific directories per user profile.
A possible solution for this scenario could be:
- Developers have all the path permissions enabled.
- Artists have all the path permissions enabled, but the "src" folder.
Summary
We have reviewed the main Plastic SCM features to secure a server and also some classic scenarios where you can customize the rules depending on your requirements.
What are the permission policies that you are using in your company? Could you share your configuration with us?
0 comentarios: