aceec15371
Better follow conventions, especially: * remove Latinism like via and i.e. * use variable lists * Add missing <filename> * wrap long lines Change-Id: I2a537df78ddf4fbeb127b058bf05caaf42441d5f
116 lines
6.6 KiB
XML
116 lines
6.6 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE chapter [
|
|
<!ENTITY % openstack SYSTEM "../common/entities/openstack.ent">
|
|
%openstack;
|
|
]>
|
|
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
xmlns="http://docbook.org/ns/docbook"
|
|
version="5.0"
|
|
xml:id="ch034_tenant-secure-networking-best-practices">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Networking services security best practices</title>
|
|
<para>This section discusses OpenStack Networking configuration best practices as they apply to tenant network security within your OpenStack deployment.</para>
|
|
<section xml:id="ch034_tenant-secure-networking-best-practices-idp44592">
|
|
<title>Tenant network services workflow</title>
|
|
<para>OpenStack Networking provides users real self services of network resources and configurations. It is important that cloud architects and operators evaluate their design use cases in providing users the ability to create, update, and destroy available network resources.</para>
|
|
</section>
|
|
<section xml:id="ch034_tenant-secure-networking-best-practices-idp46080">
|
|
<title>Networking resource policy engine</title>
|
|
<para>A policy engine and its configuration file,
|
|
<filename>policy.json</filename>, within OpenStack Networking
|
|
provides a method to provide finer grained authorization of
|
|
users on tenant networking methods and objects. It is important
|
|
that cloud architects and operators evaluate their design and
|
|
use cases in providing users and tenants the ability to create,
|
|
update, and destroy available network resources as it has a
|
|
tangible effect on tenant network availability, network
|
|
security, and overall OpenStack security. For a more detailed
|
|
explanation of OpenStack Networking policy definition, please
|
|
refer to the <link
|
|
xlink:href="http://docs.openstack.org/admin-guide-cloud/content/section_networking_auth.html">Authentication
|
|
and authorization section</link> in the <citetitle>OpenStack
|
|
Cloud Administrator Guide</citetitle>.</para>
|
|
<note><para>It is important to review the default networking
|
|
resource policy and modify the policy appropriately for your
|
|
security posture.</para></note>
|
|
<para>If your deployment of OpenStack provides multiple external
|
|
access points into different security domains it is important
|
|
that you limit the tenant's ability to attach multiple vNICs to
|
|
multiple external access points—this would bridge these
|
|
security domains and could lead to unforeseen security
|
|
compromise. It is possible mitigate this risk by utilizing the
|
|
host aggregates functionality provided by OpenStack Compute or
|
|
through splitting the tenant VMs into multiple tenant projects
|
|
with different virtual network configurations.</para>
|
|
</section>
|
|
<section xml:id="ch034_tenant-secure-networking-best-practices-idp51440">
|
|
<title>Security groups</title>
|
|
<para>
|
|
The OpenStack Networking Service provides security group
|
|
functionality using a mechanism that is more flexible and
|
|
powerful than the security group capabilities built into
|
|
OpenStack Compute. Thus, when using OpenStack Networking,
|
|
<filename>nova.conf</filename> should always disable built-in
|
|
security groups and proxy all security group calls to the
|
|
OpenStack Networking API. Failure to do so will result in
|
|
conflicting security policies being simultaneously applied by
|
|
both services. To proxy security groups to OpenStack
|
|
Networking, use the following configuration values:</para>
|
|
<itemizedlist><listitem>
|
|
<para><option>firewall_driver</option> must be set to
|
|
<literal>nova.virt.firewall.NoopFirewallDriver</literal> so
|
|
that <systemitem class="service">nova-compute</systemitem>
|
|
does not perform iptables-based filtering itself.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><option>security_group_api</option> must be set to
|
|
<literal>neutron</literal> so that all security group
|
|
requests are proxied to the OpenStack Networking
|
|
service.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Security groups and security group rules allow administrators and tenants the ability to specify the type of traffic and direction (ingress/egress) that is allowed to pass through a virtual interface port. A security group is a container for security group rules. When a virtual interface port is created in OpenStack Networking it is associated with a security group. If a security group is not specified, the port will be associated with a 'default' security group. By default this group will drop all ingress traffic and allow all egress. Rules can be added to this group in order to change the behaviour.</para>
|
|
<para>When using the security group API through OpenStack Compute, security groups are applied to all virtual interface ports on an instance. The reason for this is that OpenStack Compute security group APIs are instance based and not virtual interface port based as OpenStack Networking.</para>
|
|
</section>
|
|
<section xml:id="ch034_tenant-secure-networking-best-practices-idp58016">
|
|
<title>Quotas</title>
|
|
|
|
<para>Quotas provide the ability to limit the number of network
|
|
resources available to tenants. You can enforce default quotas
|
|
for all tenants. The
|
|
<filename>/etc/neutron/neutron.conf</filename> includes these
|
|
options for quota:</para>
|
|
<programlisting language="ini">[QUOTAS]
|
|
# resource name(s) that are supported in quota features
|
|
quota_items = network,subnet,port
|
|
|
|
# default number of resource allowed per tenant, minus for unlimited
|
|
#default_quota = -1
|
|
|
|
# number of networks allowed per tenant, and minus means unlimited
|
|
quota_network = 10
|
|
|
|
# number of subnets allowed per tenant, and minus means unlimited
|
|
quota_subnet = 10
|
|
|
|
# number of ports allowed per tenant, and minus means unlimited
|
|
quota_port = 50
|
|
|
|
# number of security groups allowed per tenant, and minus means unlimited
|
|
quota_security_group = 10
|
|
|
|
# number of security group rules allowed per tenant, and minus means unlimited
|
|
quota_security_group_rule = 100
|
|
|
|
# default driver to use for quota checks
|
|
quota_driver = neutron.quota.ConfDriver</programlisting>
|
|
<para>
|
|
OpenStack Networking also supports per-tenant quotas limit
|
|
through a quota extension API. To enable per-tenant quotas,
|
|
you must set the <literal>quota_driver</literal> option in
|
|
<filename>neutron.conf</filename>.</para>
|
|
<programlisting language="ini">quota_driver = neutron.db.quota_db.DbQuotaDriver</programlisting>
|
|
</section>
|
|
</chapter>
|