From 278b0eff1e3cd3052be57729a3c2523bfa133163 Mon Sep 17 00:00:00 2001 From: Ghanshyam Mann Date: Fri, 28 Apr 2023 13:25:58 -0500 Subject: [PATCH] Re-propose "Policy service role spec" This spec is to add service role to nova service-to-service APIs policies. Partial implement blueprint policy-service-role-default APIImpact Change-Id: Iea9c017a4f104370e75a3f1e5070c8efa01e30b6 --- .../approved/policy-service-role-default.rst | 195 ++++++++++++++++++ 1 file changed, 195 insertions(+) create mode 100644 specs/2023.2/approved/policy-service-role-default.rst diff --git a/specs/2023.2/approved/policy-service-role-default.rst b/specs/2023.2/approved/policy-service-role-default.rst new file mode 100644 index 000000000..07c5171d5 --- /dev/null +++ b/specs/2023.2/approved/policy-service-role-default.rst @@ -0,0 +1,195 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +=========================== +Policy Service Role Default +=========================== + +https://blueprints.launchpad.net/nova/+spec/policy-service-role-default + +Ideally all internal service-to-service APIs should not be accessible +by admin or end user by default. From policy defaults it should be +clear which APIs are supposed to be used by admin or end user and +which is for internal service-to-service APIs communication. + +Problem description +=================== + +Currently, internal service-to-service communication APIs have their +default policy as either admin or project roles which means operators +need to assign the admin or project roles to their service users. +That service user having admin or project role access is poor security +practice as they can perform admin or project level operations. + +Another problem is that APIs which are meant to only be used by internal +services are able to be called by regular users and human admins. Requiring +(and allowing only) a service role for these APIs help avoid intentional +and accidental abuse. + +Use Cases +--------- + +As an operator I want to keep ``service`` role user to access +service-to-service APIs with least privilege. + +Proposed change +=============== + +We need to make sure all the policy rules for internal service-to-service +APIs are default to ``service`` role only. Example: + + +.. code-block:: python + + policy.DocumentedRuleDefault( + name='os_compute_api:os-server-external-events:create', + check_str='role:service', + scope_types=['project'] + ) + +Keystone's ``service`` role is kept outside of the existing role hierarchy +that includes ``admin``, ``member``, and ``reader``. Keeping the ``service`` +role outside the current hierarchy ensures we're following the principle +of least privilege for service accounts. + +We need to make all the service-to-service APIs which are *only* suitable +for services default to ``service`` role only. But we might have some cases +where APIs are both intended for service usage, as well as admin (any other +user role) usage. For such policy rules we need to default them to ``service`` +as well as ``admin`` (or any other user role) role. For example, +'role:admin or role:service' + +As Nova have dropped the system scope implementation, service-to-service +communication with ``service`` role will be done with project scope token +(which is currently done in devstack setup). + +Below APIs policy will be default to ``service`` role: + +* os_compute_api:os-assisted-volume-snapshots:create +* os_compute_api:os-assisted-volume-snapshots:delete +* os_compute_api:os-volumes-attachments:swap +* os_compute_api:os-server-external-events:create + +Alternatives +------------ + +Keep the service-to-service APIs default same as it is and expect operators +to take care of the ``service`` role users access permissions by overriding +it in the policy.yaml. + +Data model impact +----------------- + +None + +REST API impact +--------------- + +Below APIs policy will be default to ``service`` role: + +* os_compute_api:os-assisted-volume-snapshots:create +* os_compute_api:os-assisted-volume-snapshots:delete +* os_compute_api:os-volumes-attachments:swap +* os_compute_api:os-server-external-events:create + +Security impact +--------------- + +Easier to understand service-to-service APIs policy and restricting them to +least privilege. + +Notifications impact +-------------------- + +None + +Other end user impact +--------------------- + +None + +Performance Impact +------------------ + +None + +Other deployer impact +--------------------- + +If service-to-service APIs are used by the admin or end user then make +sure to override the required permission in policy.yaml because by default +they will be accessed by the ``service`` role user only. + +Developer impact +---------------- + +New APIs must add policies that follow the new pattern. + +Upgrade impact +-------------- + +If service-to-service APIs are used by the admin or end user then make +sure to override the required permission in policy.yaml because by default +they will be accessed by the ``service`` role user only. If deployment +overrides these policies then, they need to start considering the new +default policy rules. + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + gmann + +Feature Liaison +--------------- + +Feature liaison: + dansmith + +Work Items +---------- + +* Modify the service-to-service APIs defaults +* Modify policy rule unit tests + +Dependencies +============ + +None + +Testing +======= + +Modify or add the policy unit tests. + +Add a job enabling the new defaults and run the tempest tests to make sure +existing service-service APIs communication work fine. If needed modify the +token used by services as per the new defaults. + +Documentation Impact +==================== + +API Reference should be updated to add all the service-service APIs under +separate section and mention about ``service`` role as their default. + +References +========== + +History +======= + +.. list-table:: Revisions + :header-rows: 1 + + * - Release Name + - Description + * - 2023.1 + - Introduced + * - 2023.2 + - Re-proposed