openstack-manuals/doc/training-guide/module002-ch004-security-in-neutron.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>