Configuration and Credentials

Download this manual as a PDF file

The following sections describe how to configure OpenStack resources for monitoring by SL1 using the OpenStack PowerPack:

Configuring OpenStack for Monitoring

To discover OpenStack resources for monitoring by SL1, you must create a SOAP/XML credential that includes authentication information for an OpenStack user.

The user whose information is used in this credential can be either an administrator or a regular (non-administrator) user. Administrator credentials enable SL1 to discover an OpenStack domain and resource pool; regular user credentials enable SL1 to discover only a single project within a specified domain and those components that the user has permissions for in the policy files. The recommended policy edits described in the Adding the User Role to API Policy Endpoints section will enable non-administrator users to discover resource pools.

The following sections describe how to assign a role to an OpenStack user and then add that user role to the appropriate API policy endpoints.

Prerequisites for Monitoring OpenStack

Before completing the following sections, you must have already created the OpenStack domain and projects you want to monitor, the user whose information you will include in the SOAP/XML credential, and the role you want to assign to that user.

ScienceLogic recommends that you create a new user role that will be used only for ScienceLogic monitoring and then add this ScienceLogic-specific user role to the policy endpoints described in the Adding the User Role to API Policy Endpoints section. Having a ScienceLogic-specific user role makes it easier to manage the role's policy permissions without having to change any of your existing user roles.

Assigning a Role to a User

After you have created the user whose information you will include in the SOAP/XML credential, you must assign that user a role in a specific project. This can be done either in the OpenStack portal or using the OpenStackClient command line interface. Both methods are described in this section.

Method 1: OpenStack Portal

To assign the user a role using the OpenStack portal:

  1. Log in to the OpenStack portal and navigate to the Projects page (Identity > Projects).

  1. Locate the project you want to monitor. In the Actions column, click Manage Members.
  2. If the user whose information you will include in the SOAP/XML credential does not already appear in the Project Members list, locate the user in the All Users list and click the plus (+) icon for that user.
  3. Locate the user in the Project Members list and use the drop-down menu next to the user's name to select the user's role.
  4. Click Save.

Method 2: Command Line Interface

To add a role to the user in a project using the OpenStackClient (OSC) command line interface, SSH into OSC and then use the following command format:

openstack role add <role name> --project <project name> user <username>

Adding the User Role to API Policy Endpoints

After you have assigned the user a role, you must add the user's assigned role to endpoints in the following OpenStack API policies:

  • Keystone (identity services)
  • Nova (compute services)
  • Neutron (networking services)
  • Cinder (block storage services)

For example, to allow a user to list OpenStack projects, Keystone's policy.json file needs to include the following rule:

"identity:list_projects" : "role: <user-role>"

A rule can also contain multiple roles by using the "or" syntax. For example:

"identity:list_projects" : "role: <user-role-1> or role: <user-role-2>"

By default, a role can be any of the following:

  • admin
  • user
  • member

Policy Permissions for Administrators

For administrator users, you must update the following policies:

Keystone Policy

An administrator user defined in the SOAP/XML credential needs permissions to the following endpoints defined in /etc/keystone/policy.json:

  • identity:get_region

  • identity:list_regions
  • identity:get_endpoint
  • identity:list_endpoints
  • identity:get_domain
  • identity:list_domains
  • identity:get_project
  • identity:list_projects

Nova Policy

An administrator user defined in the SOAP/XML credential needs permissions to the following endpoints defined in /etc/nova/policy.json:

  • os_compute_api:os-aggregates:index

  • os_compute_api:os-aggregates:show
  • os_compute_api:os-extended-server-attributes
  • os_compute_api:flavors
  • os_compute_api:os-hosts
  • os_compute_api:os-hypervisors
  • os_compute_api:limits
  • os_compute_api:os-networks
  • os_compute_api:os-networks:view
  • os_compute_api:os-networks-associate
  • os_compute_api:os-security-group-default-rules
  • os_compute_api:os-security-groups
  • os_compute_api:os-server-diagnostics
  • os_compute_api:os-server-groups
  • os_compute_api:os-server-usage
  • os_compute_api:servers:detail
  • os_compute_api:servers:index:get_all_tenants
  • os_compute_api:servers:detail:get_all_tenants
  • os_compute_api:servers:show
  • os_compute_api:servers:show:host_status
  • os_compute_api:os-services
  • os_compute_api:os-simple-tenant-usage:show
  • os_compute_api:os-simple-tenant-usage:list
  • os_compute_api:os-tenant-networks
  • os_compute_api:os-virtual-interfaces
  • os_compute_api:os-volumes
  • os_compute_api:os-volumes-attachments:show

Neutron Policy

An administrator user defined in the SOAP/XML credential needs permissions to the following endpoints defined in /etc/neutron/policy.json:

  • get_subnet

  • get_subnet:segment_id
  • get_subnetpool
  • get_address_scope
  • get_network
  • get_network:router:external
  • get_network:segments
  • get_network:provider:network_type
  • get_network:provider:physical_network
  • get_network:provider:segmentation_id
  • get_network:queue_id
  • get_network_ip_availabilities
  • get_network_ip_availability
  • get_segment
  • get_port
  • get_port:queue_id
  • get_router
  • get_router:distributed
  • get_router:ha
  • get_dhcp-networks
  • get_l3-routers
  • get_network_profiles
  • get_network_profile
  • get_flavors
  • get_flavor

Cinder Policy

An administrator user defined in the SOAP/XML credential needs permission to the following endpoint defined in /etc/cinder/policy.json:

  • volume_extension:services:index

Policy Permissions for Non-Administrator Users

For regular (non-administrator) users, you must update the following policies:

Keystone Policy

A regular user defined in the SOAP/XML credential needs permissions to the following endpoints defined in /etc/keystone/policy.json:

  • identity:get_region

  • identity:list_regions
  • identity:get_endpoint
  • identity:list_endpoints
  • identity:get_domain
  • identity:list_domains
  • identity:get_project
  • identity:list_projects

Nova Policy

A regular user defined in the SOAP/XML credential needs permissions to the following endpoints defined in /etc/nova/policy.json:

  • os_compute_api:os-aggregates:index

  • os_compute_api:os-aggregates:show
  • os_compute_api:os-extended-server-attributes
  • os_compute_api:flavors
  • os_compute_api:os-hosts
  • os_compute_api:os-hypervisors
  • os_compute_api:limits
  • os_compute_api:os-networks
  • os_compute_api:os-networks:view
  • os_compute_api:os-networks-associate
  • os_compute_api:os-security-group-default-rules
  • os_compute_api:os-security-groups
  • os_compute_api:os-server-diagnostics
  • os_compute_api:os-server-groups
  • os_compute_api:os-server-usage
  • os_compute_api:servers:detail
  • os_compute_api:servers:index:get_all_tenants
  • os_compute_api:servers:detail:get_all_tenants
  • os_compute_api:servers:show
  • os_compute_api:servers:show:host_status
  • os_compute_api:os-services
  • os_compute_api:os-simple-tenant-usage:show
  • os_compute_api:os-simple-tenant-usage:list
  • os_compute_api:os-tenant-networks
  • os_compute_api:os-virtual-interfaces
  • os_compute_api:os-volumes
  • os_compute_api:os-volumes-attachments:show

Neutron Policy

A regular user defined in the SOAP/XML credential needs permissions to the following endpoints defined in /etc/neutron/policy.json:

  • get_subnet

  • get_subnet:segment_id
  • get_subnetpool
  • get_address_scope
  • get_network
  • get_network:router:external
  • get_network:segments
  • get_network:provider:network_type
  • get_network:provider:physical_network
  • get_network:provider:segmentation_id
  • get_network:queue_id
  • get_network_ip_availabilities
  • get_network_ip_availability
  • get_segment
  • get_port
  • get_port:queue_id
  • get_router
  • get_router:distributed
  • get_router:ha
  • get_dhcp-networks
  • get_l3-routers
  • get_network_profiles
  • get_network_profile
  • get_flavors
  • get_flavor

Creating a SOAP/XML Credential for OpenStack

To configure SL1 to monitor OpenStack, you must first create a SOAP/XML credential. This credential allows the Dynamic Applications in the OpenStack PowerPack to communicate with your OpenStack domain.

The PowerPack includes two example SOAP/XML credentials that you can edit for your own use:

  • OpenStack Admin - Example. This credential is for administrators and will discover all projects contained within the specified domain.
  • OpenStack User - Example. This credential is for regular (non-administrator) users and will discover a single project within a specified domain and those components that the user has permissions for in the policy files.

During discovery, SL1 discovers only those OpenStack components within the single domain that is specified in the SOAP/XML credential, regardless of whether the credential is for an administrator or a regular user. To discover multiple domains, you must create a separate credential for each domain, which results in each domain being discovered with its own separate dynamic component map. To load-balance multiple domains, ScienceLogic recommends discovering different domains on different Data Collectors or All-In-One Appliances.

To configure a SOAP/XML credential to access OpenStack:

  1. Go to the Credential Management page (System > Manage > Credentials).

  1. Locate the OpenStack Admin - Example or OpenStack User - Example credential, then click its wrench icon (). The Edit SOAP/XML Credential modal page appears.

  1. Complete the following fields:

Basic Settings

  • Profile Name. Type a name for the OpenStack credential.

  • Content Encoding. Select text/xml.
  • Method. Select POST.
  • HTTP Version. Select HTTP/1.1.
  • URL. Type "http://<IP Address>:<Port>", replacing <IP address> with the IP address or hostname of the OpenStack domain and replacing <Port> with the appropriate port number.
  • HTTP Auth User. Type the OpenStack username.
  • HTTP Auth Password. Type the OpenStack user's password.
  • Timeout (seconds). Type "120".

Proxy Settings

  • Hostname/IP. Leave this field blank.

  • Port. Type "0".
  • User. Leave this field blank.
  • Password. Leave this field blank.

CURL Options

  • CURL Options. Do not make any selections in this field.

SOAP Options

  • Embedded Password [%P]. Leave this field blank.

  • Embed Value [%1]. Type the OpenStack domain ID.
  • Embed Value [%2]. If you are creating a credential for a regular (non-administrator) user, type the OpenStack project name. Otherwise, leave this field blank.
  • Embed Value [%3]. Leave this field blank.
  • Embed Value [%4]. Leave this field blank.

HTTP Headers

  • HTTP Headers. Do not make any selections in this field.

  1. Click the Save As button.