openstack-manuals/doc/security-guide/ch014_best-practices-for-operator-mode-access.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 (for example,
        <systemitem class="service">nova-manage</systemitem>,
        <systemitem class="service">glance-manage</systemitem>)</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 OpenStack Image Service through the dashboard. 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 (for example, <command>nova</command> or
      <command>glance</command>), 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 (for example, <systemitem
      class="service">nova</systemitem>, <systemitem
      class="service">glance</systemitem>). In addition to the
      standard CLI client, most of the services have a management
      command-line utility 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, such as 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 might 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>