fac23cb047
Since we have now a niceness gate, let's remove the known failures. Change-Id: I01684aee61e18e76f6523a466e28b8252e577f6f
141 lines
7.6 KiB
XML
141 lines
7.6 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
version="5.0"
|
|
xml:id="module002-ch004-security-in-neutron">
|
|
<title>Security in Neutron</title>
|
|
<para><guilabel>Security Groups</guilabel></para>
|
|
<para>Security groups and security group rules allows
|
|
administrators and tenants the ability to specify the type
|
|
of traffic and direction (ingress/egress) that is allowed
|
|
to pass through a port. A security group is a container
|
|
for security group rules.</para>
|
|
<para>When a 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>If one desires to use the OpenStack Compute security
|
|
group APIs and/or have OpenStack Compute orchestrate the
|
|
creation of new ports for instances on specific security
|
|
groups, additional configuration is needed. To enable
|
|
this, one must configure the following file
|
|
/etc/nova/nova.conf and set the config option
|
|
security_group_api=neutron on every node running
|
|
nova-compute and nova-api. After this change is made
|
|
restart nova-api and nova-compute in order to pick up this
|
|
change. After this change is made one will be able to use
|
|
both the OpenStack Compute and OpenStack Network security
|
|
group API at the same time.</para>
|
|
<para><guilabel>Authentication and Authorization</guilabel></para>
|
|
<para>OpenStack Networking uses the OpenStack Identity service
|
|
(project name keystone) as the default authentication
|
|
service. When OpenStack Identity is enabled Users
|
|
submitting requests to the OpenStack Networking service
|
|
must provide an authentication token in X-Auth-Token
|
|
request header. The aforementioned token should have been
|
|
obtained by authenticating with the OpenStack Identity
|
|
endpoint. For more information concerning authentication
|
|
with OpenStack Identity, please refer to the OpenStack
|
|
Identity documentation. When OpenStack Identity is
|
|
enabled, it is not mandatory to specify tenant_id for
|
|
resources in create requests, as the tenant identifier
|
|
will be derived from the Authentication token. Please note
|
|
that the default authorization settings only allow
|
|
administrative users to create resources on behalf of a
|
|
different tenant. OpenStack Networking uses information
|
|
received from OpenStack Identity to authorize user
|
|
requests. OpenStack Networking handles two kind of
|
|
authorization policies:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">Operation-based:</emphasis>
|
|
policies specify access criteria for specific
|
|
operations, possibly with fine-grained control over
|
|
specific attributes;</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold"
|
|
>Resource-based:</emphasis>whether access to specific
|
|
resource might be granted or not according to the
|
|
permissions configured for the resource (currently
|
|
available only for the network resource). The actual
|
|
authorization policies enforced in OpenStack
|
|
Networking might vary from deployment to
|
|
deployment.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>The policy engine reads entries from the policy.json
|
|
file. The actual location of this file might vary from
|
|
distribution to distribution. Entries can be updated while
|
|
the system is running, and no service restart is required.
|
|
That is to say, every time the policy file is updated, the
|
|
policies will be automatically reloaded. Currently the
|
|
only way of updating such policies is to edit the policy
|
|
file. Please note that in this section we will use both
|
|
the terms "policy" and "rule" to refer to objects which
|
|
are specified in the same way in the policy file; in other
|
|
words, there are no syntax differences between a rule and
|
|
a policy. We will define a policy something which is
|
|
matched directly from the OpenStack Networking policy
|
|
engine, whereas we will define a rule as the elements of
|
|
such policies which are then evaluated. For instance in
|
|
create_subnet: [["admin_or_network_owner"]], create_subnet
|
|
is regarded as a policy, whereas admin_or_network_owner is
|
|
regarded as a rule.</para>
|
|
<para>Policies are triggered by the OpenStack Networking
|
|
policy engine whenever one of them matches an OpenStack
|
|
Networking API operation or a specific attribute being
|
|
used in a given operation. For instance the create_subnet
|
|
policy is triggered every time a POST /v2.0/subnets
|
|
request is sent to the OpenStack Networking server; on the
|
|
other hand create_network:shared is triggered every time
|
|
the shared attribute is explicitly specified (and set to a
|
|
value different from its default) in a POST /v2.0/networks
|
|
request. It is also worth mentioning that policies can be
|
|
also related to specific API extensions; for instance
|
|
extension:provider_network:set will be triggered if the
|
|
attributes defined by the Provider Network extensions are
|
|
specified in an API request.</para>
|
|
<para>An authorization policy can be composed by one or more
|
|
rules. If more rules are specified, evaluation policy will
|
|
be successful if any of the rules evaluates successfully;
|
|
if an API operation matches multiple policies, then all
|
|
the policies must evaluate successfully. Also,
|
|
authorization rules are recursive. Once a rule is matched,
|
|
the rule(s) can be resolved to another rule, until a
|
|
terminal rule is reached.</para>
|
|
<para>The OpenStack Networking policy engine currently defines
|
|
the following kinds of terminal rules:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><emphasis role="bold">Role-based
|
|
rules:</emphasis> evaluate successfully if the
|
|
user submitting the request has the specified role.
|
|
For instance "role:admin"is successful if the user
|
|
submitting the request is an administrator.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Field-based
|
|
rules:</emphasis> evaluate successfully if a field
|
|
of the resource specified in the current request
|
|
matches a specific value. For instance
|
|
"field:networks:shared=True" is successful if the
|
|
attribute shared of the network resource is set to
|
|
true.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Generic
|
|
rules:</emphasis>compare an attribute in the resource
|
|
with an attribute extracted from the user's security
|
|
credentials and evaluates successfully if the
|
|
comparison is successful. For instance
|
|
"tenant_id:%(tenant_id)s" is successful if the tenant
|
|
identifier in the resource is equal to the tenant
|
|
identifier of the user submitting the request.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</chapter>
|