Open Stack

Reviewed:  https://review.openstack.org/563719
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=8392c7f2656ae624877e3df539681c0a8f8b4926
Submitter: Zuul
Branch:    stable/ocata

commit 8392c7f2656ae624877e3df539681c0a8f8b4926
Author: Matt Riedemann <mriedem.os at gmail.com>
Date:   Fri Apr 13 13:44:33 2018 -0400

    Add policy rule to block image-backed servers with 0 root disk flavor
    
    This adds a new policy rule which defaults to behave in a
    backward compatible way, but will allow operators to enforce
    that servers created with a zero disk flavor must also be
    volume-backed servers.
    
    Allowing users to upload their own images and create image-backed
    servers on local disk with zero root disk size flavors can be
    potentially hazardous if the size of the image is unexpectedly
    large, since it can consume the local disk (or shared storage pool).
    
    It should be noted that disabling the new policy rule will
    result in a non-backward compatible API behavior change and no
    microversion is being introduced for this because enforcement via
    a new microversion would not close the security gap on any previous
    microversions.
    
    Related compute API reference and user documentation is updated
    to mention the policy rule along with a release note since
    this is tied to a security bug, which will be backported to stable
    branches.
    
    Conflicts:
          api-ref/source/parameters.yaml
          doc/source/admin/flavors2.rst
          nova/policies/servers.py
          nova/tests/functional/wsgi/test_servers.py
    
    NOTE(mriedem): The api-ref/source/parameters.yaml conflict is due
    to If646149efb7eec8c90bf7d07c39ff4c495349941 not being in Pike.
    The doc/source/admin/flavors2.rst conflict is due to the doc
    not being in Ocata - it was migrated from the central admin-guide
    in Ifa0039e270e54ea2fb58ab18ce6724e5e8e061a1.
    The nova/policies/servers.py conflict is due to two changes in Pike:
    I17b6ca6e17c777ae7d337bf70ec4774ffe5187a8 and
    I050c4f5f19aa79a682e076cc3e47eba597f272dd. The DocumentedRuleDefault
    class was added to oslo.policy starting in 1.21.1 in Pike which is
    newer than what stable/ocata supports in global-requirements so we
    can't use it in this backport.
    The nova/tests/functional/wsgi/test_servers.py conflict is due to
    Ifcaaf285c8f98a1d0e8bbbc87b2f57fbce057346 and
    I294c54e5a22dd6e5b226a4b00e7cd116813f0704 not being in Ocata.
    
    Change-Id: Id67e1285a0522474844de130c9263e11868f67fb
    Closes-Bug: #1739646
    (cherry picked from commit 763fd62464e9a0753e061171cc1fd826055bbc01)
    (cherry picked from commit 7bcd581c78bb5916bf4b52e213322e7b56283572)
    (cherry picked from commit 0bf75621bbd25d4ce8a3588f112cf714891556eb)


** Changed in: nova/ocata
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Security SIG, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1739646

Title:
  Instance type with disk set to 0 can cause DoS

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  Fix Committed
Status in OpenStack Compute (nova) pike series:
  Fix Committed
Status in OpenStack Compute (nova) queens series:
  Fix Committed
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  In OpenStack at the moment, there is the ability to create instance
  types with disk size 0.  The API documentation states the following:

  "The size of the root disk that will be created in GiB. If 0 the root
  disk will be set to exactly the size of the image used to deploy the
  instance. However, in this case filter scheduler cannot select the
  compute host based on the virtual image size. Therefore, 0 should only
  be used for volume booted instances or for testing purposes."

  In a cloud environment where a deployer wants to offer boot-from-
  volume instances, those instance types will be there.  However, this
  means that a user can upload an image of 4TB and boot small instances
  where each one will have 4TB of storage, potentially exhausting the
  disks local storage (or Ceph cluster if using Ceph for ephemeral
  storage).

  I'm not sure if this is a security issue or it should be published as
  an advisory, but I believe there should be an option to disable the
  feature of booting an instance with the exact size of the image used
  so deployers have the ability/choice to provide boot-from-volume
  instance types.

  I can confirm this in our environment that if a customer creates an
  instance with 200GB of ephemeral disk space, they can take an image of
  it, then create an instance with that image on an instance type that
  has no ephemeral disk space and get 200GB of disk.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1739646/+subscriptions