154 lines
11 KiB
XML
154 lines
11 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch014_best-practices-for-operator-mode-access"><?dbhtml stop-chunking?>
|
||
<title>Management Interfaces</title>
|
||
<para>It is necessary for administrators to perform command and control over the cloud for various operational functions. It is important these command and control facilities are understood and secured.</para>
|
||
<para>OpenStack provides several management interfaces for operators and tenants:</para>
|
||
<itemizedlist><listitem>
|
||
<para>OpenStack Dashboard (Horizon)</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>OpenStack API</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Secure Shell (SSH)</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>OpenStack Management Utilities (nova-manage, glance-manage, etc.)</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Out-of-Band Management Interfaces (IPMI, etc.)</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp49280">
|
||
<title>Dashboard</title>
|
||
<para>The OpenStack Dashboard (Horizon) provides administrators and tenants a web-based graphical interface to provision and access cloud-based resources. The dashboard communicates with the back-end services via calls to the OpenStack API (discussed above).</para>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp50608">
|
||
<title>Capabilities</title>
|
||
<itemizedlist><listitem>
|
||
<para>As a cloud administrator, the dashboard provides an overall view of the size and state of your cloud. You can create users and tenants/projects, assign users to tenant/projects and set limits on the resources available for them.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>The dashboard provides tenant-users a self-service portal to provision their own resources within the limits set by administrators.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>The dashboard provides GUI support for routers and load-balancers. For example, the dashboard now implements all of the main Networking features.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>It is an extensible <glossterm>Django</glossterm> web application that allows easy plug-in of third-party products and services, such as billing, monitoring, and additional management tools.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>The dashboard can also be branded for service providers and other commercial vendors.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</section>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp56400">
|
||
<title>Security Considerations</title>
|
||
<itemizedlist><listitem>
|
||
<para>The dashboard requires cookies and JavaScript to be enabled in the web browser.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>The web server that hosts dashboard should be configured for SSL to ensure data is encrypted.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Both the Horizon web service and the OpenStack API it uses to communicate with the back-end are susceptible to web attack vectors such as denial of service and must be monitored.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>It is now possible (though there are numerous deployment/security implications) to upload an image file directly from a user’s hard disk to Glance through Horizon. For multi-GB images it is still strongly recommended that the upload be done using the Glance CLI</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Create and manage security groups through dashboard. The security groups allows L3-L4 packet filtering for security policies to protect virtual machines</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</section>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp62384">
|
||
<title>References</title>
|
||
<para><link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly"><citetitle>Grizzly Release Notes</citetitle></link></para>
|
||
</section>
|
||
</section>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp63760">
|
||
<title>OpenStack API</title>
|
||
<para>The OpenStack API is a RESTful web service endpoint to access, provision and automate cloud-based resources. Operators and users typically access the API through command-line utilities (i.e. Nova, Glance, etc.), language-specific libraries, or third-party tools.</para>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp65328">
|
||
<title>Capabilities</title>
|
||
<itemizedlist><listitem>
|
||
<para>To the cloud administrator the API provides an overall view of the size and state of the cloud deployment and allows the creation of users, tenants/projects, assigning users to tenants/projects and specifying resource quotas on a per tenant/project basis.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>The API provides a tenant interface for provisioning, managing, and accessing their resources.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</section>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp68272">
|
||
<title>Security Considerations</title>
|
||
<itemizedlist><listitem>
|
||
<para>The API service should be configured for SSL to ensure data is encrypted.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>As a web service, OpenStack API is susceptible to familiar web site attack vectors such as denial of service attacks.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</section>
|
||
</section>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp71184">
|
||
<title>Secure Shell (SSH)</title>
|
||
<para>It has become industry practice to use secure shell (SSH) access for the management of Linux and Unix systems. SSH uses secure cryptographic primitives for communication. With the scope and importance of SSH in typical OpenStack deployments, it is important to understand best practices for deploying SSH.</para>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp72528">
|
||
<title>Host Key Fingerprints</title>
|
||
<para>Often overlooked is the need for key management for SSH hosts. As most or all hosts in an OpenStack deployment will provide an SSH service, it is important to have confidence in connections to these hosts. It cannot be understated that failing to provide a reasonably secure and accessible method to verify SSH host key fingerprints is ripe for abuse and exploitation.</para>
|
||
<para>All SSH daemons have private host keys and, upon connection, offer a host key fingerprint. This host key fingerprint is the hash of an unsigned public key. It is important these host key fingerprints are known in advance of making SSH connections to those hosts. Verification of host key fingerprints is instrumental in detecting man-in-the-middle attacks.</para>
|
||
<para>Typically, when an SSH daemon is installed, host keys will be generated. It is necessary that the hosts have sufficient entropy during host key generation. Insufficient entropy during host key generation can result in the possibility to eavesdrop on SSH sessions.</para>
|
||
<para>Once the SSH host key is generated, the host key fingerprint should be stored in a secure and queriable location. One particularly convenient solution is DNS using SSHFP resource records as defined in RFC-4255. For this to be secure, it is necessary that DNSSEC be deployed.</para>
|
||
</section>
|
||
</section>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp76272">
|
||
<title>Management Utilities</title>
|
||
<para>The OpenStack Management Utilities are open-source Python
|
||
command-line clients that make API calls. There is a client for
|
||
each OpenStack service (nova, glance, etc.). In addition to the
|
||
standard CLI client, most of the services have a management
|
||
command line which makes direct calls to the database. These
|
||
dedicated management utilities are slowly being
|
||
deprecated.</para>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp77728">
|
||
<title>Security Considerations</title>
|
||
<itemizedlist><listitem>
|
||
<para>The dedicated management utilities (*-manage) in some cases use the direct database connection.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Ensure that the .rc file which has your credential information is secured.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</section>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp80496">
|
||
<title>References</title>
|
||
<para><citetitle>OpenStack End User Guide</citetitle> section <link xlink:href="http://docs.openstack.org/user-guide/content/section_cli_overview.html">command line clients overview</link></para>
|
||
<para><citetitle>OpenStack End User Guide</citetitle> section <link xlink:href="http://docs.openstack.org/user-guide/content/cli_openrc.html">Download and source the OpenStack RC file</link></para>
|
||
</section>
|
||
</section>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp82336">
|
||
<title>Out-of-Band Management Interface</title>
|
||
<para>OpenStack management relies on out-of-band management interfaces such as the IPMI protocol to access into nodes running OpenStack components. IPMI is a very popular specification to remotely manage, diagnose and reboot servers whether the operating system is running or the system has crashed.</para>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp83712">
|
||
<title>Security Considerations</title>
|
||
<itemizedlist><listitem>
|
||
<para>Use strong passwords and safeguard them, or use client-side SSL authentication.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Ensure that the network interfaces are on their own private(management or a separate) network. Segregate management domains with firewalls or other network gear.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>If you use a web interface to interact with the <glossterm>BMC</glossterm>/IPMI, always use the SSL interface (e.g. https or port 443). This SSL interface should <emphasis role="bold">NOT</emphasis> use self-signed certificates, as is often default, but should have trusted certificates using the correctly defined fully qualified domain names (FQDNs).</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Monitor the traffic on the management network. The anomalies may be easier to track than on the busier compute nodes</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<para>Out of band management interfaces also often include graphical machine console access. It is often possible, although not necessarily default, that these interfaces are encrypted. Consult with your system software documentation for encrypting these interfaces.</para>
|
||
</section>
|
||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp89920">
|
||
<title>References</title>
|
||
<para><link xlink:href="https://isc.sans.edu/diary/IPMI%3A+Hacking+servers+that+are+turned+%22off%22/13399">Hacking servers that are turned off</link></para>
|
||
</section>
|
||
</section>
|
||
</chapter>
|