• Home
  • About Us
  • Products
  • Industry
  • Customers
  • Partners
  • Blog

XebiaLabs Blog

 

Deployit Cookbook: Setup Security Roles

Posted on April 26, 2012 by Hes Siemelink

Deployit provides fine-grained security settings based on roles and permissions and allows them to be configured through the CLI and in the GUI.

In this example, we'll be setting up security roles using the GUI. The example environment has two applications, OnlineOrders and SiteSearch that are both deployed to a test server before going to production. There are two different teams developing and deploying the applications. One team can't see the other's team application. Moreover, developers can only deploy to the test environment. Deployers can deploy both to the test environment and to production.

We'll set up different security roles for the different users in the organization.

This example assumes that there are already users and groups present in the system, for example by way of LDAP integration. For more detailed information on Deployit Security (including LDAP integration), please refer to the Deployit Security Manual

Overview

Here's an overview of the environment for this example.

security-setup-overview

We have two applicatons: OnlineOrders and SiteSearch. They're maintained by two different teams and deployed independently.

Both applications are deployed to the same environments: The Test Environment, containing one server called testserver and the Production Environment, that contains two physical servers, server1 and server2.

Roles

At the current state, no roles have been implemented.

This is the list of roles we want to have in the system.

  • OnlineOrders developer - May update the OnlineOrders application.
  • SiteSearch developer - May update the SiteSearch application.
  • Lead developer - May update and install any application on the Test Environment
  • OnlineOrders Deployer - May update OnlineOrders application in Test and Production
  • SiteSearch Deployer - May update SiteSearch application in Test and Production
  • Lead Deployer - May install any application on any environment

To add roles, log in as the a user with admin rights and got the Admin tab. Under the Admin tab, click on the Roles tab. This is the screen where you add, modify and delete roles. To add a role, click on the green plus on the right-hand side of the screen.

Roles

Enter the name of the role in the first column. The role is used within Deployit only. In the second column, 'Principals', you can specify a list of users and groups. If you have configured Deployit to point to your LDAP directory, you can add users and groups from LDAP here. To enter more than one principal, use a comma-separated list.

Hit Save to persist the changes. Note that the UI will display the roles in alphabetical order.

Directories

The following is important enough to put in italics:

In Deployit, you can only set security permissions on directories.

That means it's not possible to set permissions on individual CI nodes, like Packages or Environments. In practice you will need to impose a folder structure on your repository in order to set fine-grained permissions. The advantage here is that security will be explicit and localized in one place. Note that the root nodes in the repository ('Applications', 'Environments', etc.) are a special kind of folder and also allow setting of permissions.

Now let's add some directories. Go to the Repository browser, right-click on Applications and choose New > core > core.Directory. Name the new directory "Order". Now move the OnlineOrder package into the newly created Order directory by way of drag-and-drop. Following this procedure we create the following structure:

security-setup-directories

Assigning Roles

To assign roles, right-click on a Directory and choose Permissions. Let's start by assigning roles to the Applications/Orders directory.

Right click permissions

In the resulting screen, we add roles for Lead Developer, Lead Deployer, OnlineOrders Developer and OnlineOrders Deployer.

We assign the roles as follows.

Permissions on the application

This means that both the Lead Developer and the Lead Deployer are allowed to add and remove applications in the Orders directory, but regular developers and deployers assigned to the project may only upgrade an existing deployment, say from OnlineOrders 1.0 to 2.0.

We can do a similar setup for the Search directory, substituting the OnlineOrders Developer and Deployer roles with the corresponding SiteSearch roles.

Note that if a role is not added to this screen, it effectively has no permissions. To remove a role, simply untick all its permissions and hit Save.

Now we'll set permissions to the Test environment. This environment is can be accessed by both development and ops teams. Simply add all roles and grant all permissions to the Lead Developers and Deployers. Regular developers / deployers have more restricted access.

Permissions on Test environment

For production, we only want deployers to have access. Only the lead deployer may alter the environment from Deployit.

Permissions on Production environment

Refining Security Levels

In our current setup, the Test and Production environments are shared for the OnlineOrders and SiteSearch applications. That means that the OnlineOrders deployers can see the SiteSearch application and vice versa. To avoid this, we need to split the environments into application-specific environments. So the Production environment will be split into an 'Online Order Production environment' and 'SiteSearch Production environment'. Note that they will still refer to the same physical servers. But, by splitting them up, you can effectively hide them from different sets of users in Deployit. To do so, we will also need another Directory layer, that splits the applications under the Environment node.

Here's the new setup:

The permissions for Environment/Orders/Production look like:

There are several important issues to note here.

NOTE 1 - Security setting on a lower level overwrite all permissions from a higher level. So the settings on the Orders/Production directory is all there is for the OrderSearch Production Environment. There is no inheritance from higher levels, combining settings from various directories.

NOTE 2 - If there are no permissions set on a directory, the permission settings from the parent are taken (recursively). So if you have a deep hierarchy of nested directories, but you don't set any permissions on them, Deployit will take the permissions set on the root node, Environments for example.

NOTE 3 - All directories higher up in a hierarchy need to provide read permission for the roles defined in the lowest directory. Otherwise the permissions itself can't be read! This analogous to file permissions on unix directories. On unix, you also need read permissions on (all) parent directories, in order to list its contents. For example, here's the permissions table of Environment/Orders

Restricted access in the UI

After setting up the security roles, users will have restricted access to the UI. For example, this is what an OnlineOrder developer will see when logging in:

Note that the SiteSearch application and environments are missing, as well as the Production environment for OnlineOrders. The Admin tab is also inaccessible.

This concludes our Security Setup example. For more information, please refer to the Deployit Security Manual

Share

About Hes Siemelink

Hes Siemelink is Product Developer at XebiaLabs.
View all posts by Hes Siemelink →
Tags: Deployit, Security
Filed under: Deployit Cookbook. Bookmark the permalink.
 
← Prev Post
Next Post →

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

How Can We Help?

XebiaLabs USA
  • Live Chat Online
  • Phone:508.983.2515
    508.983.2512
  • 98 N. Washington St.
    Suite 501
    Boston, MA 02114
  • Email:info@xebialabs.com

Blog Authors

Sort by Blog Author
Vincent Partington
CTO
Andrew Phillips
VP of Product Management
Xebia Team

Tags

Agile agile operations Agile Strategy alm Application Deployment Application Lifecycle Management Application Release Automation ARA automation best practices cloud cloudbees Cloud Deployments configuration management Continous Integration Continuous Delivery Continuous Deployment Continuous Deployments Continuous Integration continuous value customization datapower Deployit Deployment deployment automation deployment package Deploy to JBoss. Scale. Deploy to Tomcat Deploy to Weblogic Deploy to WebSphere devops dpadmin DTAP Frameworks ITIL ITSM jenkins Oracle Puppet release automation release management virtual appliance Virtualization websphere Xebia Labs

Archives

  • May 2013 (1)
  • April 2013 (1)
  • March 2013 (3)
  • February 2013 (2)
  • January 2013 (4)
  • December 2012 (1)
  • November 2012 (3)
  • October 2012 (2)
  • September 2012 (1)
  • August 2012 (5)
  • July 2012 (3)
  • June 2012 (1)
  • May 2012 (3)
  • April 2012 (4)
  • March 2012 (1)
  • February 2012 (3)
  • January 2012 (2)
  • November 2011 (6)
  • October 2011 (3)
  • September 2011 (1)
  • August 2011 (3)
  • July 2011 (1)
  • June 2011 (2)
  • May 2011 (6)
  • April 2011 (2)
  • February 2011 (1)
  • January 2011 (4)
  • December 2010 (3)
  • November 2010 (2)
  • October 2010 (1)
  • August 2010 (1)
  • July 2010 (2)
  • June 2010 (3)
  • March 2010 (2)
  • February 2010 (1)
  • December 2009 (1)
  • November 2009 (1)
  • August 2009 (2)
  • July 2009 (1)
  • January 2009 (1)
  • August 2008 (1)
Copyright XebiaLabs B.V. ©.All rights reserved. Disclaimer
Home| About us| Products| Industry| Customers| Partners| News| Blog