NaviCloud Sphere. Role Based Access Control (RBAC) Introductory Tutorial. A Time Warner Cable Company. March 17, 2011

Transcription

1 NaviCloud Sphere Role Based Access Control (RBAC) Introductory Tutorial March 17, 2011 A Time Warner Cable Company

2 Table of Contents ROLE BASED ACCESS CONTROL (RBAC) INTRODUCTORY TUTORIAL APPCENTER ADMIN TAB: ACCESS TO RBAC CONFIGURATION APPROVERS SCREEN CONFIGURATION APPROVERS, AUTHORIZATION TEMPLATES WORKFLOW SCREEN CONFIGURATION WORKFLOW, REQUIREMENT TEMPLATES USERS SCREEN CONFIGURATION USERS, ROLES, MEMBERSHIP, UI VISIBILITY POLICY SCREEN CONFIGURATION POLICY, MEMBERSHIP RBAC APPLIED: RUN-TIME ACCESS CONTROL RESULTS IN APPCENTER WRAP UP NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 2

3 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 Figures 6: Users screen, dialogs, list Figures 7: User Roles screen, dialogs, list Figures 8: User Membership screen, dialogs, lists Figures 9: User Interface Visibility Management Figures 10: Policy screen, dialog, Dev policy Figures 11: Policy screen, addition of roles to Dev policy, list Figures 12: Policy screen, dialog, Prod policy Figures 13: Policy screen, addition of roles to Prod policy Figures 14: Servers established for this tutorial Figures 15: Policy Membership screen, dialogs, lists Figures 16: Server power off, policy in effect indicators Figures 17: Technical approval authority as CTO Figures 18: Technical approval authority over Dev server only as Dev engineer Figures 19: Technical approval authority over Prod server as Prod engineer Figures 20: Finance approval authority as founder Figures 21: Prod engineer redux seeing and clearing alert Figures 22: UI visibility conditionally restricted NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 3

4 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 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 4

5 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 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 5

6 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: NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 6

7 Figures 3: Authorization Templates screen, dialogs, matrixes NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 7

8 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: NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 8

9 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. NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 9

10 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 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 10

11 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 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) deveng@anyco.com Development Engineer 2) prdeng@anyco.com Production Engineer 3) cto@anyco.com Chief Technical Officer 4) cfo@anyco.com Chief Finance Officer 5) founder@anyco.com -- Founder NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 11

12 Figures 6: Users screen, dialogs, list NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 12

13 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 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 13

14 4.c. Membership section Here we associate individual people (from the list of users we created) with roles. The screen is rolecentric, 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 With the "Prod Server Admin" role, we associate The "All Server Admin" role will be filled by the CTO, so we specify For the Finance role, we specify the CFO, In the "All Powerful" role, we put the company founder, In our tutorial example, the founder wants the access and capability to do everything if needed. Figures 8: User Membership screen, dialogs, lists NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 14

15 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 15

16 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 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 16

17 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 17

18 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. NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 18

19 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 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 19

20 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 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 20

21 Figures 13: Policy screen, addition of roles to Prod policy NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 21

22 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 webanon without policy. Figures 15: Policy Membership screen, dialogs, lists NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 22

23 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 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 23

24 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 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 24

25 The CTO logs out and the development engineer logs in: 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. NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 25

26 The development engineer logs out and the production engineer logs in: 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. NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 26

27 The production engineer logs out and the founder logs in: 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 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 27

28 The founder logs out and the production engineer (the person who requested that the web-prod machine be powered on) logs back in: The Servers tab shows a yellow alert on the VM, and the server detail page shows that the power on job was declined by founder@anyco.com. Figures 21: Prod engineer redux seeing and clearing alert NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 28

29 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 NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 29

30 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. * * * * * NaviSite NaviCloud Sphere RBAC Introductory Tutorial 17-Mar-2011 Page 30