Added two new indexes to all RBAC DB models: "target_tenant" and
"action".
The DB models affected are "networkrbacs", "qospolicyrbacs",
"securitygrouprbacs", "addressscoperbacs", "subnetpoolrbacs" and
"addressgrouprbacs".
The goal of this patch is to speed up the model query if RBAC apply to
this object. If the object query scope is a project, [1] will be added
to the DB query. If "action" and "target_tenant" are indexed, the exact
match filtering will be faster.
[1]890d62a3df/neutron_lib/db/model_query.py (L123-L131)
Change-Id: I0a70a1a500fad52ca55006d6e2ebc1044aef0fc8
Closes-Bug: #1918145
"@abc.abstractproperty" is deprecated since 3.3. Now it's possible
to use "@property" on top of "@abstractmethod".
Change-Id: I0cca37b626a94a05fb983a8528c22a660e89e673
Increment the revision number when RBAC policies are
changed since it impacts the calculation of the 'shared'
field.
Closes-Bug: #1708079
Change-Id: I4c7eeff8745eff3761d54ef6d3665cf3dc6e6222
Remove The following _MAX_LEN constants from
neutron/api/v2/attributes.py and use the corresponding DB field size
constants from neutron_lib.db.constants instead.
NAME_MAX_LEN --> NAME_FIELD_SIZE
TENANT_ID_MAX_LEN --> PROJECT_ID_FIELD_SIZE
DESCRIPTION_MAX_LEN --> DESCRIPTION_FIELD_SIZE
LONG_DESCRIPTION_MAX_LEN --> LONG_DESCRIPTION_FIELD_SIZE
DEVICE_ID_MAX_LEN --> DEVICE_ID_FIELD_SIZE
DEVICE_OWNER_MAX_LEN --> DEVICE_NAME_FIELD_SIZE
In alembic migration scripts, the raw numerical value is used.
For more information, see:
http://lists.openstack.org/pipermail/openstack-dev/2016-October/105789.html
NeutronLibImpact
Change-Id: I734890372584fe27e5d6ec38c0cad2de882ff11c
Neutron Manager is loaded at the very startup of the neutron
server process and with it plugins are loaded and stored for
lookup purposes as their references are widely used across the
entire neutron codebase.
Rather than holding these references directly in NeutronManager
this patch refactors the code so that these references are held
by a plugin directory.
This allows subprojects and other parts of the Neutron codebase
to use the directory in lieu of the manager. The result is a
leaner, cleaner, and more decoupled code.
Usage pattern [1,2] can be translated to [3,4] respectively.
[1] manager.NeutronManager.get_service_plugins()[FOO]
[2] manager.NeutronManager.get_plugin()
[3] directory.get_plugin(FOO)
[4] directory.get_plugin()
The more entangled part is in the neutron unit tests, where the
use of the manager can be simplified as mocking is typically
replaced by a call to the directory add_plugin() method. This is
safe as each test case gets its own copy of the plugin directory.
That said, unit tests that look more like API tests and that rely on
the entire plugin machinery, need some tweaking to avoid stumbling
into plugin loading failures.
Due to the massive use of the manager, deprecation warnings are
considered impractical as they cause logs to bloat out of proportion.
Follow-up patches that show how to adopt the directory in neutron
subprojects are tagged with topic:plugin-directory.
NeutronLibImpact
Partially-implements: blueprint neutron-lib
Change-Id: I7331e914234c5f0b7abe836604fdd7e4067551cf
All occurences of ``tenant_id`` across the database are renamed
to ``project_id``. Both options are equally valid, but ``project_id``
is preferred.
To inform external users about the change, HasTenant class was
deprecated.
UpgradeImpact
Partially-Implements: blueprint keystone-v3
Change-Id: I87a8ef342ccea004731ba0192b23a8e79bc382dc
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
The UniqueConstraint being constructed at class load time for
RBACColumns meant that all tables inheriting from it ended up
sharing the same UniqueConstraint object. This led to a bunch
of warnings about columns being replaced from one table to
another. This didn't appear to affect any functionality but it
may have broken queries across both tables.
This patch just converts it into a declared attr so a separate
constraint object gets created for each table that inherits the
class.
Closes-Bug: #1550618
Change-Id: I02b8e911125c06691bf02b6e7ac02cf25c4c4142
This patch implements a new database model required for the
qos-policy RBAC support. In addition it migrates the current qos-policy
'shared' attribute to leverage the new 'qospolicyrbacs' table.
'shared' is no longer a property of the QosPolicy DB model. Its status
is based on the tenant ID of the API caller. From an API perspective the
logic remains the same - tenants will see qos-policies as 'shared=True'
in case the qos-policy is shared with them). However, internal callers
(e.g. plugins, drivers, services) must not check for the 'shared'
attribute on qos-policy db objects any more.
DocImpact
APIImpact
Blueprint: rbac-qos
Related-bug: #1512587
Change-Id: I1c59073daa181005a3e878bc2fe033a0709fbf31
The Network model was implicitly relying on a core plugin to import
the db_base_plugin_v2 module which would import the rbac model module
so "NetworkRBAC" would be defined by the time something would query
the DB. However, this isn't the case for scripts or agents that are
importing models_v2 and trying to query the DB directly so they will
now break with an sqlaclhemy error about a missing model.
This patch makes models_v2 import the rbac_db_models module directly
so the model will always be defined.
This would have resulted in a circular import because the
rbac_db_models module required the HasId and HasTenant classes
in models_v2. So this patch also moves these helper classes
into model_base.
Change-Id: I338ce1c0ba55647e6410a63f937737f75a63057d
Closes-Bug: #1488032
This patch implements the database model required for the network
RBAC work. In addition it migrates the current network and subnet
'shared' attributes to leverage the new table.
'shared' is no longer a property of the DB model because its status
is based on the tenant ID of the API caller. From an API perspective
this is the same (tenants will see networks as 'shared=True' if the
network is shared with them). However, internal callers (e.g. plugins,
drivers, services) will not be able to check for the 'shared' attribute
on network and subnet db objects any more.
This patch just achieves parity with the current shared behavior so it
doesn't add the ability to manipulate the RBAC entries directly. The
RBAC API is in the following patch.
Partially-Implements: blueprint rbac-networks
Change-Id: I3426b13eede8bfa29729cf3efea3419fb91175c4
Rodolfo Alonso Hernandez