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
(cherry picked from commit 3c524e6491)

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(

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(

releasenotes/notes/bp-system-scope-7d236ee5992d4e20.yaml

@@ -4,7 +4,9 @@ features:
     [`blueprint system-scope <https://blueprints.launchpad.net/keystone/+spec/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 <https://bugs.launchpad.net/keystone/+bug/968696>`_]
@@ -12,3 +14,8 @@ fixes:
     in addition to associating `scope types <http://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html>`_
     to operations with ``oslo.policy`` will give project developers the ability
     to fix `bug 968696 <https://bugs.launchpad.net/keystone/+bug/968696>`_.
+  - |
+    [`bug 1749268 <https://bugs.launchpad.net/keystone/+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.