Describe the need for a default service role
Related-Bug: 1951632 Change-Id: Idef5ac4083a7070f272b3e15a464a8c9dc447d47
This commit is contained in:
Lance Bragstad
Ghanshyam Mann
parent
7071cf3e94
commit
75b4fb25c5
|
|
@ -14,6 +14,14 @@ Project Documentation:
|
|||
keystone
|
||||
--------
|
||||
|
||||
2023.1 approved specs:
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
specs/keystone/2023.1/*
|
||||
|
||||
Yoga approved specs:
|
||||
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@ -0,0 +1,212 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
====================
|
||||
Default Service Role
|
||||
====================
|
||||
|
||||
`bug #1951632 <https://bugs.launchpad.net/keystone/+bug/1951632>`_
|
||||
|
||||
In Rocky, keystone added a `default role hierarchy
|
||||
<https://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html>`_.
|
||||
This was part of a large initiative to improve RBAC across all OpenStack
|
||||
projects. Through the process of adopting the default roles implemented in
|
||||
Rocky, OpenStack developers and operators have acknowledged that several
|
||||
OpenStack service accounts have too much authorization.
|
||||
|
||||
This specification details the reasons for creating a new role called
|
||||
``service`` and updating the default policies across OpenStack for
|
||||
service-to-service communication to use that specialized role.
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
Today, ``keystone-manage bootstrap`` provides three default roles, ``admin``,
|
||||
``member``, and ``reader``. These roles build a basic hierarchy, where
|
||||
``admin`` implies ``member``, and ``member`` implies ``reader``. The rationale
|
||||
for this work is detailed in the original specification.
|
||||
|
||||
The ``admin`` role has the ability to do just about anything in the OpenStack
|
||||
deployment. Unfortunately, it's used as catch all for authorization. This
|
||||
results in service users getting the ``admin`` role when they need to do a
|
||||
privileged operation in one service. In reality, this is poor security practice
|
||||
because that service account has the ability to do anything. It can create,
|
||||
update, and remove any resource in the deployment. A bad actor could easily use
|
||||
a compromised service account to create backdoor access to the deployment.
|
||||
|
||||
By applying the principle of least privilege to service users, we can harden
|
||||
OpenStack default security posture and reduce the surface area of
|
||||
administrative power.
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
Expand the ``keystone-manage bootstrap`` utility to create a new role named
|
||||
``service``. Conflicts should be handled gracefully, especially since some
|
||||
policies in OpenStack rely on the ``service`` role already and it's entirely
|
||||
plausible that operators have created this role already. Existing roles
|
||||
shouldn't be deleted and then recreated, so that we don't break anything
|
||||
relying on the role ID.
|
||||
|
||||
|
||||
This role should be kept outside of the existing role hierarchy that includes
|
||||
``admin``, ``member``, and ``reader``. Those role definitions were created with
|
||||
humans in mind, and organized hierarchically to apply to hierarchical RBAC.
|
||||
Service-to-service communication is much more prescriptive in that service
|
||||
accounts only need to access a handful of APIs from other services. Building
|
||||
the ``service`` role outside the current hierarchy ensures we're following the
|
||||
principle of least privilege for service accounts.
|
||||
|
||||
After keystone implements support for the ``service`` role, OpenStack service
|
||||
developers can start integrating it into their default policies.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
policy.DocumentedRuleDefault(
|
||||
name='os_compute_api:os-server-external-events:create',
|
||||
check_str='role:service',
|
||||
scope_types=['project']
|
||||
)
|
||||
|
||||
We need to keep all the service-to-service APIs default to ``service`` role
|
||||
only and not to add any other role in logical or here. The idea here is to keep
|
||||
their default access to ``service`` role only. If any of the service-to-service
|
||||
APIs are used by admin or non-admin user then recommendation is to ask them to
|
||||
override the default in policy.yaml file instead of changing the default in
|
||||
code. There might be exception service-to-service APIs which project think are
|
||||
useful to be used by admin or non-admin user then they can take the exceptional
|
||||
decision to default them to user role and ``service`` role.
|
||||
|
||||
As we have dropped the system scope implementation for services, service to
|
||||
service communication with ``service`` role will be done with project scope
|
||||
token.
|
||||
|
||||
Additionally, any deployment tools that create service accounts for OpenStack
|
||||
services, should start preparing for these policy changes by updating their
|
||||
role assignments and performing the deployment language equivalent of the
|
||||
following::
|
||||
|
||||
$ openstack role add --user nova --project service service
|
||||
$ openstack role add --user cinder --project service service
|
||||
$ openstack role add --user neutron --project service service
|
||||
$ openstack role add --user glance --project service service
|
||||
$ openstack role add --user manila --project service service
|
||||
|
||||
Future Work Proposals
|
||||
---------------------
|
||||
|
||||
Service-Specific Default Roles
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In a later release we could elaborate on this concept to create additional
|
||||
roles called ``compute-service``, ``block-storage-service``,
|
||||
``network-service``, ``image-service`` and so on. The ``service`` role could
|
||||
imply each of these roles and the policies for each service could be refined
|
||||
again to only allow access based on the service. This would require additional
|
||||
deployment tool intervention::
|
||||
|
||||
$ openstack role add --user nova --project service compute-service
|
||||
$ openstack role add --user cinder --project service block-storage-service
|
||||
$ openstack role add --user neutron --project service network-service
|
||||
$ openstack role add --user glance --project service image-service
|
||||
|
||||
This would reduce the ability for service accounts to interact with APIs they
|
||||
don't need.
|
||||
|
||||
Application Credentials
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
An alternative to service-specific default roles would be to use `application
|
||||
credentials with access rules
|
||||
<https://docs.openstack.org/keystone/latest/user/application_credentials.html#access-rules>`_
|
||||
for each service. Each service would still have the ``service`` role, but it
|
||||
would be restricted to only access the APIs it requires using access rules.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
We could rely on deployment tooling to deploy this role at installation time.
|
||||
However, that still opens the door for inconsistencies across OpenStack
|
||||
installers.
|
||||
|
||||
Adding formal support in ``keystone-manage bootstrap`` is cleaner, more
|
||||
consistent, and integrates with existing deployment tools without additional
|
||||
action required.
|
||||
|
||||
Security Impact
|
||||
---------------
|
||||
|
||||
This new role is already used in some OpenStack policies. Using it initially
|
||||
will be better than granting service users the ``admin`` role.
|
||||
|
||||
Notifications Impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other End User Impact
|
||||
---------------------
|
||||
|
||||
This work doesn't require any client code since it's done using
|
||||
``keystone-manager``.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
This is a trivial change to add another row to the roles table. Performance
|
||||
impact is negligible.
|
||||
|
||||
Other Deployer Impact
|
||||
---------------------
|
||||
|
||||
If operators or deployers have a utility that creates a ``service`` role, then
|
||||
they can update that utility to remove that API call and they can rely on the
|
||||
functionality in ``keystone-manage bootstrap``.
|
||||
|
||||
Developer Impact
|
||||
----------------
|
||||
|
||||
Developers will have another role at their disposal for writing default
|
||||
policies. They should understand the proper usage of ``service`` and that it
|
||||
should only be used for service-to-service APIs.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
<lbragstad>
|
||||
<abhishekk>
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Update ``keystone-manage bootstrap`` to create a new role called ``service``
|
||||
* Add the corresponding ``service`` role to the administrator `guide
|
||||
<https://docs.openstack.org/keystone/latest/admin/service-api-protection.html>`_
|
||||
* Add the ``service`` role to the developer `documentation
|
||||
<https://docs.openstack.org/keystone/latest/contributor/services.html#reusable-default-roles>`_
|
||||
* Add the service role to any OpenStack-wide documentation describing the
|
||||
secure RBAC personas
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
This work is required to move forward on a set of community-wide `goals
|
||||
<https://review.opendev.org/c/openstack/governance/+/815158>`_ to improve
|
||||
authorization in OpenStack.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Listed above in the `Work Items`_ section.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
Referenced inline.
|
||||
Loading…
Reference in New Issue