keystone.common.config is 1200+ lines of super dense, merge-conflict
prone, difficult to navigate, and finicky to maintain code. Let's follow
nova's lead and break it down into more manageable modules.
This patch creates a new Python package, keystone.conf, and moves all of
our configuration options into it, mirroring nova's nova.conf package.
There are a couple special modules in keystone.conf introduced here as
well:
- keystone.conf.__init__: This causes all of Keystone options to be
registered on import, so consumers of keystone.conf don't have
races with config initialization code while trying to use
oslo_config.cfg.CONF directly (keystone.conf replaces all uses for
oslo_config.cfg.CONF in keystone).
- keystone.conf.base: Keystone's [DEFAULT] group options. I'd prefer
this to be called 'default.py', but I'm just copying nova's lead here.
- keystone.conf.opts: The entry point for oslo.config itself.
- keystone.conf.constants: There are a few constants (deprecation
messages, default paths, etc) that are used by multiple configuration
modules, so they need to live in a common place.
Change-Id: Ia3daffe3fef111b42de203762e966cd14d8927e2
This patch moves the assignment abstract base class out of core and into
backends/base.py
This removes dependencies where backend code references code in the
core. The reasoning being that the core should know about the backend
interface, but the backends should not know anything about the core
(separation of concerns). And part of the risk here is a potential for
circular dependencies.
Partial-Bug: #1563101
Change-Id: Ie507b61044ad32ecaac26901c1bcd0a0c17bd381
EngineFacade is deprecated. This partially switches keystone to
use oslo.db.sqlalchemy.enginefacade. 'get_session' and 'get_engine'
methods are still used in sql migrations and related tests.
Change-Id: I221232d50821fe2adb9881f237f06714003ce79d
Partial-Bug: #1490571
Currently, when deleting a role that has an implied role, only one
is removed from the database. This is because the initial FKs that
were created did not take delete and update into account.
Change-Id: I09ef96cf9e4a863337399ae880e0511125f5239c
Closes-Bug: 1546562
In change I74a8403a7bda271342708d282fd3f3f8aae63dc9, two comments
suggested fixing a typo and adding another test case.
This change address them.
Change-Id: Ibfc2bfc8df5fb03b10386c8918691487be4bc81f
This patch expands the definition of a role to include an
optional domain_id, which is included in the uniqueness
contraint along with the role name.
The V8 role driver wrapper is updated to ensure that
older drivers are oblivious to this change (and an
attempt to create a domain specific role with a V8 driver
will raise a NotImplemented exception).
An additional item of note, is that since the uniqueness
constraint contains a nullable value, we actually store
a special value (as opposed to None) in the sql attribute so
as to still use the sql uniqueness constraint to ensure
we do not have race conditions in multi-process keystone
configurations. This special value is entirely hidden within
the sql driver and is not exposed to the manager layer and
above. We do not support domain specific roles in the LDAP backend.
Follow-on patches will modify the policy rules for the role
APIs as well as modify the implied roles mechanism to support
domain specific roles so that they are actually useful.
Partially Implements: blueprint domain-specific-roles
Change-Id: I74a8403a7bda271342708d282fd3f3f8aae63dc9
This patch addresses most of the comments from patch:
https://review.openstack.org/#/c/264260/
Changes:
- fix nits on documentation
- minor refactor in get and delete of implied
roles SQL backend
- added tests for CRD of implied role and ImpliedRoleNotFound
Change-Id: I96ce922d94826cc985af4f4b4acff3be24b35aad
The LDAP Role Backend has been removed without the normal deprecation
notice in-code however, the Role backend was explicitly called out when
the deprecation announcement occured[1] and was explicitly included
as part of the deprecation of "assignment"-based LDAP. The LDAP Role
backend is not very useful without the other parts of the assignment
backend that were deprecated and removed.
[1] http://lists.openstack.org/pipermail/openstack/2015-January/011337.html
Change-Id: I1bd02d5834814959a93601fe53f115d0f9cc08a8
bp: removed-as-of-mitaka
CRD for the rules that allow one role to infer another role.
When listing roles, implied roles are inferred from any explicitly
assigned roles. A config option controls whether implied roles
are expanded in the auth data associated with tokens.
The list_assignment tests helper is also modified to
allow data driven tests for implied roles, and those new tests
are also included here.
Implied roles are not supported by the LDAP drivers; if you
try and CRD implied roles with an LDAP assignment driver a
NotImplemented is returned.
Co-Authored-By: Henry Nash <henryn@linux.vnet.ibm.com>
Partially implements: blueprint implied-roles
Change-Id: I6a9c23aea4b1f348c6c8c2b9274865806d856b82
In the recent change to create a V9 role driver
(https://review.openstack.org/#/c/247805/) the renaming to V9
was missed for the LDAP driver (the SQL driver was correct).
This patch fixes the LDAP driver class name.
Partially Implements: blueprint implied-roles
Change-Id: I49efeedaa5c163c4434dacc3c3467497d9fffca2
Although not used in all backends now, @truncated decorator can be
useful in all of them and there is no sense in making it sql-only.
Change-Id: I063cb1d621f4e2bf4d350450a56044d0b6cee7c1
Partial-Bug: 1501698
In preparation for new role driver methods for implied roles, this
patch creates a new version of the role driver.
Partially Implements@ blueprint implied-roles
Change-Id: I00cc57a77a23ed30d86fce8e309f6b27c4ae26a1
The LDAP backend for assignment and resource drivers has been
deprecated since the 'K' release. It's been decided that its time
to deprecate LDAP role, since without the support for assignment
and resource, the role backend is likely broken.
The LDAP role backend was split from assignment backend and should
have also been deprecated according to the agreement from the keystone
team, but it looks like it was missed [1].
[1] http://lists.openstack.org/pipermail/openstack/2015-January/011337.html
Change-Id: I390f5c2fb36d617a83fce618708febca3da9f1d2
implements: bp deprecated-as-of-mitaka
The try_except_pass test checks that pass isn't used in an except
block because it's the source of lots of security issues. The
current instances of pass in an except block are marked as nosec.
Change-Id: I73af6b80fa75286e96943026b7b71ad23dc1786b
Extended support for versioned driver classes to the rest of the
backends based on the design of the initial support for catalog backend @
https://review.openstack.org/#/c/218481/
partially Implements bp stable-driver-interfaces
Change-Id: I0078f6dc32932beb6db534ecf22b160097c5a090
Keystone modules used different sources of the CONF global so were
inconsistent. All modules should use CONF from oslo_config.cfg.
Change-Id: I60c8d2c577d37b9b8a367b46596154ce6c49fff4
Most of changes are just replacing
from keystone.openstack.common import log
with
from oslo_log import log
There are some other specific changes that had to be made
* Initialize logger in keystone/config.py
Change-Id: I859edb71c434051ffe7f34c16018b738ddb71e3b
This is the first part of the more comprehensive split of
assignments, which rationalizes both the backend and controllers.
In order to make this change easier for reviewers, it is divided
into a number of smaller patches.
Follow-on patches will:
- Fix incorrect doc strings for grant driver methods
- Update unit tests to call the new role manager
- Update the assignment controller to call the role manager
- Refactor assignment manager and driver methods to logically
separate project/domains from the actual assignments
- Split projects and domains into their own backend
- Split the controllers so they call the correct manager
- Update the tests to call the new correct manager
Partially implements: bp pluggable-assignments
Change-Id: I41fc23a049c26e514222a966c1847e183448be00
zhufl