NaviCloud Sphere - Navisite · NaviSite’s NaviCloud® Sphere platform’s Role Based Access...

NaviCloud® Sphere

Role Based Access Control (RBAC) Introductory Tutorial

March 17, 2011

A Time Warner Cable Company

NaviSite – NaviCloud® Sphere – RBAC Introductory Tutorial – 17-Mar-2011 Page | 2

© 2010-2015 NaviSite, Inc. All rights reserved. NaviSite is a trademark of Time Warner Cable Inc. All other trademarks and copyrights are property of their respective owners.

Table of Contents

ROLE BASED ACCESS CONTROL (RBAC) – INTRODUCTORY TUTORIAL ..................................................................4

1. APPCENTER ADMIN TAB: ACCESS TO RBAC CONFIGURATION .......................................................................5

2. APPROVERS SCREEN CONFIGURATION – APPROVERS, AUTHORIZATION TEMPLATES ............................................5

3. WORKFLOW SCREEN CONFIGURATION – WORKFLOW, REQUIREMENT TEMPLATES .............................................9

4. USERS SCREEN CONFIGURATION – USERS, ROLES, MEMBERSHIP, UI VISIBILITY ............................................... 11

5. POLICY SCREEN CONFIGURATION – POLICY, MEMBERSHIP .......................................................................... 18

6. RBAC APPLIED: RUN-TIME ACCESS CONTROL RESULTS IN APPCENTER ........................................................... 23

7. WRAP UP ....................................................................................................................................... 30

http://www.navisite.com/



Table of Figures Figure 1: Admin tab ....................................................................................................................................... 5

Figures 2: Approvers screen, dialogs, list ...................................................................................................... 5

Figures 3: Authorization Templates screen, dialogs, matrixes ..................................................................... 7

Figures 4: Workflow screen, dialogs, list....................................................................................................... 9

Figures 5: Requirement Template screen, dialog, matrix ........................................................................... 10

Figures 6: Users screen, dialogs, list ........................................................................................................... 12

Figures 7: User Roles screen, dialogs, list ................................................................................................... 13

Figures 8: User Membership screen, dialogs, lists ...................................................................................... 14

Figures 9: User Interface Visibility Management ........................................................................................ 16

Figures 10: Policy screen, dialog, Dev policy ............................................................................................... 18

Figures 11: Policy screen, addition of roles to Dev policy, list .................................................................... 19

Figures 12: Policy screen, dialog, Prod policy ............................................................................................. 20

Figures 13: Policy screen, addition of roles to Prod policy ......................................................................... 21

Figures 14: Servers established for this tutorial ......................................................................................... 22

Figures 15: Policy Membership screen, dialogs, lists .................................................................................. 22

Figures 16: Server power off, policy in effect indicators ............................................................................ 23

Figures 17: Technical approval authority as CTO ........................................................................................ 24

Figures 18: Technical approval authority over Dev server only – as Dev engineer .................................... 25

Figures 19: Technical approval authority over Prod server – as Prod engineer ......................................... 26

Figures 20: Finance approval authority – as founder ................................................................................. 27

Figures 21: Prod engineer redux – seeing and clearing alert ...................................................................... 28

Figures 22: UI visibility conditionally restricted .......................................................................................... 29




Role Based Access Control (RBAC) – introductory tutorial

NaviSite’s NaviCloud® Sphere platform’s Role Based Access Control (RBAC) is a powerful tool that allows for very granular control over which users or groups of users can manipulate objects within AppCenter. AppCenter is the NaviCloud Sphere web-based console for creating, managing, and monitoring virtual machines, the network, or global resources. RBAC was designed to meet sophisticated regulatory requirements in a highly customized manner, allowing you to map the approval framework to your existing workflows.

This document is a tutorial introduction to configuring RBAC. Through step by step illustration, it demonstrates how a new RBAC configuration can be set up to apply essential controls. Additional access control can then be layered into a NaviCloud Sphere system through further application of the same RBAC concepts and tools outlined in this tutorial.

The tutorial proceeds along the following steps:

1. AppCenter Admin tab: Access to RBAC configuration

2. Approvers screen configuration – Approvers, Authorization Templates

3. Workflow screen configuration – Workflow, Requirement Templates

4. Users screen configuration – Users, Roles, Membership, UI Visibility

5. Policy screen configuration – Policy, Membership

6. RBAC applied: Run-time access control results in AppCenter

7. Wrap up




1. AppCenter Admin tab: Access to RBAC configuration You create and modify RBAC configuration through AppCenter’s Admin tab.

Figure 1: Admin tab

The Admin tab consists of four configuration screens. You configure RBAC by working through the Approvers, Workflow, Users, and Policy screens from left to right. Within each screen, you work through its sections from top to bottom. As the configuration proceeds, the screens reference, require, and utilize objects defined in previous steps.

2. Approvers screen configuration – Approvers, Authorization Templates Through the Approvers screen, you define approvers and authorization templates. An approver is not an individual user; rather, an approver is a permission construct – for example: Technical Approval, Finance Approval, Legal Approval. An authorization template is a named matrix of actions on cloud objects, mapped to approvers. It associates acts that you can perform in AppCenter (e.g. powering up and down virtual machines, creating firewalls, etc.) with approvers holding permissions.

2.a. Approvers section From the Approvers section, we create an approver called "Technical".

Figures 2: Approvers screen, dialogs, list




We also want certain operations to require finance approval, so we create another approver called "Financial".

2.b. Authorization Templates section Now that we have two approval permissions that people can attain, we define what those permissions allow. This is managed via authorization templates. We create three templates:

1) Server Admin - will have technical approval for all VM functions. 2) Finance Admin - will have finance approval for all VM functions. 3) All Powerful - will have both technical and finance approval for all VM functions.

Here is how we create the first:




Figures 3: Authorization Templates screen, dialogs, matrixes




If we configure a checkbox in the matrix as checked, then a user associated with the authorization template would be allowed to approve the action, or to execute the action.

We add the other two authorization templates:




3. Workflow screen configuration – Workflow, Requirement Templates Through the Workflow screen, you define workflow and requirement templates. A workflow is a named set of approvers specified in the order in which their approvals are required. A requirement template is a matrix of actions that may be taken on a cloud object, in a specified, required order of approval.

Back on the Approvers screen, we defined the basic constructs of technical and finance approval, and created authorization templates around them. That granted an ability to approve. Here in the Workflow screen we define what approvals are required, in what order.

3.a. Workflow section First we describe the order in which we must apply the Approvers. We create a workflow first and then add the approval order for it.

Figures 4: Workflow screen, dialogs, list

We require Technical approval first, and then Finance approval.




3.b. Requirement Templates section Whereas an Approval screen authorization template associates rights – i.e. things you can do or approve, a Workflow screen requirement template specifies needs. That is, a requirement template specifies that in order for a particular action to take place, the person requesting must have or must gain approval for the action.

Here we define only one requirement template for now, which describes the approvals required for various actions on VMs. We name the requirement template “RBAC Managed Virtual Machine.”

Figures 5: Requirement Template screen, dialog, matrix




We require technical approval for all actions, and finance approval only for actions likely to incur cost (clone, power on VM, etc.).

4. Users screen configuration – Users, Roles, Membership, UI Visibility Through the Users screen, you define users, roles, membership, and UI visibility. Users are specified by name and email address. Roles are named entities, each of which has a defined authorization template. User membership is the assignment of users to roles. UI visibility management is the application of restrictions to prevent certain users from seeing selected portions of AppCenter.

4.a. Users section In this tutorial, we begin with only one user, since this emulates a new implementation. The initial user is designated as a Super admin. The super admin user can create additional users, and can manage the admin status of the user base. Important: Super admin and admin users have access to AppCenter’s Admin tab and therefore the RBAC configuration capabilities. Non-admin users do not. (Only the super admin also has the ability to create admin users.)

Here we create the following five users, which we’ll reference later in this tutorial:

1) [email protected] – Development Engineer 2) [email protected] – Production Engineer 3) [email protected] – Chief Technical Officer 4) [email protected] – Chief Finance Officer 5) [email protected] -- Founder




Figures 6: Users screen, dialogs, list




4.b. Roles section Here we define a number of roles. Roles function as a layer wrapped around authorization templates. In this tutorial we demonstrate that we can share the "Server Admin" authorization template we created earlier – between a "Dev Server Admin" role and a "Prod Server Admin" role. We also create an "All Server Admin" role to show how roles can be used to segregate authority and provide umbrella type of coverage at the same time.

We create the following five roles:

1) Dev Server Admin 2) Prod Server Admin 3) All Server Admin 4) Finance 5) All Powerful

Note: For situations in which we don't need the ability to segregate access based on the underlying object, we have roles which correlate one to one with an authorization template: “Finance” and “All Powerful.” But in the case of server administration we create three roles, all of which reference the server admin authorization template.

Figures 7: User Roles screen, dialogs, list




4.c. Membership section Here we associate individual people (from the list of users we created) with roles. The screen is role-centric, so we go through each role we've defined previously and link the appropriate user(s):

Starting with the "Dev Server Admin" role, we associate "[email protected]".

With the "Prod Server Admin" role, we associate "[email protected]".

The "All Server Admin" role will be filled by the CTO, so we specify "[email protected]".

For the “Finance” role, we specify the CFO, "[email protected]".

In the "All Powerful" role, we put the company founder, [email protected]. In our tutorial example, the founder wants the access and capability to do everything if needed.

Figures 8: User Membership screen, dialogs, lists




4.d. Visibility section In the Visibility section of the Users screen, you can restrict specified users from seeing and accessing portions of AppCenter. By default, users begin with full access to AppCenter (except to the Admin tab, which is displayed only to users defined as administrators). UI visibility configuration is optional. You configure its restrictions only in order to block AppCenter tabs or sub-screens from being seen by a user or group of users.

In this tutorial, we’ll configure and demonstrate only one simple UI visibility restriction: We’ll restrict display of the Services and IP Management screens of AppCenter’s Network tab to Tom CFO. Upon Tom CFO’s login, that portion of the UI will not be visible.

You could define any number of UI visibility restrictions in the same general manner as the simple example we show here.

1. We start at the Visibility section of the Users screen to configure the constraints. 2. We add a Group to which to apply the restrictions. 3. We add user Tom CFO to our user group. 4. We use the Block Section button and dialog to blacklist the Services and IP Management screens

of AppCenter’s Network tab for Tom CFO’s group.

Figures 9: User Interface Visibility Management




5. Policy screen configuration – Policy, Membership Through the Policy screen, you define policy and membership. Policy definition is the association of workflow and authorization, via role. Policy membership associates policy with objects in your cloud environments.

5.a. Policy section When creating a policy you are specifying the workflow requirement template to apply, and optionally the set of roles which should be allowed to approve. If no roles are specified then anyone who has the correct authorization can execute/approve, but if roles are specified, then only people associated with the role may do so. This is how RBAC enables you to share authorization templates, yet still exert granular control over who can approve actions on which objects.

In this tutorial we create only two policies: one to be applied to development servers and one to be applied to production servers. Because the underlying approval needs are the same (we only want segregation on who can approve), both policies reference the "RBAC Managed Virtual Machine" requirement template we created through the Workflow screen.

First we configure the policy for development servers. We add the policy, and then we add roles to it.

Figures 10: Policy screen, dialog, Dev policy

Having created the policy, we’ll specify which roles are considered for approval. Until we do, AppCenter displays the message "Since no roles are assigned to this policy, anyone with the correct approval type

can approve this policy’s approvals." If we do not specify particular roles, then any user tied back to the correct authorization would be able to approve for this policy. But since we want to segregate development and production servers, we do want to use the role-based mechanism.




So we add the following roles:

a) Dev Server Admin b) All Server Admin c) Finance d) All Powerful

Figures 11: Policy screen, addition of roles to Dev policy, list




Next we configure the policy for production servers. We add the policy, and then we add roles to it.

Figures 12: Policy screen, dialog, Prod policy

As we did with the Development VM Control policy, we'll create this policy for production, the only difference being that we include the Prod Server Admin role instead of the Dev Server Admin role. Note that we associate both policies with the "All Server Admin", "Finance", and "All Powerful" roles, since we want those roles to have privileges on both development and production servers.

Therefore we add the following roles to the Production VM Control policy:

a) Prod Server Admin b) All Server Admin c) Finance d) All Powerful




Figures 13: Policy screen, addition of roles to Prod policy




5.b. Membership section Finally, we specify which policies apply to which VMs. By default, a VM has no policy associated with it. This screen is where we apply a policy to an object (VM). For this tutorial, servers named "web-dev", "web-prod", and "web-anon" exist as part of the cloud configuration.

Figures 14: Servers established for this tutorial

We’ll put the development policy on web-dev, the production policy on web-prod, and we'll leave web-anon without policy.

Figures 15: Policy Membership screen, dialogs, lists




6. RBAC applied: Run-time access control results in AppCenter The final segment of this tutorial illustrates the access control effects at run-time of the RBAC configuration defined through the Admin tab’s multiple screens.

First, note that the super admin account used thus far to create the RBAC configuration is not associated with any RBAC policy; therefore the super admin account is considered unprivileged from an RBAC standpoint. Using that account to try to power off all three VMs, we see that web-dev and web-prod become pending approval, as they have policies in effect; web-anon powers off right away, as it carries no associated policy.

Figures 16: Server power off, policy in effect indicators




The super admin logs out and the CTO logs in.

We don't approve anything as CTO, but we do see that the CTO can approve for both the web-dev and web-prod servers, which is part of what we intend the RBAC configuration to do.

Figures 17: Technical approval authority as CTO




The CTO logs out and the development engineer logs in: [email protected]. We see that the dev engineer can approve only the operation on the web-dev server, but not the operation on the web-prod server – because the role limit that we configured on the policy authorizes only the one approval and not the other.

Figures 18: Technical approval authority over Dev server only – as Dev engineer

The approval screen shows the dev engineer that there is a pending job for the web-prod server, but the only valid approvers are the CTO, the prod engineer, and the founder. By contrast, the dev engineer is allowed to approve the operation on the web-dev VM, and does so – and the VM display on the Servers tab reflects that the power off operation goes through.




The development engineer logs out and the production engineer logs in: [email protected].

As the prod engineer we can see the web-prod job, which we are entitled to approve. We do so, and see that the operation goes through to completion.

Figures 19: Technical approval authority over Prod server – as Prod engineer

After the web-prod VM shuts down, the prod engineer attempts to power it back on. But we configured power on as an action which requires finance approval, because a running VM can consume resources and therefore incur cost. We used RBAC to require finance to sign off – therefore the power on operation is displayed as waiting for approval.




The production engineer logs out and the founder logs in: [email protected]. The power on operation is waiting for finance approval, which the founder has. If the founder (or CFO) were to approve the operation, the VM would power on, just as the technical approval in this tutorial’s previous examples allowed the power off operations to occur. But, in this case the founder declines the job for cost reasons.

Figures 20: Finance approval authority – as founder




The founder logs out and the production engineer (the person who requested that the web-prod machine be powered on) logs back in: [email protected].

The Servers tab shows a yellow alert on the VM, and the server detail page shows that the power on job was declined by [email protected].

Figures 21: Prod engineer redux – seeing and clearing alert




Clicking the Ignore link in the Jobs section of the Server Details screen clears the yellow alert indicator from the VM icon on the Servers tab – and the VM remains powered off because the power on request was denied.

Finally, to demonstrate the UI Visibility Management configured in the tutorial, we need to log in as Tom CFO. We see that AppCenter displays only three of the five screens of the Network tab, suppressing display of the Services and IP Management screens as intended.

Figures 22: UI visibility conditionally restricted




7. Wrap up The preceding sections of this tutorial illustrate step by step example configuration and use of the RBAC facilities available in NaviCloud Sphere’s AppCenter. The tutorial covers the following topics on establishing role based access control over the users and components of your NaviCloud Sphere environments:

AppCenter’s Admin tab and access to RBAC configuration.

Approver permission constructs granting ability to approve.

Authorization template configuration that associates approval permissions with cloud object types and the actions performed on them.

Workflow configuration associating approvers and the order in which they must approve.

Requirement template configuration associating actions available on cloud objects with required approval order.

User definition and administrator designation.

Configuration of user roles and their association with authorization templates – enabling the sharing or segregating of approval authority.

User membership associating users with their designated roles.

Configuration of RBAC policy and membership to tie together workflow requirement templates, approval roles, and cloud objects. Application of policy allows for sharing authority at the same time as securing access to specific cloud objects.

An example of how the tutorial’s configuration functions to provide access control in the runtime use of NaviCloud Sphere’s AppCenter UI operating on a cloud environment.

* * * * *


NaviCloud Sphere - Navisite · NaviSite’s NaviCloud® Sphere platform’s Role Based Access...

Documents

Transcript of NaviCloud Sphere - Navisite · NaviSite’s NaviCloud® Sphere platform’s Role Based Access...