From ab8e689d33958bb6f87dabf3f492c326079b0fd3 Mon Sep 17 00:00:00 2001 From: Ruby Loo Date: Tue, 24 May 2016 12:38:56 -0400 Subject: [PATCH] minor changes to security documentation This contains some minor changes to the security documentation: - replace 'ironic' with 'the Bare Metal service' (as per documentation guidelines - fixes a few grammatical issues - removes reference to "clean_nodes" configuration option since it has been deleted in Newton - clarifies that [deploy]/erase_devices_priority cannot be 0 for erasing of devices to happen - added links - additional references shows reference descriptions instead of the links Change-Id: I11df3bde9eff4b7f109bee6b9d0058e325b67027 --- doc/source/deploy/security.rst | 42 +++++++++++++++++++--------------- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/doc/source/deploy/security.rst b/doc/source/deploy/security.rst index c89276d1ef..3964c72c75 100644 --- a/doc/source/deploy/security.rst +++ b/doc/source/deploy/security.rst @@ -7,14 +7,14 @@ Security Overview ======== -While Ironic is intended to be a secure application, it is important to -understand what it does and does not cover today. +While the Bare Metal service is intended to be a secure application, it is +important to understand what it does and does not cover today. Deployers must properly evaluate their use case and take the appropriate actions to secure their environment appropriately. This document is intended to -provide an overview of what risks and operator of Ironic should be aware of. It -is not intended as a How-To guide for securing a data center or an OpenStack -deployment. +provide an overview of what risks an operator of the Bare Metal service should +be aware of. It is not intended as a How-To guide for securing a data center +or an OpenStack deployment. .. TODO: add "Security Considerations for Network Boot" section @@ -27,10 +27,10 @@ deployment. Firmware security ================= -When ironic deploys an operating system image to a server, that image is run -natively on the server without virtualization. Any user with administrative -access to the deployed instance has administrative access to the underlying -hardware. +When the Bare Metal service deploys an operating system image to a server, that +image is run natively on the server without virtualization. Any user with +administrative access to the deployed instance has administrative access to +the underlying hardware. Most servers' default settings do not prevent a privileged local user from gaining direct access to hardware devices. Such a user could modify device or @@ -38,16 +38,17 @@ firmware settings, and potentially flash new firmware to the device, before deleting their instance and allowing the server to be allocated to another user. -If the ``automated_clean`` configuration option is enabled (previously the -``clean_nodes`` option), then Ironic will securely erase all local disk devices -within a machine during instance deletion. However, Ironic does not ship with +If the ``[conductor]/automated_clean`` configuration option is enabled (and +the ``[deploy]/erase_devices_priority`` configuration option is not zero), +the Bare Metal service will securely erase all local disk devices within a +machine during instance deletion. However, the service does not ship with any code that will validate the integrity of, or make any modifications to, system or device firmware or firmware settings. Operators are encouraged to write their own hardware manager plugins for the ``ironic-python-agent`` ramdisk. This should include custom ``clean steps`` -that would be run as part of Node de-provisioning. This should include custom -``clean steps`` to be run as part of the automated cleaning process, which +that would be run during the `automated cleaning`_ process, as part of Node +de-provisioning. The ``clean steps`` would perform the specific actions necessary within that environment to ensure the integrity of each server's firmware. @@ -57,11 +58,16 @@ include: - installing signed firmware for BIOS and peripheral devices - using a TPM (Trusted Platform Module) to validate signatures at boot time - - booting machines in UEFI SecureBoot mode, rather than BIOS mode, to validate - kernel signatures + - booting machines in `UEFI Secure Boot mode`_, rather than BIOS mode, to + validate kernel signatures - disabling local (in-band) access from the host OS to the management controller (BMC) - disabling modifications to boot settings from the host OS Additional references: - - http://docs.openstack.org/developer/ironic/deploy/install-guide.html?highlight=txt#trusted-boot-with-partition-image - - http://docs.openstack.org/developer/ironic/drivers/ilo.html?highlight=secure%20boot#uefi-secure-boot-support + - `automated cleaning`_ + - `trusted boot with partition image`_ + - `UEFI Secure Boot mode`_ + +.. _automated cleaning: http://docs.openstack.org/developer/ironic/deploy/cleaning.html#automated-cleaning +.. _trusted boot with partition image: http://docs.openstack.org/developer/ironic/deploy/install-guide.html?highlight=txt#trusted-boot-with-partition-image +.. _UEFI Secure Boot mode: http://docs.openstack.org/developer/ironic/drivers/ilo.html?highlight=secure%20boot#uefi-secure-boot-support