From 3c524e6491c1b35a2f8413ebe046c238bf530d71 Mon Sep 17 00:00:00 2001 From: Lance Bragstad Date: Thu, 28 Dec 2017 22:11:32 +0000 Subject: [PATCH] Grant admin a role on the system during bootstrap Now that we have system scope in place, we should make sure at least one user has a role assignment on the system. We can do this at the same time we grant the user a role on a project during bootstrap. This is backwards compatible because even if a deployment doesn't use system-scope, the assignment will just sit there. The deployment will have to opt into enforcing scope by updating configuration options for oslo.policy to enforce scoping. This shouldn't prevent deployments from fixing bug 968696 and using system scope. Closes-Bug: 1749268 Change-Id: I6b7196a28867d9a699716c8fef2609d608a5b2a2 --- keystone/cmd/cli.py | 20 +++++++++++++++++++ keystone/tests/unit/test_cli.py | 7 +++++++ .../bp-system-scope-7d236ee5992d4e20.yaml | 9 ++++++++- 3 files changed, 35 insertions(+), 1 deletion(-) diff --git a/keystone/cmd/cli.py b/keystone/cmd/cli.py index 663b082caa..1238fac261 100644 --- a/keystone/cmd/cli.py +++ b/keystone/cmd/cli.py @@ -298,6 +298,26 @@ class BootStrap(BaseApp): 'role': self.role_name, 'project': self.project_name}) + # NOTE(lbragstad): We need to make sure a user has at least one role on + # the system. Otherwise it's possible for administrators to lock + # themselves out of system-level APIs in their deployment. This is + # considered backwards compatible because even if the assignment + # exists, it needs to be enabled through oslo.policy configuration + # options to be enforced. + try: + self.assignment_manager.create_system_grant_for_user( + user['id'], self.role_id + ) + LOG.info('Granted %(role)s on the system to user' + ' %(username)s.', + {'role': self.role_name, + 'username': self.username}) + except exception.Conflict: + LOG.info('User %(username)s already has %(role)s on ' + 'the system.', + {'username': self.username, + 'role': self.role_name}) + if self.region_id: try: self.catalog_manager.create_region( diff --git a/keystone/tests/unit/test_cli.py b/keystone/tests/unit/test_cli.py index 68e4fe10f2..7894043b7c 100644 --- a/keystone/tests/unit/test_cli.py +++ b/keystone/tests/unit/test_cli.py @@ -131,6 +131,13 @@ class CliBootStrapTestCase(unit.SQLDriverOverrides, unit.TestCase): project['id'])) self.assertIs(1, len(role_list)) self.assertEqual(role_list[0], role['id']) + system_roles = ( + bootstrap.assignment_manager.list_system_grants_for_user( + user['id'] + ) + ) + self.assertIs(1, len(system_roles)) + self.assertEqual(system_roles[0]['id'], role['id']) # NOTE(morganfainberg): Pass an empty context, it isn't used by # `authenticate` method. bootstrap.identity_manager.authenticate( diff --git a/releasenotes/notes/bp-system-scope-7d236ee5992d4e20.yaml b/releasenotes/notes/bp-system-scope-7d236ee5992d4e20.yaml index c32c263d19..8e47957c81 100644 --- a/releasenotes/notes/bp-system-scope-7d236ee5992d4e20.yaml +++ b/releasenotes/notes/bp-system-scope-7d236ee5992d4e20.yaml @@ -4,7 +4,9 @@ features: [`blueprint system-scope `_] Keystone now supports the ability to assign roles to users and groups on the system. As a result, users and groups with system role assignment will - be able to request system-scoped tokens. + be able to request system-scoped tokens. Additional logic has been added to + ``keystone-manage bootstrap`` to ensure the administrator has a role on the + project and system. fixes: - | [`bug 968696 `_] @@ -12,3 +14,8 @@ fixes: in addition to associating `scope types `_ to operations with ``oslo.policy`` will give project developers the ability to fix `bug 968696 `_. + - | + [`bug 1749268 `_] + The ``keystone-manage bootstrap`` command now ensures that an administrator + has a system role assignment. This prevents the ability for operators to + lock themselves out of system-level APIs.