yahoo-eng-team team mailing list archive

[Boden R <bodenvmw@xxxxxxxxx>]

The original patch included a release note.

The networking guide is already updated to include documentation on
access_as_external [1].

That said I don't see any work left here. Closing out as invalid.


[1] http://docs.openstack.org/newton/networking-guide/config-rbac.html#allowing-a-network-to-be-used-as-an-external-network

** Changed in: neutron
       Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1552077

Title:
  [api-ref]Use network RBAC feature for external access

Status in neutron:
  Invalid
Status in openstack-api-site:
  Invalid

Bug description:
  https://review.openstack.org/282295
  Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to.

  commit 49b4dd3478d782aee4260033825aa6b47eaf644a
  Author: Kevin Benton <kevin@xxxxxxxxxx>
  Date:   Fri Feb 19 03:34:27 2016 -0800

      Use network RBAC feature for external access
      
      This allows access to external networks to be controlled via the
      RBAC framework added during Liberty with a new 'access_as_external'
      action.
      
      A migration adds all current external networks to the RBAC policies
      table with a wildcard indicating that all tenants can access the network
      as RBAC.
      
      Unlike the conversion of shared networks to RBAC, the external table
      is left in the DB to avoid invasive changes throughout the codebase
      to calculate the flag relative to the caller. So the current 'external'
      flag is used throughout the code base as it previously was for wiring
      up floating IPs, router gateway ports, etc. Then the RBAC entries are
      only referenced when determining what networks to show the tenants.
      
      API Behavior:
       * Marking a network as 'external' will automatically create a wildcard
         entry that allows that network to be accessed by all tenants.
       * An external network may have all of its RBAC entries deleted and then
         only an admin will be able to attach to it.
       * An RBAC 'access_as_external' entry cannot be deleted if it is required
         for a tenant that currently has a router attached to that network.
       * Creating an 'access_as_external' RBAC entry will automatically convert
         the network into an external network. (This is to enable a workflow
         where a private external network is never visible to everyone.)
       * The default policy.json will prevent a non-admin from creating wildcard
         'access_as_external' RBAC entries to align with the current default policy
         we have on setting the 'external' field on the network to prevent poluting
         everyone else's network lists.
       * The default policy.json will allow a tenant to create an
         'access_as_external' RBAC entry to allow specific tenants
         (including itself) the ability to use its network as an external network.
      
      Closes-Bug: #1547985
      DocImpact: External networks can now have access restricted to small subsets
                 of tenants
      APIImpact: 'access_as_external' will be allowed as an action in the RBAC
                 API for networks
      Change-Id: I4d8ee78a9763c58884e4fd3d7b40133da659cd61

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