OutSystems DevOps Model Series: 3-Access Control Policy
Once we have 4 environments, we can use them to define a proper security access policy and keep things organized.
However, each environment will have a well-defined objective, and we must make sure we know it, they are:
As you can see, each environment really have a well-defined objective!
This is important because this way we can control what will be done in each of them and most important who will have access to do each activity.
To limit access to each environment and define who can do what, OutSystems provides a very good access control mechanism in LifeTime.
In a way that each IT User will have a specific main role, and can even have additional privileges in specifics applications.
To leverage that we have to use LifeTime’s roles and teams.
A detailed information on how to create roles and teams can be found here, here and here.
I will not dive in the details of the process on how to create them but I will say which roles and teams we should have to keep our model organized.
A Lifetime Team is group of Applications and Users.
Each User can be part of different Lifetime Teams and have different roles in them.
Each Application however, can only be part of one Lifetime Team.
To achieve a good level of security and the correct granularity of activities, we will need the following roles and teams:
Please note that when we say Product Team(s) this means that each Product will have a different team using the same roles for its applications. While the Factory Team is only one, and will be responsible for the factory administration and shared components.
Each of these roles will have different permissions level on each environment, the permissions for each role can be found in this table:
*Consumer Role
As you must have noticed a special case in the Product Team is the consumer role.
When you have specific Applications in your Product that can be shared with different Products you will have to split your LifeTime Team and assign the consumer role to each of the Users from other Teams that will reuse it but not change it.
To understand even better check the next image:
Notice that each Product has 2 teams.
One for shared applications and another one for non-shared applications.
High Level View
So far, this is what we will have, when looking for the environments and roles:
Now that we defined all roles and access levels, lets see what each role will be responsible for in our release cycle. On the next article of this series we will talk about Release Management Cycle and what are the activities of each role in it.
Next: 4 — Release Management
Previous: 2 — Requirements
OutSystems DevOps Series Articles:
Disclaimer: Most of the material was gotten from OutSystems documents
