OpenStack Cloud Administrator Guide

Transcription

1 docs.openstack.org

2 OpenStack Cloud Administrator Guide current ( ) Copyright OpenStack Foundation Some rights reserved. OpenStack offers open source software for cloud administrators to manage and troubleshoot an Open- Stack cloud. This guide documents OpenStack Kilo, OpenStack Juno, and OpenStack Icehouse releases. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Except where otherwise noted, this document is licensed under Creative Commons Attribution ShareAlike 3.0 License. ii

3 Table of Contents Preface... ix Conventions... ix Document change history... ix 1. Get started with OpenStack... 1 Conceptual architecture... 2 Logical architecture... 3 OpenStack services... 4 Feedback Identity management Identity concepts Certificates for PKI Configure the Identity Service with SSL External authentication with Identity Integrate Identity with LDAP Configure Identity service for token binding Use trusts Caching layer User CRUD Logging Start the Identity services Example usage Authentication middleware with user name and password Identity API protection with role-based access control (RBAC) Troubleshoot the Identity service Dashboard Customize the dashboard Set up session storage for the dashboard Compute System architecture Images and instances Networking with nova-network System administration Troubleshoot Compute Object Storage Introduction to Object Storage Features and benefits Object Storage characteristics Components Ring-builder Cluster architecture Replication Account reaper Configure tenant-specific image locations with Object Storage Object Storage monitoring System administration for Object Storage Troubleshoot Object Storage Block Storage Introduction to Block Storage iii

4 Increase Block Storage API service throughput Manage volumes Troubleshoot your installation Networking Introduction to Networking Plug-in configurations Configure neutron agents Networking architecture Configure Identity Service for Networking Networking scenarios Advanced configuration options Scalable and highly available DHCP agents Use Networking Advanced features through API extensions Advanced operational features Authentication and authorization Plug-in pagination and sorting support Telemetry Introduction System architecture Data collection Data retrieval Alarms Measurements Events Troubleshoot Telemetry Database Introduction Create a datastore Configure a cluster Orchestration Introduction Orchestration authorization model Stack domain users A. Community support Documentation ask.openstack.org OpenStack mailing lists The OpenStack wiki The Launchpad Bugs area The OpenStack IRC channel Documentation feedback OpenStack distribution packages iv

5 List of Figures 1.1. OpenStack conceptual architecture Logical architecture Base image state with no running instances Instance creation from image and runtime state End state of image and volume after instance exits multinic flat manager multinic flatdhcp manager multinic VLAN manager novnc process Trusted compute pool Object Storage (swift) Object Storage building blocks The ring Zones Accounts and containers Partitions Replication Object Storage in use Object Storage architecture Object Storage (swift) FWaaS architecture Tenant and provider networks VMware NSX deployment example - two Compute nodes VMware NSX deployment example - single Compute node Example VXLAN tunnel v

6 List of Tables 1.1. OpenStack services Storage types Description of IPv6 configuration options Description of metadata configuration options Identity Service configuration file sections rootwrap.conf configuration options filters configuration options Description of live migration configuration options Description of VNC configuration options Description of SPICE configuration options Description of Zookeeper configuration options Description of trusted computing configuration options Description of configuration options for [drive-audit] in driveaudit.conf Image settings reported by glance image-list for image ID Networking resources LBaaS features Available networking plug-ins Plug-in compatibility with Compute drivers Basic operations on Networking agents Networking agents General distinct physical data center networks nova.conf API and credential settings nova.conf security group settings nova.conf metadata settings Settings Settings Settings Settings Hosts for demo API abstractions Network attributes Subnet attributes Port attributes Basic Networking operations Advanced Networking operations Basic Compute and Networking operations Advanced VM creation operations Provider extension terminology Provider network attributes Router Floating IP Basic L3 operations Security group attributes Security group rules Basic security group operations Firewall rules Firewall policies vi

7 7.34. Firewalls VMware NSX QoS attributes Basic VMware NSX QoS operations Recommended values for max_lp_per_bridged_ls Configuration options for tuning operational status synchronization in the NSX plug-in Big Switch Router rule attributes Label Rules Basic L3 operations Plug-ins that support native pagination and sorting Consumed event types from OpenStack services List of available transformers Time-to-live support for database back ends Telemetry meter types OpenStack Compute meters OpenStack Compute host meters Metrics of Bare metal module for OpenStack IPMI based meters SNMP based meters OpenStack Image Service meters OpenStack Block Storage meters OpenStack Object Storage meters Metrics for Ceph Object Storage OpenStack Identity meters OpenStack Networking meters SDN meters LoadBalancer as a Service meters VPN as a Service meters Firewall as a Service meters Metrics for the Orchestration module Metrics of the Data processing service for OpenStack Key Value Store module meters Energy meters vii

8 List of Examples 2.1. Configure the Memcached backend viii

9 Preface Conventions Notices The OpenStack documentation uses several typesetting conventions. Notices take these forms: Note A handy tip or reminder. Important Something you must be aware of before proceeding. Warning Command prompts Critical information about the risk of data loss or security issues. $ prompt Any user, including the root user, can run commands that are prefixed with the $ prompt. # prompt The root user must run commands that are prefixed with the # prompt. You can also prefix these commands with the sudo command, if available, to run them. Document change history This version of the guide replaces and obsoletes all earlier versions. The following table describes the most recent changes: Revision Date February 20, 2015 October 15, 2014 July 21, 2014 April 17, 2014 November 12, 2013 Summary of Changes For the Kilo release, the guide has been updated with a new Measurements section in the Telemetry chapter. The tables contain the release information for all collected meters regarding to when they were introduced in the module. In addition, the Orchestration chapter has been added to the guide. It describes in details Orchestration module available in Open- Stack since Havana release. For the Juno release, the guide has been updated with a new Telemetry chapter. Updated variables to use correct formatting. For the Icehouse release, the guide was organized with system administration and system architecture sections. Also, how-to sections were moved to this guide instead of the Open- Stack Configuration Reference. Adds options for tuning operational status synchronization in the NSX plug-in. ix

10 Revision Date October 17, 2013 September 5, 2013 September 3, 2013 Havana release. Summary of Changes Moves object storage monitoring section to this guide. Removes redundant object storage information. Moved all but configuration and installation information from these component guides to create the new guide: OpenStack Compute Administration Guide OpenStack Networking Administration Guide OpenStack Object Storage Administration Guide OpenStack Block Storage Service Administration Guide x

11 1. Get started with OpenStack Table of Contents Conceptual architecture... 2 Logical architecture... 3 OpenStack services... 4 Feedback The OpenStack project is an open source cloud computing platform for all types of clouds, which aims to be simple to implement, massively scalable, and feature rich. Developers and cloud computing technologists from around the world create the OpenStack project. OpenStack provides an Infrastructure-as-a-Service (IaaS) solution through a set of interrelated services. Each service offers an application programming interface (API) that facilitates this integration. Depending on your needs, you can install some or all services. The following table describes the OpenStack services that make up the OpenStack architecture: Table 1.1. OpenStack services Service Project name Description Dashboard Horizon Provides a web-based self-service portal to interact with underlying OpenStack services, such as launching an instance, assigning IP addresses and configuring access controls. Compute Nova Manages the lifecycle of compute instances in an OpenStack environment. Responsibilities include spawning, scheduling and decommissioning of virtual machines on demand. Networking Neutron Enables Network-Connectivity-as-a-Service for other OpenStack services, such as OpenStack Compute. Provides an API for users to define networks and the attachments into them. Has a pluggable architecture that supports many popular networking vendors and technologies. Object Storage Swift Storage Stores and retrieves arbitrary unstructured data objects via a RESTful, HTTP based API. It is highly fault tolerant with its data replication and scale-out architecture. Its implementation is not like a file server with mountable directories. In this case, it writes objects and files to multiple drives, ensuring the data is replicated across a server cluster. Block Storage Cinder Provides persistent block storage to running instances. Its pluggable driver architecture facilitates the creation and management of block storage devices. Identity service Keystone Shared services Provides an authentication and authorization service for other Open- Stack services. Provides a catalog of endpoints for all OpenStack services. Image service Glance Stores and retrieves virtual machine disk images. OpenStack Compute makes use of this during instance provisioning. Telemetry Ceilometer Monitors and meters the OpenStack cloud for billing, benchmarking, scalability, and statistical purposes. 1

12 Service Project name Description Higher-level services Orchestration Heat Orchestrates multiple composite cloud applications by using either the native HOT template format or the AWS CloudFormation template format, through both an OpenStack-native REST API and a CloudFormation-compatible Query API. Database service Data processing service Trove Sahara Conceptual architecture Provides scalable and reliable Cloud Database-as-a-Service functionality for both relational and non-relational database engines. Provides capabilties to provision and scale Hadoop clusters in Open- Stack by specifying parameters like Hadoop version, cluster topology and nodes hardware details. The following diagram shows the relationships among the OpenStack services: Figure 1.1. OpenStack conceptual architecture 2

13 Logical architecture To design, deploy, and configure OpenStack, administrators must understand the logical architecture. OpenStack modules are one of the following types: Daemon Script Command-line interface (CLI) Runs as a background process. On Linux platforms, a daemon is usually installed as a service. Installs a virtual environment and runs tests. For example, the run_tests.sh script installs a virtual environment and runs unit tests on a service. Enables users to submit API calls to OpenStack services through easy-to-use commands. The following diagram shows the most common, but not the only, architecture for an OpenStack cloud: Figure 1.2. Logical architecture As in Figure 1.1, OpenStack conceptual architecture [2], end users can interact through the dashboard, CLIs, and APIs. All services authenticate through a common Identity Service and individual services interact with each other through public APIs, except where privileged administrator commands are necessary. 3

14 OpenStack services This section describes OpenStack services in detail. OpenStack Compute Use OpenStack Compute to host and manage cloud computing systems. OpenStack Compute is a major part of an Infrastructure-as-a-Service (IaaS) system. The main modules are implemented in Python. OpenStack Compute interacts with OpenStack Identity for authentication, OpenStack Image service for disk and server images, and OpenStack dashboard for the user and administrative interface. Image access is limited by projects, and by users; quotas are limited per project (the number of instances, for example). OpenStack Compute can scale horizontally on standard hardware, and download images to launch instances. OpenStack Compute consists of the following areas and their components: API nova-api service nova-api-metadata service Accepts and responds to end user compute API calls. The service supports the OpenStack Compute API, the Amazon EC2 API, and a special Admin API for privileged users to perform administrative actions. It enforces some policies and initiates most orchestration activities, such as running an instance. Accepts metadata requests from instances. The nova-api-metadata service is generally used when you run in multi-host mode with nova-network installations. For details, see Metadata service in the OpenStack Cloud Administrator Guide. On Debian systems, it is included in the nova-api package, and can be selected through debconf. Compute core nova-compute service A worker daemon that creates and terminates virtual machine instances through hypervisor APIs. For example: XenAPI for XenServer/XCP libvirt for KVM or QEMU VMwareAPI for VMware Processing is fairly complex. Basically, the daemon accepts actions from the queue and performs a series of system commands such as launching a KVM instance and updating its state in the database. 4

15 nova-scheduler service nova-conductor module nova-cert module Takes a virtual machine instance request from the queue and determines on which compute server host it runs. Mediates interactions between the nova-compute service and the database. It eliminates direct accesses to the cloud database made by the nova-compute service. The nova-conductor module scales horizontally. However, do not deploy it on nodes where the nova-compute service runs. For more information, see A new Nova service: nova-conductor. A server daemon that serves the Nova Cert service for X509 certificates. Used to generate certificates for euca-bundle-image. Only needed for the EC2 API. Networking for VMs nova-network worker daemon Similar to the nova-compute service, accepts networking tasks from the queue and manipulates the network. Performs tasks such as setting up bridging interfaces or changing IPtables rules. 5

16 Console interface nova-consoleauth daemon nova-novncproxy daemon nova-spicehtml5proxy daemon nova-xvpnvncproxy daemon nova-cert daemon Authorizes tokens for users that console proxies provide. See nova-novncproxy and nova-xvpnvcproxy. This service must be running for console proxies to work. You can run proxies of either type against a single nova-consoleauth service in a cluster configuration. For information, see About nova-consoleauth. Provides a proxy for accessing running instances through a VNC connection. Supports browser-based novnc clients. Provides a proxy for accessing running instances through a SPICE connection. Supports browser-based HTML5 client. Provides a proxy for accessing running instances through a VNC connection. Supports an OpenStack-specific Java client. x509 certificates. In Debian, a unique nova-consoleproxy package provides the nova-novncproxy, nova-spicehtml5proxy, and nova-xvpvncproxy packages. To select packages, edit the /etc/ default/nova-consoleproxy file or use the debconf interface. You can also manually edit the /etc/default/nova-consoleproxy file, and stop and start the console daemons. Image management (EC2 scenario) nova-objectstore daemon euca2ools client An S3 interface for registering images with the Open- Stack Image service. Used primarily for installations that must support euca2ools. The euca2ools tools talk to nova-objectstore in S3 language, and nova-objectstore translates S3 requests into Image service requests. A set of command-line interpreter commands for managing cloud resources. Although it is not an OpenStack module, you can configure nova-api to support this EC2 interface. For more information, see the Eucalyptus 3.4 Documentation. Command-line clients and other interfaces nova client Enables users to submit commands as a tenant administrator or end user. Other components The queue A central hub for passing messages between daemons. Usually implemented with RabbitMQ, but can be implemented with an AMQP message queue, such as Apache Qpid or Zero MQ. 6

17 SQL database Stores most build-time and run-time states for a cloud infrastructure, including: Available instance types Instances in use Available networks Projects Theoretically, OpenStack Compute can support any database that SQL- Alchemy supports. Common databases are SQLite3 for test and development work, MySQL, and PostgreSQL. 7

18 Storage concepts The OpenStack stack uses the following storage types: Table 1.2. Storage types On-instance / ephemeral Block storage (cinder) Object Storage (swift) Runs operating systems and provides scratch space Used for adding additional persistent storage to a virtual machine (VM) Used for storing virtual machine images and data Persists until VM is terminated Persists until deleted Persists until deleted Access associated with a VM Access associated with a VM Available from anywhere Implemented as a filesystem underlying OpenStack Compute Administrator configures size setting, based on flavors Example: 10 GB first disk, 30 GB/core second disk Mounted via OpenStack Block Storage controlled protocol (for example, iscsi) Sizings based on need Example: 1 TB "extra hard drive" REST API Easily scalable for future growth Example: 10s of TBs of data set storage You should note that: You cannot use OpenStack Object Storage like a traditional hard drive. The Object Storage relaxes some of the constraints of a POSIX-style file system to get other gains. You can access the objects through an API which uses HTTP. Subsequently you don't have to provide atomic operations (that is, relying on eventual consistency), you can scale a storage system easily and avoid a central point of failure. The OpenStack Image service is used to manage the virtual machine images in an Open- Stack cluster, not store them. It provides an abstraction to different methods for storage - a bridge to the storage, not the storage itself. The OpenStack Object Storage can function on its own. The Object Storage (swift) product can be used independently of the Compute (nova) product. Command-line clients and other interfaces swift client swift-init Enables users to submit commands to the REST API through a command-line client authorized as either a admin user, reseller user, or swift user. Script that initializes the building of the ring file, takes daemon names as parameter and offers commands. Documented in admin_guide.html#managing-services. swift-recon swift-ring-builder Storage ring build and rebalance utility. Documented in admin_guide.html#managing-the-rings. 8

19 OpenStack Object Storage The OpenStack Object Storage is a multi-tenant object storage system. It is highly scalable and can manage large amounts of unstructured data at low cost through a RESTful HTTP API. It includes the following components: Proxy servers (swift-proxyserver) Account servers (swift-account-server) Container servers (swiftcontainer-server) Object servers (swift-object-server) Various periodic processes WSGI middleware Accepts OpenStack Object Storage API and raw HTTP requests to upload files, modify metadata, and create containers. It also serves file or container listings to web browsers. To improve performance, the proxy server can use an optional cache that is usually deployed with memcache. Manages accounts defined with Object Storage. Manages the mapping of containers or folders, within Object Storage. Manages actual objects,such as files, on the storage nodes. Performs housekeeping tasks on the large data store. The replication services ensure consistency and availability through the cluster. Other periodic processes include auditors, updaters, and reapers. Handles authentication and is usually OpenStack Identity. OpenStack Block Storage The OpenStack Block Storage service (cinder) adds persistent storage to a virtual machine. Block Storage provides an infrastructure for managing volumes, and interacts with Open- Stack Compute to provide volumes for instances. The service also enables management of volume snapshots, and volume types. The Block Storage service consists of the following components: cinder-api cinder-volume Accepts API requests, and routes them to the cinder-volume for action. Interacts directly with the Block Storage service, and processes such as the cinder-scheduler. It also interacts with these processes through a message queue. The cinder-volume service responds to read and write requests sent to the Block Storage service to maintain state. It can interact with a variety of storage providers through a driver architecture. 9

20 cinder-scheduler daemon cinder-backup daemon Messaging queue Selects the optimal storage provider node on which to create the volume. A similar component to the nova-scheduler. The cinder-backup service provides backing up volumes of any type to a backup storage provider. Like the cinder-volume service, it can interact with a variety of storage providers through a driver architecture. Routes information between the Block Storage processes. 10

21 OpenStack Networking OpenStack Networking allows you to create and attach interface devices managed by other OpenStack services to networks. Plug-ins can be implemented to accommodate different networking equipment and software, providing flexibility to OpenStack architecture and deployment. It includes the following components: neutron-server OpenStack Networking plug-ins and agents Accepts and routes API requests to the appropriate OpenStack Networking plug-in for action. Plugs and unplugs ports, creates networks or subnets, and provides IP addressing. These plug-ins and agents differ depending on the vendor and technologies used in the particular cloud. OpenStack Networking ships with plug-ins and agents for Cisco virtual and physical switches, NEC OpenFlow products, Open vswitch, Linux bridging, and the VMware NSX product. The common agents are L3 (layer 3), DHCP (dynamic host IP addressing), and a plug-in agent. Messaging queue Used by most OpenStack Networking installations to route information between the neutron-server and various agents, as well as a database to store networking state for particular plug-ins. OpenStack Networking mainly interacts with OpenStack Compute to provide networks and connectivity for its instances. 11

22 OpenStack dashboard The OpenStack dashboard is a modular Django web application that provides a graphical interface to OpenStack services. The dashboard is usually deployed through mod_wsgi in Apache. You can modify the dashboard code to make it suitable for different sites. From a network architecture point of view, this service must be accessible to customers and the public API for each OpenStack service. To use the administrator functionality for other services, it must also connect to Admin API endpoints, which should not be accessible by customers. OpenStack Identity concepts The OpenStackIdentity Service performs the following functions: Tracking users and their permissions. Providing a catalog of available services with their API endpoints. When installing OpenStack Identity service, you must register each service in your Open- Stack installation. Identity service can then track which OpenStack services are installed, and where they are located on the network. To understand OpenStack Identity, you must understand the following concepts: User Credentials Digital representation of a person, system, or service who uses OpenStack cloud services. The Identity service validates that incoming requests are made by the user who claims to be making the call. Users have a login and may be assigned tokens to access resources. Users can be directly assigned to a particular tenant and behave as if they are contained in that tenant. Data that confirms the user's identity. For example: user name and password, user name and API key, or an authentication token provided by the Identity Service. 12

23 Authentication The process of confirming the identity of a user. OpenStack Identity confirms an incoming request by validating a set of credentials supplied by the user. These credentials are initially a user name and password, or a user name and API key. When user credentials are validated, OpenStack Identity issues an authentication token which the user provides in subsequent requests. Token An alpha-numeric string of text used to access OpenStack APIs and resources. A token may be revoked at any time and is valid for a finite duration. While OpenStack Identity supports token-based authentication in this release, the intention is to support additional protocols in the future. Its main purpose is to be an integration service, and not aspire to be a full-fledged identity store and management solution. Tenant Service Endpoint Role A container used to group or isolate resources. Tenants also group or isolate identity objects. Depending on the service operator, a tenant may map to a customer, account, organization, or project. An OpenStack service, such as Compute (nova), Object Storage (swift), or Image service (glance). It provides one or more endpoints in which users can access resources and perform operations. A network-accessible address where you access a service, usually a URL address. If you are using an extension for templates, an endpoint template can be created, which represents the templates of all the consumable services that are available across the regions. A personality with a defined set of user rights and privileges to perform a specific set of operations. In the Identity service, a token that is issued to a user includes the list of roles. Services that are being called by that user determine how they interpret the set of roles a user has and to which operations or resources each role grants access. Keystone Client A command line interface for the OpenStack Identity API. For example, users can run the keystone service-create and keystone endpoint-create commands to register services in their OpenStack installations. The following diagram shows the OpenStack Identity process flow: 13

24 14

25 OpenStack Image service The OpenStack Image service is central to Infrastructure-as-a-Service (IaaS) as shown in the section called Conceptual architecture [2]. It accepts API requests for disk or server images, and image metadata from end users or OpenStack Compute components. It also supports the storage of disk or server images on various repository types, including OpenStack Object Storage. A number of periodic processes run on the OpenStack Image service to support caching. Replication services ensure consistency and availability through the cluster. Other periodic processes include auditors, updaters, and reapers. The OpenStack Image service includes the following components: glance-api glance-registry Accepts Image API calls for image discovery, retrieval, and storage. Stores, processes, and retrieves metadata about images. Metadata includes items such as size and type. Security note The registry is a private internal service meant for use by OpenStack Image service. Do not disclose it to users. Database Storage repository for image files Telemetry module Stores image metadata and you can choose your database depending on your preference. Most deployments use MySQL or SQLite. Various repository types are supported including normal file systems, Object Storage, RADOS block devices, HTTP, and Amazon S3. Note that some repositories will only support read-only usage. The Telemetry module performs the following functions: Efficiently polls metering data related to OpenStack services. Collects event and metering data by monitoring notifications sent from services. Publishes collected data to various targets including data stores and message queues. Creates alarms when collected data breaks defined rules. The Telemetry module consists of the following components: A compute agent (ceilometer-agent-compute) Runs on each compute node and polls for resource utilization statistics. There may be other types of agents in the future, but for now our focus is creating the compute agent. 15

26 A central agent (ceilometer-agent-central) A notification agent (ceilometer-agent-notification) A collector (ceilometer-collector) An alarm evaluator (ceilometer-alarm-evaluator) An alarm notifier (ceilometer-alarm-notifier) An API server (ceilometer-api) Runs on a central management server to poll for resource utilization statistics for resources not tied to instances or compute nodes. Multiple agents can be started to scale service horizontally. Runs on a central management server(s) and consumes messages from the message queue(s) to build event and metering data. Runs on central management server(s) and dispatches collected telemetry data to a data store or external consumer without modification. Runs on one or more central management servers to determine when alarms fire due to the associated statistic trend crossing a threshold over a sliding time window. Runs on one or more central management servers to allow alarms to be set based on the threshold evaluation for a collection of samples. Runs on one or more central management servers to provide data access from the data store. These services communicate by using the OpenStack messaging bus. Only the collector and API server have access to the data store. Orchestration module concepts The Orchestration module provides a template-based orchestration for describing a cloud application, by running OpenStack API calls to generate running cloud applications. The software integrates other core components of OpenStack into a one-file template system. The templates allow you to create most OpenStack resource types, such as instances, floating IPs, volumes, security groups and users. It also provides advanced functionality, such as instance high availability, instance auto-scaling, and nested stacks. This enables OpenStack core projects to receive a larger user base. The service enables deployers to integrate with the Orchestration module directly or through custom plug-ins. The Orchestration module consists of the following components: heat command-line client heat-api component heat-api-cfn component A CLI that communicates with the heat-api to run AWS CloudFormation APIs. End developers can directly use the Orchestration REST API. An OpenStack-native REST API that processes API requests by sending them to the heat-engine over Remote Procedure Call (RPC). An AWS Query API that is compatible with AWS Cloud- Formation. It processes API requests by sending them to the heat-engine over RPC. 16

27 heat-engine Orchestrates the launching of templates and provides events back to the API consumer. Database service overview The Database service provides scalable and reliable cloud provisioning functionality for both relational and non-relational database engines. Users can quickly and easily use database features without the burden of handling complex administrative tasks. Cloud users and database administrators can provision and manage multiple database instances as needed. The Database service provides resource isolation at high performance levels, and automates complex administrative tasks such as deployment, configuration, patching, backups, restores, and monitoring. This example is a high-level process flow for using Database ser- Process flow example. vices: 1. The OpenStack Administrator configures the basic infrastructure using the following steps: a. Install the Database service. b. Create an image for each type of database. For example, one for MySQL and one for MongoDB. c. Use the trove-manage command to import images and offer them to tenants. 2. The OpenStack end user deploys the Database service using the following steps: a. Create a Database service instance using the trove create command. b. Use the trove list command to get the ID of the instance, followed by the trove show command to get the IP address of it. c. Access the Database service instance using typical database access commands. For example, with MySQL: $ mysql -u myuser -p -h TROVE_IP_ADDRESS mydb The Database service includes the following components: python-troveclient command-line client trove-api component trove-conductor service trove-taskmanager service A CLI that communicates with the trove-api component. Provides an OpenStack-native RESTful API that supports JSON to provision and manage Trove instances. Runs on the host, and receives messages from guest instances that want to update information on the host. Instruments the complex system flows that support provisioning instances, managing the lifecycle of instances, and performing operations on instances. 17

28 trove-guestagent service Data processing service Runs within the guest instance. Manages and performs operations on the database itself. The Data processing service for OpenStack (sahara) aims to provide users with a simple means to provision data processing (Hadoop, Spark) clusters by specifying several parameters like Hadoop version, cluster topology, node hardware details and a few more. After a user fills in all the parameters, the Data processing service deploys the cluster in a few minutes. Sahara also provides a means to scale already provisioned clusters by adding/removing worker nodes on demand. The solution addresses the following use cases: Fast provisioning of Hadoop clusters on OpenStack for development and QA. Utilization of unused compute power from general purpose OpenStack IaaS cloud. Analytics-as-a-Service for ad-hoc or bursty analytic workloads. Key features are: Feedback Designed as an OpenStack component. Managed through REST API with UI available as part of OpenStack dashboard. Support for different Hadoop distributions: Pluggable system of Hadoop installation engines. Integration with vendor specific management tools, such as Apache Ambari or Cloudera Management Console. Predefined templates of Hadoop configurations with the ability to modify parameters. User-friendly UI for ad-hoc analytics queries based on Hive or Pig. To provide feedback on documentation, join and use the <openstack-docs@lists.openstack.org> mailing list at OpenStack Documentation Mailing List, or report a bug. 18

29 2. Identity management Table of Contents Identity concepts Certificates for PKI Configure the Identity Service with SSL External authentication with Identity Integrate Identity with LDAP Configure Identity service for token binding Use trusts Caching layer User CRUD Logging Start the Identity services Example usage Authentication middleware with user name and password Identity API protection with role-based access control (RBAC) Troubleshoot the Identity service OpenStack Identity, code-named keystone, is the default identity management system for OpenStack. After you install Identity, you configure it through the etc/keystone.conf configuration file and, possibly, a separate logging configuration file. You initialize data into Identity by using the keystone command-line client. Identity concepts User management The main components of Identity user management are: User. Represents a human user. Has associated information such as user name, password, and . This example creates a user named alice: $ openstack user create --password-prompt -- alice@example.com alice Project. A tenant, group, or organization. When you make requests to OpenStack services, you must specify a project. For example, if you query the Compute service for a list of running instances, you get a list of all running instances in the project that you specified in your query. This example creates a project named acme: $ openstack project create acme Domain. Defines administrative boundaries for the management of Identity entities. A domain may represent an individual, company, or operator-owned space. It is used for exposing administrative activities directly to the system users. A domain is a collection of projects and users. Users may be given a domain's administrator role. A domain administrator may create projects, users, and groups within a domain and assign roles to users and groups. 19

30 This example creates a domain named emea: $ openstack domain create emea Role. Captures the operations that a user can perform in a given tenant. This example creates a role named compute-user: $ openstack role create compute-user Note Individual services, such as Compute and the Image service, assign meaning to roles. In the Identity Service, a role is simply a name. 20

31 The Identity Service assigns a tenant and a role to a user. You might assign the compute-user role to the alice user in the acme tenant: $ openstack user list ID Name alice $ openstack role list ID Name a764e compute-user $ openstack project list ID Name b8fd2 acme $ openstack role add --project 6b8fd2 --user a764e A user can have different roles in different tenants. For example, Alice might also have the admin role in the Cyberdyne tenant. A user can also have multiple roles in the same tenant. The /etc/[service_codename]/policy.json file controls the tasks that users can perform for a given service. For example, /etc/nova/policy.json specifies the access policy for the Compute service, /etc/glance/policy.json specifies the access policy for the Image service, and /etc/keystone/policy.json specifies the access policy for the Identity Service. The default policy.json files in the Compute, Identity, and Image service recognize only the admin role: all operations that do not require the admin role are accessible by any user that has any role in a tenant. If you wish to restrict users from performing operations in, say, the Compute service, you need to create a role in the Identity Service and then modify /etc/nova/policy.json so that this role is required for Compute operations. 21

32 For example, this line in /etc/nova/policy.json specifies that there are no restrictions on which users can create volumes: if the user has any role in a tenant, they can create volumes in that tenant. "volume:create": "", To restrict creation of volumes to users who had the compute-user role in a particular tenant, you would add "role:compute-user", like so: "volume:create": "role:compute-user", To restrict all Compute service requests to require this role, the resulting file would look like: { "admin_or_owner": "role:admin or project_id:%(project_id)s", "default": "rule:admin_or_owner", "compute:create": "role:compute-user", "compute:create:attach_network": "role:compute-user", "compute:create:attach_volume": "role:compute-user", "compute:get_all": "role:compute-user", "compute:unlock_override": "rule:admin_api", "admin_api": "role:admin", "compute_extension:accounts": "rule:admin_api", "compute_extension:admin_actions": "rule:admin_api", "compute_extension:admin_actions:pause": "rule:admin_or_owner", "compute_extension:admin_actions:unpause": "rule:admin_or_owner", "compute_extension:admin_actions:suspend": "rule:admin_or_owner", "compute_extension:admin_actions:resume": "rule:admin_or_owner", "compute_extension:admin_actions:lock": "rule:admin_or_owner", "compute_extension:admin_actions:unlock": "rule:admin_or_owner", "compute_extension:admin_actions:resetnetwork": "rule:admin_api", "compute_extension:admin_actions:injectnetworkinfo": "rule:admin_api", "compute_extension:admin_actions:createbackup": "rule:admin_or_owner", "compute_extension:admin_actions:migratelive": "rule:admin_api", "compute_extension:admin_actions:migrate": "rule:admin_api", "compute_extension:aggregates": "rule:admin_api", "compute_extension:certificates": "role:compute-user", "compute_extension:cloudpipe": "rule:admin_api", "compute_extension:console_output": "role:compute-user", "compute_extension:consoles": "role:compute-user", "compute_extension:createserverext": "role:compute-user", "compute_extension:deferred_delete": "role:compute-user", "compute_extension:disk_config": "role:compute-user", "compute_extension:evacuate": "rule:admin_api", "compute_extension:extended_server_attributes": "rule:admin_api", "compute_extension:extended_status": "role:compute-user", "compute_extension:flavorextradata": "role:compute-user", "compute_extension:flavorextraspecs": "role:compute-user", "compute_extension:flavormanage": "rule:admin_api", "compute_extension:floating_ip_dns": "role:compute-user", "compute_extension:floating_ip_pools": "role:compute-user", "compute_extension:floating_ips": "role:compute-user", "compute_extension:hosts": "rule:admin_api", "compute_extension:keypairs": "role:compute-user", "compute_extension:multinic": "role:compute-user", "compute_extension:networks": "rule:admin_api", "compute_extension:quotas": "role:compute-user", "compute_extension:rescue": "role:compute-user", "compute_extension:security_groups": "role:compute-user", 22

33 } "compute_extension:server_action_list": "rule:admin_api", "compute_extension:server_diagnostics": "rule:admin_api", "compute_extension:simple_tenant_usage:show": "rule:admin_or_owner", "compute_extension:simple_tenant_usage:list": "rule:admin_api", "compute_extension:users": "rule:admin_api", "compute_extension:virtual_interfaces": "role:compute-user", "compute_extension:virtual_storage_arrays": "role:compute-user", "compute_extension:volumes": "role:compute-user", "compute_extension:volume_attachments:index": "role:compute-user", "compute_extension:volume_attachments:show": "role:compute-user", "compute_extension:volume_attachments:create": "role:compute-user", "compute_extension:volume_attachments:delete": "role:compute-user", "compute_extension:volumetypes": "role:compute-user", "volume:create": "role:compute-user", "volume:get_all": "role:compute-user", "volume:get_volume_metadata": "role:compute-user", "volume:get_snapshot": "role:compute-user", "volume:get_all_snapshots": "role:compute-user", "network:get_all_networks": "role:compute-user", "network:get_network": "role:compute-user", "network:delete_network": "role:compute-user", "network:disassociate_network": "role:compute-user", "network:get_vifs_by_instance": "role:compute-user", "network:allocate_for_instance": "role:compute-user", "network:deallocate_for_instance": "role:compute-user", "network:validate_networks": "role:compute-user", "network:get_instance_uuids_by_ip_filter": "role:compute-user", "network:get_floating_ip": "role:compute-user", "network:get_floating_ip_pools": "role:compute-user", "network:get_floating_ip_by_address": "role:compute-user", "network:get_floating_ips_by_project": "role:compute-user", "network:get_floating_ips_by_fixed_address": "role:compute-user", "network:allocate_floating_ip": "role:compute-user", "network:deallocate_floating_ip": "role:compute-user", "network:associate_floating_ip": "role:compute-user", "network:disassociate_floating_ip": "role:compute-user", "network:get_fixed_ip": "role:compute-user", "network:add_fixed_ip_to_instance": "role:compute-user", "network:remove_fixed_ip_from_instance": "role:compute-user", "network:add_network_to_project": "role:compute-user", "network:get_instance_nw_info": "role:compute-user", "network:get_dns_domains": "role:compute-user", "network:add_dns_entry": "role:compute-user", "network:modify_dns_entry": "role:compute-user", "network:delete_dns_entry": "role:compute-user", "network:get_dns_entries_by_address": "role:compute-user", "network:get_dns_entries_by_name": "role:compute-user", "network:create_private_dns_domain": "role:compute-user", "network:create_public_dns_domain": "role:compute-user", "network:delete_dns_domain": "role:compute-user" Service management The Identity Service provides identity, token, catalog, and policy services. It consists of: keystone Web Server Gateway Interface (WSGI) service. Can be run in a WSGI-capable web server such as Apache httpd to provide the Identity Service. The service and administrative APIs are run as separate instances of the WSGI service. 23

34 Groups Identity Service functions. Each has a pluggable back end that allows different ways to use the particular service. Most support standard back ends like LDAP or SQL. keystone-all. Starts both the service and administrative APIs in a single process. Using federation with keystone-all is not supported. keystone-all is deprecated in favor of the WSGI service. The Identity Service also maintains a user that corresponds to each service, such as, a user named nova for the Compute service, and a special service tenant called service. For information about how to create services and endpoints, see the OpenStack Admin User Guide. A group is a collection of users. Administrators can create groups and add users to them. Then, rather than assign a role to each user individually, assign a role to the group. Every group is in a domain. Groups were introduced with the Identity API v3. Identity API V3 provides the following group-related operations: Create a group Delete a group Update a group (change its name or description) Add a user to a group Remove a user from a group List group members List groups for a user Assign a role on a tenant to a group Assign a role on a domain to a group Query role assignments to groups Note The Identity service server might not allow all operations. For example, if using the Identity server with the LDAP Identity back end and group updates are disabled, then a request to create, delete, or update a group fails. Here are a couple of examples: Group A is granted Role A on Tenant A. If User A is a member of Group A, when User A gets a token scoped to Tenant A, the token also includes Role A. Group B is granted Role B on Domain B. If User B is a member of Domain B, if User B gets a token scoped to Domain B, the token also includes Role B. 24

35 Certificates for PKI PKI stands for Public Key Infrastructure. Tokens are documents, cryptographically signed using the X509 standard. In order to work correctly token generation requires a public/private key pair. The public key must be signed in an X509 certificate, and the certificate used to sign it must be available as a Certificate Authority (CA) certificate. These files can be generated either using the keystone-manage utility, or externally generated. The files need to be in the locations specified by the top level Identity Service configuration file keystone.conf as specified in the above section. Additionally, the private key should only be readable by the system user that will run the Identity Service. Warning The certificates can be world readable, but the private key cannot be. The private key should only be readable by the account that is going to sign tokens. When generating files with the keystone-manage pki_setup command, your best option is to run as the pki user. If you run keystone-manage as root, you can append --keystone-user and --keystone-group parameters to set the user name and group keystone is going to run under. The values that specify where to read the certificates are under the [signing] section of the configuration file. The configuration values are: certfile - Location of certificate used to verify tokens. Default is /etc/keystone/ssl/certs/signing_cert.pem. keyfile - Location of private key used to sign tokens. Default is /etc/keystone/ssl/private/signing_key.pem. ca_certs - Location of certificate for the authority that issued the above certificate. Default is /etc/keystone/ssl/certs/ca.pem. ca_key - Location of the private key used by the CA. Default is /etc/keystone/ssl/ private/cakey.pem. key_size - Default is valid_days - Default is cert_subject - Certificate subject (auto generated certificate) for token signing. Default is /C=US/ST=Unset/L=Unset/O=Unset/CN= When generating certificates with the keystone-manage pki_setup command, the ca_key, key_size, and valid_days configuration options are used. If the keystone-manage pki_setup command is not used to generate certificates, or you are providing your own certificates, these values do not need to be set. If provider=keystone.token.providers.uuid.provider in the [token] section of the keystone configuration, a typical token looks like 53f7f6ef0cc344b5be706bcc8b1479e1. If provider=keystone.token.providers.pki.provider, a typical token is a much longer string, such as: 25