From 6be442b5531b4b6cecc5f37823c23e794a8e8163 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Tue, 14 May 2024 14:54:42 +0200 Subject: [PATCH 01/25] First parts of the role standards draft Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 152 ++++++++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 Standards/scs-03XX-v1-standard-roles.md diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md new file mode 100644 index 000000000..8f78eca15 --- /dev/null +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -0,0 +1,152 @@ +--- +title: SCS Standard Roles +type: Standard +status: Draft +track: IAM +--- + +## Introduction + +SCS aims to provide a standardized role model for RBAC roles across all supported OpenStack API services that applies sensible and consistent permission sets based on a set list of roles defined by a standard. +It is closely guided by the OpenStack defaults. + +## Terminology + +The following special terms are used throughout this standard document: + +| Term | Meaning | +|---|---| +| API | Application Programming Interface, often referring to the REST API interfaces provided by OpenStack and related services | +| CSP | Cloud Service Provider, provider managing the OpenStack infrastructure | +| RBAC | Role-Based Access Control[^1] established by OpenStack Keystone | + +[^1]: [OpenStack Documentation: Role-Based Access Control Overview](https://static.opendev.org/docs/patrole/latest/rbac-overview.html) + +## Motivation + +The permission settings of OpenStack RBAC roles are configured in service-specific deployment configuration files (usually the respective "`policy.yaml`") in a rather static way and have to be carefully managed. +In contrast to many of OpenStack's IAM and IaaS resources, these settings cannot be changed via its API at runtime. +For this reason it is important to have a secure and sensible default configuration in SCS clouds that is both intuitive and flexible enough to cover all necessary use cases of permission models desired by CSPs and customers. + +## Design Considerations + +One key aspect of the design considerations for this standard is to be as close to the native (upstream) OpenStack role model and role definitions as possible to not introduce unnecessary complexity or divergence from OpenStack. +Meanwhile the standardized roles and permission sets should cover all scenarios and use cases that SCS deems necessary. + +### Scope Enforcement Compatibility + +The API policy library used by OpenStack (oslo.policy) introduced two new [configuration options](https://docs.openstack.org/oslo.policy/latest/configuration/#oslo-policy) during the [ongoing RBAC rework of OpenStack](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html): + +- `enforce_scope` +- `enforce_new_defaults` + +Using those new defaults and scope-enforcing options [will currently break](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#the-issues-we-are-facing-with-scope-concept) orchestration tooling such as **OpenStack Heat** and Tacker. +Due to OpenStack Heat being a service supported by the SCS project, those conflicting options cannot be mandated by a SCS standard. + +Some service-specific role sets currently found in OpenStack services can only be eliminated and streamlined with the general roles when those new options are enabled. +As a result, this standard cannot consider role models dependent on the aforementioned options due to their currently unresolved compatibility issues and must incorporate the service-specific role sets for the time being. +The affected services and roles are documented below. + +#### Barbican Role Set + +The Key Manager component Barbican [established a set of dedicated roles](https://docs.openstack.org/barbican/2024.1/admin/access_control.html#default-policy): + +- key-manager:service-admin +- creator +- observer +- audit + +This set of roles is Barbican-specific and not used by any other API. +It became deprecated during the [RBAC rework](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html) of OpenStack but is still included per default in recent OpenStack releases (as of the 2024.1 release). + +Due to its deprecation it is possible to enable Barbican's use of the already established reader, member and admin roles instead. +This however requires the olso.policy options `enforce_scope` and `enforce_new_default` to be enabled, which are currently non-defaults and break compatibility with orchestration tooling, see above. + +#### Octavia Role Set + +The Load-Balancer-as-a-Service (LBaaS) component Octavia comes with a set of specific roles in its default API policy configuration: + +- load-balancer_observer +- load-balancer_global_observer +- load-balancer_member +- load-balancer_quota_admin +- load-balancer_admin + +This set of roles is Octavia-specific and not used by any other API. +However, Octavia also [officially supports alternative policy configurations](https://docs.openstack.org/octavia/2024.1/configuration/policy.html#openstack-default-roles-policy-override-file) that use the already established reader, member and admin roles instead. + +Using the alternative configurations would streamline Octavia's policies with the rest of the services and reduce complexity as well as ambiguity in the global role model of this standard. + +However, both of the alternative policy files that omit the Octavia-specific roles currently state "The [oslo_policy] `enforce_scope` and `enforce_new_defaults` must be `True`.". +This would mean enabling the new defaults and scope-enforcing options that currently break compatibility with orchestration tooling like explained above. + +### Open questions + +RECOMMENDED + +## Standard + +### Established Roles + +This standard establishes the following roles in SCS clouds. + +Core Roles: + +- reader +- member +- manager +- admin +- service + +Service-specific Roles: + +- key-manager:service-admin +- creator +- observer +- audit +- load-balancer_observer +- load-balancer_global_observer +- load-balancer_member +- load-balancer_quota_admin +- load-balancer_admin +- ResellerAdmin +- heat_stack_user + +#### Role Definitions + +The following overview will explain the roles' purposes and target scopes. +Roles marked as "internal" are roles only meant to be assigned to technical user accounts intended for internal use by OpenStack services. + +Core Roles: + +| Role | Primary Target(s) | Purpose | +|---|---|---| +| reader | customer | read-only access to resources and information in the scope of authentication (e.g. project) | +| member | customer | similar to *reader* but extended by write access to resources in the scope of authentication (e.g. project) | +| manager | customer, CSP | slightly more elevated privileges than *member*, able to manage core resources or settings of a project or domain | +| admin | CSP | cloud-level global administrative access to all resources (cross-domain, cross-project) | +| service | internal | internal technical user role for service communication | + +Service-specific Roles: + +| Service | Role | Primary Target(s) | Purpose | +|---|---|---|---| +| Barbican | audit | customer | allows read-only access to metadata of secrets within a project; does not allow secret retrieval or decryption | +| Barbican | observer | customer | allows read-only access to secrets within a project, including retrieval and decryption | +| Barbican | creator | customer | allows access to, creation and deletion of secrets within a project, including retrieval and decryption | +| Barbican | key-manager:service-admin | CSP | management API access for the cloud administrator, e.g. for project quota settings | +| Octavia | load-balancer_observer | customer | access to read-only APIs | +| Octavia | load-balancer_global_observer | CSP | access to read-only APIs including resources owned by others | +| Octavia | load-balancer_member | customer | access to read and write APIs | +| Octavia | load-balancer_quota_admin | CSP | admin access to quota APIs only, including quota resources owned by others | +| Octavia | load-balancer_admin | CSP | admin access to all LB APIs including resources owned by others | +| Ceilometer | ResellerAdmin | internal | technical user of Ceilometer with access privileges in the object storage API to store statistics for metering | +| Heat | heat_stack_user | internal | assigned to technical user accounts resulting from other resources' creation in Heat templates | + +## Related Documents + +- [OpenStack Governance: Consistent and Secure Default RBAC](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html) + +## Conformance Tests + +Conformance Tests, OPTIONAL From dfc7b046010a0b955200cca9b8dfb384cb8e5552 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Tue, 14 May 2024 17:59:17 +0200 Subject: [PATCH 02/25] Add further details and open question section Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 28 ++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 8f78eca15..4cf8b000f 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -18,6 +18,8 @@ The following special terms are used throughout this standard document: |---|---| | API | Application Programming Interface, often referring to the REST API interfaces provided by OpenStack and related services | | CSP | Cloud Service Provider, provider managing the OpenStack infrastructure | +| IaaS | Infrastructure-as-a-Service | +| IAM | Identity and Access Management | | RBAC | Role-Based Access Control[^1] established by OpenStack Keystone | [^1]: [OpenStack Documentation: Role-Based Access Control Overview](https://static.opendev.org/docs/patrole/latest/rbac-overview.html) @@ -33,6 +35,9 @@ For this reason it is important to have a secure and sensible default configurat One key aspect of the design considerations for this standard is to be as close to the native (upstream) OpenStack role model and role definitions as possible to not introduce unnecessary complexity or divergence from OpenStack. Meanwhile the standardized roles and permission sets should cover all scenarios and use cases that SCS deems necessary. +Due to the high level of modularity and the large amount of available services for OpenStack clouds, this standard cannot address all possible manifestations of OpenStack clouds. +This standard will therefore only cover IaaS APIs and services that are classified as either mandatory or supported by the SCS project. + ### Scope Enforcement Compatibility The API policy library used by OpenStack (oslo.policy) introduced two new [configuration options](https://docs.openstack.org/oslo.policy/latest/configuration/#oslo-policy) during the [ongoing RBAC rework of OpenStack](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html): @@ -82,7 +87,28 @@ This would mean enabling the new defaults and scope-enforcing options that curre ### Open questions -RECOMMENDED +#### Incorporating the new upstream defaults into this standard + +Due to the ongoing RBAC rework in upstream OpenStack[^2], not all changes which are to be introduced by it will be included in the first iteration of this standard to avoid prematurely adopting role and policy definitions which might still change before being stabilized or have unresolved compatibility issues with certain services. + +This results in a need of keeping this standard in sync once the upstream rework finishes. +It is currently unknown when the upstream rework will conclude exactly and how this standard will need to be adjusted as a result. + +This primarily concerns the new scoping and defaults in `oslo.policy`: + +```ini +[oslo_policy] +enforce_new_defaults = True +enforce_scope = True +``` + +As of the time of writing this standard, those options currently default to `False`[^3] for all OpenStack services. +Once those options default to `True` in a future OpenStack release, this standard must be updated to properly account for the resulting changes in policy and role defaults. +Due to the fact that the details on how the remaining compatibility issues will be addressed upstream are still unknown, the full implications on when and how this standard will need to be updated specifically remains an open question. + +[^2]: [OpenStack Technical Committee Governance Documents: Consistent and Secure Default RBAC](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html) + +[^3]: [Current parameter defaults in `oslo_policy/opts.py` (2023-12-11)](https://github.com/openstack/oslo.policy/blob/a1e76258180002b288e64532676ba2bc2d1ec800/oslo_policy/opts.py#L26-L51) ## Standard From 76444ea71f099d6a8fc774ae63b30ea1236e7bd6 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Wed, 15 May 2024 14:20:07 +0200 Subject: [PATCH 03/25] Content additions and rephrasing for better clarity Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 57 ++++++++++++++++--------- 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 4cf8b000f..7db2b0fb0 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -40,7 +40,7 @@ This standard will therefore only cover IaaS APIs and services that are classifi ### Scope Enforcement Compatibility -The API policy library used by OpenStack (oslo.policy) introduced two new [configuration options](https://docs.openstack.org/oslo.policy/latest/configuration/#oslo-policy) during the [ongoing RBAC rework of OpenStack](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html): +The API policy library used by OpenStack (oslo.policy) introduced two new [configuration options](https://docs.openstack.org/oslo.policy/latest/configuration/#oslo-policy) during the ongoing RBAC rework of OpenStack[^2]: - `enforce_scope` - `enforce_new_defaults` @@ -48,8 +48,8 @@ The API policy library used by OpenStack (oslo.policy) introduced two new [confi Using those new defaults and scope-enforcing options [will currently break](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#the-issues-we-are-facing-with-scope-concept) orchestration tooling such as **OpenStack Heat** and Tacker. Due to OpenStack Heat being a service supported by the SCS project, those conflicting options cannot be mandated by a SCS standard. -Some service-specific role sets currently found in OpenStack services can only be eliminated and streamlined with the general roles when those new options are enabled. -As a result, this standard cannot consider role models dependent on the aforementioned options due to their currently unresolved compatibility issues and must incorporate the service-specific role sets for the time being. +Some service-specific role sets currently found in OpenStack services can only be eliminated and streamlined with the general roles (reader, member etc.) when those new options are enabled. +Due to their currently unresolved compatibility issues, this standard cannot consider role models dependent on the those oslo.policy options and must keep incorporating the service-specific role sets for the time being. The affected services and roles are documented below. #### Barbican Role Set @@ -62,7 +62,7 @@ The Key Manager component Barbican [established a set of dedicated roles](https: - audit This set of roles is Barbican-specific and not used by any other API. -It became deprecated during the [RBAC rework](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html) of OpenStack but is still included per default in recent OpenStack releases (as of the 2024.1 release). +It became deprecated during the RBAC rework of OpenStack[^2] but is still included per default in recent OpenStack releases (as of the 2024.1 release). Due to its deprecation it is possible to enable Barbican's use of the already established reader, member and admin roles instead. This however requires the olso.policy options `enforce_scope` and `enforce_new_default` to be enabled, which are currently non-defaults and break compatibility with orchestration tooling, see above. @@ -112,11 +112,13 @@ Due to the fact that the details on how the remaining compatibility issues will ## Standard -### Established Roles +### Roles This standard establishes the following roles in SCS clouds. +**Core Roles** MUST be present in the Identity API at all times. +**Service-specific Roles** MUST be present in the Identity API as long as the corresponding service (denoted in parentheses) is part of the infrastructure. -Core Roles: +**Core Roles:** - reader - member @@ -124,19 +126,19 @@ Core Roles: - admin - service -Service-specific Roles: +**Service-specific Roles:** -- key-manager:service-admin -- creator -- observer -- audit -- load-balancer_observer -- load-balancer_global_observer -- load-balancer_member -- load-balancer_quota_admin -- load-balancer_admin -- ResellerAdmin -- heat_stack_user +- key-manager:service-admin (Barbican) +- creator (Barbican) +- observer (Barbican) +- audit (Barbican) +- load-balancer_observer (Octavia) +- load-balancer_global_observer (Octavia) +- load-balancer_member (Octavia) +- load-balancer_quota_admin (Octavia) +- load-balancer_admin (Octavia) +- ResellerAdmin (Swift + Ceilometer) +- heat_stack_user (Heat) #### Role Definitions @@ -166,12 +168,27 @@ Service-specific Roles: | Octavia | load-balancer_member | customer | access to read and write APIs | | Octavia | load-balancer_quota_admin | CSP | admin access to quota APIs only, including quota resources owned by others | | Octavia | load-balancer_admin | CSP | admin access to all LB APIs including resources owned by others | -| Ceilometer | ResellerAdmin | internal | technical user of Ceilometer with access privileges in the object storage API to store statistics for metering | +| Swift | ResellerAdmin | Ceilometer (internal) | assigned to technical users of Ceilometer to integrate with Swift for access privileges in the object storage API to store statistics for metering | | Heat | heat_stack_user | internal | assigned to technical user accounts resulting from other resources' creation in Heat templates | +### API Policies + +TODO: what does the CSP need to adhere to when it comes to API policy configuration? + ## Related Documents -- [OpenStack Governance: Consistent and Secure Default RBAC](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html) +### SCS Domain Manager standard + +**Description:** SCS standard that describes the Domain Manager role introduced by SCS and its configuration. + +**Link:** [SCS Standards: Domain Manager configuration for Keystone](https://docs.scs.community/standards/scs-0302-v1-domain-manager-role) + +### Consistent and Secure Default RBAC + +**Description:** Upstream rework of the default role definitions and hierarchy across all OpenStack services. +Explains the reasoning for the `enforce_scope` and `enforce_new_defaults` options and the transition process. + +**Link:** [OpenStack Technical Committee Governance Documents: Consistent and Secure Default RBAC](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html) ## Conformance Tests From 717642a03e2b18fb7001b95cc22f3a0e23ba4d87 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Wed, 15 May 2024 16:18:06 +0200 Subject: [PATCH 04/25] Remove reader role and add reasoning Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 7db2b0fb0..53af8ab35 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -52,6 +52,18 @@ Some service-specific role sets currently found in OpenStack services can only b Due to their currently unresolved compatibility issues, this standard cannot consider role models dependent on the those oslo.policy options and must keep incorporating the service-specific role sets for the time being. The affected services and roles are documented below. +#### Core Role Set + +Independently from any service-specific roles, the set of core roles is fundamentally affected by the scope enforcement options as well. + +The proper distinction between reader, member and manager roles is only fully implemented in all services when the `enforce_scope` and `enforce_new_defaults` oslo.policy options are used. +Otherwise the OpenStack APIs will oftentimes fall back to their earlier policy implementations which do not fully differentiate between reader, member and manager. + +This results in more elevated permissions for users possessing the reader role than its role description suggests. +Since this standard cannot mandate or expect the use of the aforementioned oslo.policy options due to their current compatibility issues as stated above, this reduces the usefulness of the reader role and will introduce unexpected behavior when using it. + +Due to this, the standard will omit the reader role in its current state. + #### Barbican Role Set The Key Manager component Barbican [established a set of dedicated roles](https://docs.openstack.org/barbican/2024.1/admin/access_control.html#default-policy): @@ -120,7 +132,6 @@ This standard establishes the following roles in SCS clouds. **Core Roles:** -- reader - member - manager - admin @@ -149,8 +160,7 @@ Core Roles: | Role | Primary Target(s) | Purpose | |---|---|---| -| reader | customer | read-only access to resources and information in the scope of authentication (e.g. project) | -| member | customer | similar to *reader* but extended by write access to resources in the scope of authentication (e.g. project) | +| member | customer | read and write access to resources in the scope of authentication (e.g. project) | | manager | customer, CSP | slightly more elevated privileges than *member*, able to manage core resources or settings of a project or domain | | admin | CSP | cloud-level global administrative access to all resources (cross-domain, cross-project) | | service | internal | internal technical user role for service communication | From acd431cea2be45a1b1b91cb2a4cf57c122018043 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Wed, 15 May 2024 16:35:08 +0200 Subject: [PATCH 05/25] Document necessary future changes to the standard Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 53af8ab35..a56c754d0 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -99,7 +99,7 @@ This would mean enabling the new defaults and scope-enforcing options that curre ### Open questions -#### Incorporating the new upstream defaults into this standard +#### Incorporating future upstream defaults into this standard Due to the ongoing RBAC rework in upstream OpenStack[^2], not all changes which are to be introduced by it will be included in the first iteration of this standard to avoid prematurely adopting role and policy definitions which might still change before being stabilized or have unresolved compatibility issues with certain services. @@ -117,6 +117,13 @@ enforce_scope = True As of the time of writing this standard, those options currently default to `False`[^3] for all OpenStack services. Once those options default to `True` in a future OpenStack release, this standard must be updated to properly account for the resulting changes in policy and role defaults. Due to the fact that the details on how the remaining compatibility issues will be addressed upstream are still unknown, the full implications on when and how this standard will need to be updated specifically remains an open question. +However, at the very least this will most likely result in the following changes to this standard: + +- mandate the use of the new olso.policy options in all APIs +- remove the service-specific roles of Barbican and Octavia from the standard +- add the reader role to the core roles of this standard +- remove the design considerations sections related to the above +- if applicable, update any policy generation workflows to use the new role model [^2]: [OpenStack Technical Committee Governance Documents: Consistent and Secure Default RBAC](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html) From f7513f33516fd993318ee23e135fa1b79896177c Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Wed, 15 May 2024 16:54:03 +0200 Subject: [PATCH 06/25] Add reference to service list standard Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index a56c754d0..576166659 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -194,6 +194,13 @@ TODO: what does the CSP need to adhere to when it comes to API policy configurat ## Related Documents +### SCS Mandatory and Supported IaaS Services + +**Description:** SCS standard that lists mandatory and supported OpenStack APIs for SCS clouds. +This list is decisive for the standard on roles as all applicable services need to be taken into consideration. + +**Link:** TBD + ### SCS Domain Manager standard **Description:** SCS standard that describes the Domain Manager role introduced by SCS and its configuration. From c8885cd65d17aa28067d4974d70221b559eafaab Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Wed, 15 May 2024 18:02:23 +0200 Subject: [PATCH 07/25] Add remark about Barbican inaccessibility for users Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 576166659..6962ec645 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -97,6 +97,15 @@ Using the alternative configurations would streamline Octavia's policies with th However, both of the alternative policy files that omit the Octavia-specific roles currently state "The [oslo_policy] `enforce_scope` and `enforce_new_defaults` must be `True`.". This would mean enabling the new defaults and scope-enforcing options that currently break compatibility with orchestration tooling like explained above. +### Key Manager Role Model + +The OpenStack policy defaults for the Key Manager service Barbican establish service-specific roles as documented above. +Unless the new scoping defaults are used, this leads to users possessing the generic "member" role being unable to access the Key Manager API to create and manage secrets. +This in turn renders encryption features like the volume encryption of OpenStack's volume service unusable for customers unless the corresponding users are assigned the Barbican-specific "creator" role in projects additionally. +This creates unnecessary management overhead on the CSP side and ambiguity for users since the role is only useful in Barbican but its name does not communicate this. + + + ### Open questions #### Incorporating future upstream defaults into this standard From 6a593769c30d072b5153e4c6826aa2a6d8f8583c Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Wed, 15 May 2024 18:03:27 +0200 Subject: [PATCH 08/25] Add test script for checking role presence Signed-off-by: Markus Hentsch --- Tests/iam/iaas-roles/standard-roles-check.py | 132 +++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 Tests/iam/iaas-roles/standard-roles-check.py diff --git a/Tests/iam/iaas-roles/standard-roles-check.py b/Tests/iam/iaas-roles/standard-roles-check.py new file mode 100644 index 000000000..4f40a108e --- /dev/null +++ b/Tests/iam/iaas-roles/standard-roles-check.py @@ -0,0 +1,132 @@ +import argparse +import getpass +import os +import typing + +import openstack + +CORE_ROLES = { + "member", + "manager", + "admin", + "service" +} + +# The dict index key here equals the corresponding endpoint type as per +# Keystone's service catalog. Those roles will only be checked if that +# endpoint type is registered. +# Denoted by a colon, optionally the service name can also be matched against. +SERVICE_ROLES = { + "load-balancer": { + "load-balancer_observer", + "load-balancer_global_observer", + "load-balancer_member", + "load-balancer_quota_admin", + "load-balancer_admin ", + }, + "key-manager": { + "key-manager:service-admin", + "creator", + "observer", + "audit", + }, + "object-store:swift": { + "ResellerAdmin", + }, + "orchestration:heat": { + "heat_stack_user", + } +} + + +def connect(cloud_name: str, password: typing.Optional[str] = None + ) -> openstack.connection.Connection: + """Create a connection to an OpenStack cloud + + :param string cloud_name: + The name of the configuration to load from clouds.yaml. + + :param string password: + Optional password override for the connection. + + :returns: openstack.connnection.Connection + """ + + if password: + return openstack.connect( + cloud=cloud_name, + password=password + ) + else: + return openstack.connect( + cloud=cloud_name, + ) + + +def check_list_of_roles(conn: openstack.connection.Connection, + expected_roles: typing.Iterable[str]) -> None: + actual_roles = [role.name for role in conn.identity.roles()] + for role in expected_roles: + assert role in actual_roles, ( + f"Expected role '{role}' was not found." + ) + print(f"Role '{role}' is present: PASS") + + +def main(): + parser = argparse.ArgumentParser( + description="SCS Standard Roles Conformance Checker") + parser.add_argument( + "--os-cloud", type=str, + help="Name of the cloud from clouds.yaml, alternative " + "to the OS_CLOUD environment variable" + ) + parser.add_argument( + "--ask", + help="Ask for password interactively instead of reading it from the " + "clouds.yaml", + action="store_true" + ) + parser.add_argument( + "--debug", action="store_true", + help="Enable OpenStack SDK debug logging" + ) + args = parser.parse_args() + openstack.enable_logging(debug=args.debug) + + # parse cloud name for lookup in clouds.yaml + cloud = os.environ.get("OS_CLOUD", None) + if args.os_cloud: + cloud = args.os_cloud + assert cloud, ( + "You need to have the OS_CLOUD environment variable set to your " + "cloud name or pass it via --os-cloud" + ) + conn = connect( + cloud, + password=getpass.getpass("Enter password: ") if args.ask else None + ) + service_catalog = [ + (svc.get("type"), svc.get("name")) for svc in conn.service_catalog + ] + + check_list_of_roles(conn, CORE_ROLES) + for service_identifier in SERVICE_ROLES: + if ":" in service_identifier: + # match both service type and service name + svc_type, svc_name = service_identifier.split(":", 1) + if (svc_type, svc_name) not in service_catalog: + # if the service is not present, do not check its roles + continue + else: + # match only service type + if service_identifier not in [svc[0] for svc in service_catalog]: + # if the service is not present, do not check its roles + continue + print(f"INFO: service '{service_identifier}' is present and its " + f"roles will be checked ...") + check_list_of_roles(conn, SERVICE_ROLES[service_identifier]) + + +if __name__ == "__main__": + main() From 5b571b3d42d0b20be4a4acccd19171b7d765fc9b Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Thu, 16 May 2024 16:59:13 +0200 Subject: [PATCH 09/25] Integrate Barbican adjustments Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 28 ++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 6962ec645..74ac33e01 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -100,11 +100,15 @@ This would mean enabling the new defaults and scope-enforcing options that curre ### Key Manager Role Model The OpenStack policy defaults for the Key Manager service Barbican establish service-specific roles as documented above. -Unless the new scoping defaults are used, this leads to users possessing the generic "member" role being unable to access the Key Manager API to create and manage secrets. +Unless the new scoping defaults (`enforce_new_defaults`) are used, this leads to users possessing the generic "member" role being unable to access the Key Manager API to create and manage secrets. This in turn renders encryption features like the volume encryption of OpenStack's volume service unusable for customers unless the corresponding users are assigned the Barbican-specific "creator" role in projects additionally. This creates unnecessary management overhead on the CSP side and ambiguity for users since the role is only useful in Barbican but its name does not communicate this. - +To improve user experience and make the encryption features easily accessible, this standard should adjust the Key Manager API policies to extend permissions referencing the Barbican-specific "creator" role by the "member" role. +This offers users easy access to the Key Manager API and aligns the permission set with the future rework (as per `enforce_new_defaults`), because it will later replace the "creator" role by the "member" role entirely. + +The "creator" role will be kept for compatibility reasons concerning service integration. +For example, the block storage service Cinder usually has a technical user in Keystone possessing the "creator" role in the "service" project. ### Open questions @@ -187,7 +191,7 @@ Service-specific Roles: |---|---|---|---| | Barbican | audit | customer | allows read-only access to metadata of secrets within a project; does not allow secret retrieval or decryption | | Barbican | observer | customer | allows read-only access to secrets within a project, including retrieval and decryption | -| Barbican | creator | customer | allows access to, creation and deletion of secrets within a project, including retrieval and decryption | +| Barbican | creator | customer | allows access to, creation and deletion of secrets within a project, including retrieval and decryption, equal to the member role | | Barbican | key-manager:service-admin | CSP | management API access for the cloud administrator, e.g. for project quota settings | | Octavia | load-balancer_observer | customer | access to read-only APIs | | Octavia | load-balancer_global_observer | CSP | access to read-only APIs including resources owned by others | @@ -201,6 +205,24 @@ Service-specific Roles: TODO: what does the CSP need to adhere to when it comes to API policy configuration? +#### Key Manager API + +For the Key Manager API, the policy rule called "creator" MUST be adjusted to incorporate the "member" role as shown below. +This can be achieved by adding the following entry to a `policy.yaml` for Barbican (usually located at "`/etc/barbican/policy.yaml`"): + +```yaml +"creator": "role:creator or role:member" +``` + +Exemplary contents of a "`/etc/barbican/barbican.conf`": + +```ini +[oslo_policy] +enforce_new_defaults = False +enforce_scope = False +policy_file = policy.yaml +``` + ## Related Documents ### SCS Mandatory and Supported IaaS Services From a0b332a4cb047e7a9ce8a68a17e2047baaae89c0 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Thu, 16 May 2024 17:45:26 +0200 Subject: [PATCH 10/25] Add rationale for keeping the creator role for service accounts Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 1 + 1 file changed, 1 insertion(+) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 74ac33e01..bf70b7de4 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -109,6 +109,7 @@ This offers users easy access to the Key Manager API and aligns the permission s The "creator" role will be kept for compatibility reasons concerning service integration. For example, the block storage service Cinder usually has a technical user in Keystone possessing the "creator" role in the "service" project. +Moving such service accounts to the "member" role could introduce undesired access patterns in other APIs that otherwise don't accept the "creator" role but offer a lot of functionality to the "member" role by default. ### Open questions From 77a7c5ba636b0bf5e1b7ed87010e3c8f31e85177 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Fri, 17 May 2024 10:52:50 +0200 Subject: [PATCH 11/25] Downgrade "manager" role to service-specific roles Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 20 ++++++++++++++++++-- Tests/iam/iaas-roles/standard-roles-check.py | 4 +++- 2 files changed, 21 insertions(+), 3 deletions(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index bf70b7de4..9425d8bba 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -111,6 +111,21 @@ The "creator" role will be kept for compatibility reasons concerning service int For example, the block storage service Cinder usually has a technical user in Keystone possessing the "creator" role in the "service" project. Moving such service accounts to the "member" role could introduce undesired access patterns in other APIs that otherwise don't accept the "creator" role but offer a lot of functionality to the "member" role by default. +### Classification of the "manager" role + +The current RBAC rework in upstream OpenStack[^2] describes a "project-manager" persona utilizing a "manager" role on project scope to perform more privileged operations than "member" (see "Phase 3" of the document). +This role is intended to be used across various OpenStack services. +As of the OpenStack release 2024.1 this role is not implemented in any of the core services yet, only in Ironic with `enforce_new_defaults` enabled[^4]. + +On the other hand, the SCS project is making use of this role to implement a Domain Manager persona (see the [SCS Domain Manager standard under "Related Documents"](#scs-domain-manager-standard)). + +As a result, the "manager" role has no effect outside of the Keystone Identity API until phase 3 of the RBAC rework is implemented upstream and this standard is migrated to the proper use of `enforce_new_defaults`. +As such, it will be handled as a service-specific role for Keystone in this standard, not as a core role. +This is to ensure that the effective scope of the role in SCS clouds is clearly documented and communicated to users. +It might be elevated to a core role in future iterations of the standard when it is implemented in other services. + +[^4]: [Implementation of the "manager" role in Ironic for the 2024.1 release](https://github.com/openstack/ironic/blob/stable/2024.1/ironic/common/policy.py#L76-L82) + ### Open questions #### Incorporating future upstream defaults into this standard @@ -136,6 +151,7 @@ However, at the very least this will most likely result in the following changes - mandate the use of the new olso.policy options in all APIs - remove the service-specific roles of Barbican and Octavia from the standard - add the reader role to the core roles of this standard +- move the manager role from service-specific roles to core roles - remove the design considerations sections related to the above - if applicable, update any policy generation workflows to use the new role model @@ -154,12 +170,12 @@ This standard establishes the following roles in SCS clouds. **Core Roles:** - member -- manager - admin - service **Service-specific Roles:** +- manager (Keystone) - key-manager:service-admin (Barbican) - creator (Barbican) - observer (Barbican) @@ -182,7 +198,6 @@ Core Roles: | Role | Primary Target(s) | Purpose | |---|---|---| | member | customer | read and write access to resources in the scope of authentication (e.g. project) | -| manager | customer, CSP | slightly more elevated privileges than *member*, able to manage core resources or settings of a project or domain | | admin | CSP | cloud-level global administrative access to all resources (cross-domain, cross-project) | | service | internal | internal technical user role for service communication | @@ -190,6 +205,7 @@ Service-specific Roles: | Service | Role | Primary Target(s) | Purpose | |---|---|---|---| +| Keystone | manager | customer, CSP | slightly more elevated privileges than *member*, able to manage core resources or settings of a project or domain; currently this is limited to managing identity resources within a domain | | Barbican | audit | customer | allows read-only access to metadata of secrets within a project; does not allow secret retrieval or decryption | | Barbican | observer | customer | allows read-only access to secrets within a project, including retrieval and decryption | | Barbican | creator | customer | allows access to, creation and deletion of secrets within a project, including retrieval and decryption, equal to the member role | diff --git a/Tests/iam/iaas-roles/standard-roles-check.py b/Tests/iam/iaas-roles/standard-roles-check.py index 4f40a108e..ec928bdb9 100644 --- a/Tests/iam/iaas-roles/standard-roles-check.py +++ b/Tests/iam/iaas-roles/standard-roles-check.py @@ -7,7 +7,6 @@ CORE_ROLES = { "member", - "manager", "admin", "service" } @@ -24,6 +23,9 @@ "load-balancer_quota_admin", "load-balancer_admin ", }, + "identity": { + "manager", + }, "key-manager": { "key-manager:service-admin", "creator", From 8546f359f6a247be00e7c12e759999a8512995cf Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Fri, 17 May 2024 15:25:12 +0200 Subject: [PATCH 12/25] Implement tests for verifying Key Manager role permissions Signed-off-by: Markus Hentsch --- Tests/iam/iaas-roles/standard-roles-check.py | 100 +++++++++++++++++++ 1 file changed, 100 insertions(+) diff --git a/Tests/iam/iaas-roles/standard-roles-check.py b/Tests/iam/iaas-roles/standard-roles-check.py index ec928bdb9..4f11660da 100644 --- a/Tests/iam/iaas-roles/standard-roles-check.py +++ b/Tests/iam/iaas-roles/standard-roles-check.py @@ -65,8 +65,52 @@ def connect(cloud_name: str, password: typing.Optional[str] = None ) +def reconnect_with_role(conn: openstack.connection.Connection, + target_role_name: str + ) -> openstack.connection.Connection: + """ + Uses the existing cloud connection to create a new application credential + in the Identity API limited to the role specified via target_role_name. + Creates a new cloud connection using the application credential and + returns it, effectively scoping the returned connection to the specific + role. + """ + credential_name = f"scs-{target_role_name}-role-credential" + existing_credential = conn.identity.find_application_credential( + conn.current_user_id, + credential_name + ) + if existing_credential: + conn.identity.delete_application_credential( + conn.current_user_id, + existing_credential + ) + app_credential = conn.identity.create_application_credential( + conn.current_user_id, + credential_name, + roles=[{"name": target_role_name}] + ) + + # Open a new connection using the application credential + new_conn = openstack.connect( + region_name=conn.config.config["region"], + auth_type="v3applicationcredential", + auth={ + "auth_url": conn.auth["auth_url"], + "application_credential_id": app_credential.id, + "application_credential_secret": app_credential.secret, + }, + ) + + return new_conn + + def check_list_of_roles(conn: openstack.connection.Connection, expected_roles: typing.Iterable[str]) -> None: + """ + Retrieves the list of roles from the Identity API and verifies that + it contains all role names specified in the given expected_roles list. + """ actual_roles = [role.name for role in conn.identity.roles()] for role in expected_roles: assert role in actual_roles, ( @@ -75,6 +119,60 @@ def check_list_of_roles(conn: openstack.connection.Connection, print(f"Role '{role}' is present: PASS") +def check_key_manager_permissions(conn: openstack.connection.Connection + ) -> None: + """ + Limits the authentication to the "member" role using an application + credentials restricted to that role and verifies that the member role + has sufficient access to the Key Manager API functionality. + """ + secret_name = "scs-member-role-test-secret" + member_conn = reconnect_with_role(conn, "member") + + def _find_secret(secret_name_or_id: str): + """Replacement method for finding secrets. + + Mimicks the behavior of Connection.key_manager.find_secret() + but fixes an issue with the internal implementation raising an + exception due to an unexpected microversion parameter. + """ + secrets = member_conn.key_manager.secrets() + for s in secrets: + if s.name == secret_name_or_id or s.id == secret_name_or_id: + return s + return None + + try: + existing_secret = _find_secret(secret_name) + if existing_secret: + member_conn.key_manager.delete_secret(existing_secret) + + member_conn.key_manager.create_secret( + name=secret_name, + payload_content_type="text/plain", + secret_type="opaque", + payload="foo" + ) + + new_secret = _find_secret(secret_name) + assert new_secret, ( + f"Secret created with name '{secret_name}' was not discoverable by " + f"the user" + ) + member_conn.key_manager.delete_secret(new_secret) + except openstack.exceptions.ForbiddenException as e: + print( + "Users of the 'member' role can use Key Manager API: FAIL" + ) + print( + f"ERROR: {str(e)}" + ) + exit(1) + print( + "Users of the 'member' role can use Key Manager API: PASS" + ) + + def main(): parser = argparse.ArgumentParser( description="SCS Standard Roles Conformance Checker") @@ -129,6 +227,8 @@ def main(): f"roles will be checked ...") check_list_of_roles(conn, SERVICE_ROLES[service_identifier]) + check_key_manager_permissions(conn) + if __name__ == "__main__": main() From 148e3a563c8c0aa1ae79001891d69f0485d77aae Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Fri, 17 May 2024 16:42:54 +0200 Subject: [PATCH 13/25] Add README for test suite Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 6 +- Tests/iam/iaas-roles/README.md | 86 +++++++++++++++++++++++++ 2 files changed, 91 insertions(+), 1 deletion(-) create mode 100644 Tests/iam/iaas-roles/README.md diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 9425d8bba..e014052e5 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -264,4 +264,8 @@ Explains the reasoning for the `enforce_scope` and `enforce_new_defaults` option ## Conformance Tests -Conformance Tests, OPTIONAL +Conformance tests verify that the roles mandated by the standard exist and the Key Manager API adjustments are implemented. + +There is a test suite in [`standard-roles-check.py`](https://github.com/SovereignCloudStack/standards/blob/main/Tests/iam/iaas-roles/standard-roles-check.py). +The test suite connects to the OpenStack API, queries the role list and verifies the behavior of the Key Manager API. +Please consult the associated [README.md](https://github.com/SovereignCloudStack/standards/blob/main/Tests/iam/iaas-roles/README.md) for detailed setup and testing instructions. diff --git a/Tests/iam/iaas-roles/README.md b/Tests/iam/iaas-roles/README.md new file mode 100644 index 000000000..4abbae003 --- /dev/null +++ b/Tests/iam/iaas-roles/README.md @@ -0,0 +1,86 @@ +# Standard Roles Test Suite + +## Test Environment Setup + +### API User Account + +The test suite strictly requires an OpenStack user that possesses the following access rights: + +1. the "`member`" role in the project referenced as authentication target +2. access permissions to the "`list_roles`" in the Identity API + +The second requirement (access to "`list_roles`") is usually not granted to users with the "`member`" role in default configurations and only works for user accounts also possessing the "`admin`" role. +So the test would require an user account possessing both the "`member`" and "`admin`" role. + +One alternative way to address this without granting the "`admin`" role to the test account is to create a dedicated role in the cloud environment which only has access to the role list endpoint and assign it to the user account intended for testing (in addition to the "`member`" role). + +To achieve this, first the role has to be created and assigned: + +```sh +openstack role create scs-conformance-tester +openstack role add --user ... --project ... member +openstack role add --user ... --project ... scs-conformance-tester +``` + +Finally, the policy definition for the role list endpoint has to be extended to allow this role: + +```yaml +"identity:list_roles": "... or role:scs-conformance-tester" +``` + +("`...`" is a placeholder and must be replaced by the current content of the `"identity:list_roles"` rule!) + +The credentials of the resulting user must be specified in the "`clouds.yaml`" accordingly (see below). + +### Test Execution Environment + +To execute the test suite a valid cloud configuration for the OpenStack SDK in the shape of "`clouds.yaml`" is mandatory[^1]. +**The file is expected to be located in the current working directory where the test script is executed unless configured otherwise.** + +[^1]: [OpenStack Documentation: Configuring OpenStack SDK Applications](https://docs.openstack.org/openstacksdk/latest/user/config/configuration.html) + +The test execution environment can be located on any system outside of the cloud infrastructure that has OpenStack API access. +Make sure that the API access is configured properly in "`clouds.yaml`". + +It is recommended to use a Python virtual environment[^2]. +Next, install the OpenStack SDK required by the test suite: + +```bash +pip3 install openstacksdk +``` + +Within this environment execute the test suite. + +[^2]: [Python 3 Documentation: Virtual Environments and Packages](https://docs.python.org/3/tutorial/venv.html) + +## Test Execution + +The test suite is executed as follows: + +```bash +python3 standard-roles-check.py --os-cloud mycloud +``` + +As an alternative to "`--os-cloud`", the "`OS_CLOUD`" environment variable may be specified instead. +The parameter is used to look up the correct cloud configuration in "`clouds.yaml`". +For the example command above, this file should contain a `clouds.mycloud` section like this: + +```yaml +--- +clouds: + mycloud: + auth: + auth_url: ... + ... + ... +``` + +For any further options consult the output of "`python3 standard-roles-check.py --help`". + +### Script Behavior & Test Results + +The script will print all executed tests and their results to `stdout`. + +If all tests pass, the script will return with an exit code of `0`. + +If any test fails, the script will abort, print the failed test to `stdout` and return with a non-zero exit code. From 20e95670b8dd4ed36af535e7f66dff359cc4b5fd Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Fri, 17 May 2024 16:51:25 +0200 Subject: [PATCH 14/25] Cleanup application credential after testing Signed-off-by: Markus Hentsch --- Tests/iam/iaas-roles/standard-roles-check.py | 36 ++++++++++++++------ 1 file changed, 26 insertions(+), 10 deletions(-) diff --git a/Tests/iam/iaas-roles/standard-roles-check.py b/Tests/iam/iaas-roles/standard-roles-check.py index 4f11660da..7fe817031 100644 --- a/Tests/iam/iaas-roles/standard-roles-check.py +++ b/Tests/iam/iaas-roles/standard-roles-check.py @@ -5,6 +5,11 @@ import openstack +# Name of the application credential that will be created during the test +# to temporarily scope the authentication to a specific role for testing +# purposes. +APP_CREDENTIAL_NAME = "scs-member-role-credential" + CORE_ROLES = { "member", "admin", @@ -65,6 +70,23 @@ def connect(cloud_name: str, password: typing.Optional[str] = None ) +def delete_application_credential(conn: openstack.connection.Connection, + credential_name: str) -> None: + existing_credential = conn.identity.find_application_credential( + conn.current_user_id, + credential_name + ) + if existing_credential: + print( + f"INFO: deleting application credential " + f"'{credential_name}' ..." + ) + conn.identity.delete_application_credential( + conn.current_user_id, + existing_credential + ) + + def reconnect_with_role(conn: openstack.connection.Connection, target_role_name: str ) -> openstack.connection.Connection: @@ -75,16 +97,8 @@ def reconnect_with_role(conn: openstack.connection.Connection, returns it, effectively scoping the returned connection to the specific role. """ - credential_name = f"scs-{target_role_name}-role-credential" - existing_credential = conn.identity.find_application_credential( - conn.current_user_id, - credential_name - ) - if existing_credential: - conn.identity.delete_application_credential( - conn.current_user_id, - existing_credential - ) + credential_name = APP_CREDENTIAL_NAME + delete_application_credential(conn, credential_name) app_credential = conn.identity.create_application_credential( conn.current_user_id, credential_name, @@ -168,6 +182,8 @@ def _find_secret(secret_name_or_id: str): f"ERROR: {str(e)}" ) exit(1) + finally: + delete_application_credential(conn, APP_CREDENTIAL_NAME) print( "Users of the 'member' role can use Key Manager API: PASS" ) From 65d72d4a8d7cb8598133ddb4fd7563d75cc039f1 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Fri, 28 Jun 2024 20:18:36 +0200 Subject: [PATCH 15/25] Update remarks about oslo.policy options to reflect latest findings Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index e014052e5..9333313e7 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -46,10 +46,13 @@ The API policy library used by OpenStack (oslo.policy) introduced two new [confi - `enforce_new_defaults` Using those new defaults and scope-enforcing options [will currently break](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#the-issues-we-are-facing-with-scope-concept) orchestration tooling such as **OpenStack Heat** and Tacker. -Due to OpenStack Heat being a service supported by the SCS project, those conflicting options cannot be mandated by a SCS standard. +This must be considered when making decisions in this standard. +Careful evaluation of benefits as well as implications of adopting these changes is necessary. +The new options are not adopted equally across all OpenStack services yet in context of the ongoing rework. Some service-specific role sets currently found in OpenStack services can only be eliminated and streamlined with the general roles (reader, member etc.) when those new options are enabled. -Due to their currently unresolved compatibility issues, this standard cannot consider role models dependent on the those oslo.policy options and must keep incorporating the service-specific role sets for the time being. +Due to their currently unresolved compatibility issues, they cannot be freely adopted without consequences. +If adoption proves to be unfeasible, role models dependent on the those oslo.policy options could not be considered and the service-specific role sets would need to be preserved for the time being. The affected services and roles are documented below. #### Core Role Set @@ -60,9 +63,8 @@ The proper distinction between reader, member and manager roles is only fully im Otherwise the OpenStack APIs will oftentimes fall back to their earlier policy implementations which do not fully differentiate between reader, member and manager. This results in more elevated permissions for users possessing the reader role than its role description suggests. -Since this standard cannot mandate or expect the use of the aforementioned oslo.policy options due to their current compatibility issues as stated above, this reduces the usefulness of the reader role and will introduce unexpected behavior when using it. - -Due to this, the standard will omit the reader role in its current state. +If this standard cannot mandate or expect the use of the aforementioned oslo.policy options due to their current compatibility issues as stated above, the usefulness of the reader role would be limited and unexpected behavior would be introduced when using it. +In such case, the standard should omit the reader role in its current state. #### Barbican Role Set @@ -77,7 +79,7 @@ This set of roles is Barbican-specific and not used by any other API. It became deprecated during the RBAC rework of OpenStack[^2] but is still included per default in recent OpenStack releases (as of the 2024.1 release). Due to its deprecation it is possible to enable Barbican's use of the already established reader, member and admin roles instead. -This however requires the olso.policy options `enforce_scope` and `enforce_new_default` to be enabled, which are currently non-defaults and break compatibility with orchestration tooling, see above. +This however requires the olso.policy options `enforce_scope` and `enforce_new_default` to be enabled. #### Octavia Role Set @@ -95,7 +97,7 @@ However, Octavia also [officially supports alternative policy configurations](ht Using the alternative configurations would streamline Octavia's policies with the rest of the services and reduce complexity as well as ambiguity in the global role model of this standard. However, both of the alternative policy files that omit the Octavia-specific roles currently state "The [oslo_policy] `enforce_scope` and `enforce_new_defaults` must be `True`.". -This would mean enabling the new defaults and scope-enforcing options that currently break compatibility with orchestration tooling like explained above. +This would require the new defaults and scope-enforcing options. ### Key Manager Role Model @@ -143,8 +145,8 @@ enforce_new_defaults = True enforce_scope = True ``` -As of the time of writing this standard, those options currently default to `False`[^3] for all OpenStack services. -Once those options default to `True` in a future OpenStack release, this standard must be updated to properly account for the resulting changes in policy and role defaults. +Not all OpenStack services enable these options yet. +Once those options default to `True` for additional services in a future OpenStack release, this standard must be updated to properly account for the resulting changes in policy and role defaults. Due to the fact that the details on how the remaining compatibility issues will be addressed upstream are still unknown, the full implications on when and how this standard will need to be updated specifically remains an open question. However, at the very least this will most likely result in the following changes to this standard: From 0fde99f5dd7c2d3f87e2603d176aa7376d9bebdc Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Sat, 31 Aug 2024 20:21:55 +0200 Subject: [PATCH 16/25] Address review comments Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 9333313e7..3fd360c61 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -7,8 +7,9 @@ track: IAM ## Introduction -SCS aims to provide a standardized role model for RBAC roles across all supported OpenStack API services that applies sensible and consistent permission sets based on a set list of roles defined by a standard. -It is closely guided by the OpenStack defaults. +SCS aims to provide a standardized role model for Role-Based Access Control (RBAC) across all supported OpenStack API services. +The goal of this standard is to define IaaS roles for SCS clouds with sensible and consistent permission sets. +It is closely guided by the OpenStack defaults to achieve compatibility and interoperability. ## Terminology @@ -26,8 +27,9 @@ The following special terms are used throughout this standard document: ## Motivation -The permission settings of OpenStack RBAC roles are configured in service-specific deployment configuration files (usually the respective "`policy.yaml`") in a rather static way and have to be carefully managed. -In contrast to many of OpenStack's IAM and IaaS resources, these settings cannot be changed via its API at runtime. +The permission settings of OpenStack RBAC roles are preconfigured in the OpenStack API implementations and can be adjusted individually in service-specific deployment configuration files (usually the respective "`policy.yaml`") optionally. +In contrast to many of OpenStack's IAM and IaaS resources however, these settings cannot be changed via its API at runtime, only via configuration files. +Changing these settings can have a wide range of implications and require careful testing and maintenance. For this reason it is important to have a secure and sensible default configuration in SCS clouds that is both intuitive and flexible enough to cover all necessary use cases of permission models desired by CSPs and customers. ## Design Considerations From beb65578f266c9fae034880d4b94f0d90b04e4c4 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Mon, 2 Sep 2024 17:56:06 +0200 Subject: [PATCH 17/25] Update standard to reflect latest changes in SCS and upstream Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 128 ++++++------------------ 1 file changed, 28 insertions(+), 100 deletions(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 3fd360c61..bf84fd241 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -53,9 +53,8 @@ Careful evaluation of benefits as well as implications of adopting these changes The new options are not adopted equally across all OpenStack services yet in context of the ongoing rework. Some service-specific role sets currently found in OpenStack services can only be eliminated and streamlined with the general roles (reader, member etc.) when those new options are enabled. -Due to their currently unresolved compatibility issues, they cannot be freely adopted without consequences. -If adoption proves to be unfeasible, role models dependent on the those oslo.policy options could not be considered and the service-specific role sets would need to be preserved for the time being. -The affected services and roles are documented below. + +[^2]: [OpenStack Technical Committee Governance Documents: Consistent and Secure Default RBAC](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html) #### Core Role Set @@ -78,7 +77,7 @@ The Key Manager component Barbican [established a set of dedicated roles](https: - audit This set of roles is Barbican-specific and not used by any other API. -It became deprecated during the RBAC rework of OpenStack[^2] but is still included per default in recent OpenStack releases (as of the 2024.1 release). +It became deprecated during the RBAC rework of OpenStack[^2]. Due to its deprecation it is possible to enable Barbican's use of the already established reader, member and admin roles instead. This however requires the olso.policy options `enforce_scope` and `enforce_new_default` to be enabled. @@ -108,90 +107,34 @@ Unless the new scoping defaults (`enforce_new_defaults`) are used, this leads to This in turn renders encryption features like the volume encryption of OpenStack's volume service unusable for customers unless the corresponding users are assigned the Barbican-specific "creator" role in projects additionally. This creates unnecessary management overhead on the CSP side and ambiguity for users since the role is only useful in Barbican but its name does not communicate this. -To improve user experience and make the encryption features easily accessible, this standard should adjust the Key Manager API policies to extend permissions referencing the Barbican-specific "creator" role by the "member" role. -This offers users easy access to the Key Manager API and aligns the permission set with the future rework (as per `enforce_new_defaults`), because it will later replace the "creator" role by the "member" role entirely. +To improve user experience and make the encryption features easily accessible, this standard should demand using the new role model and scoping defaults for the Key Manager API. -The "creator" role will be kept for compatibility reasons concerning service integration. -For example, the block storage service Cinder usually has a technical user in Keystone possessing the "creator" role in the "service" project. -Moving such service accounts to the "member" role could introduce undesired access patterns in other APIs that otherwise don't accept the "creator" role but offer a lot of functionality to the "member" role by default. +### Inclusion of the "manager" role -### Classification of the "manager" role - -The current RBAC rework in upstream OpenStack[^2] describes a "project-manager" persona utilizing a "manager" role on project scope to perform more privileged operations than "member" (see "Phase 3" of the document). +The current RBAC rework in upstream OpenStack[^2] describes a "project-manager" persona utilizing a new "manager" role on project scope to perform more privileged operations than "member" (see "Phase 3" of the document). This role is intended to be used across various OpenStack services. -As of the OpenStack release 2024.1 this role is not implemented in any of the core services yet, only in Ironic with `enforce_new_defaults` enabled[^4]. +As of the OpenStack release 2024.1 this role is not implemented in any of the core services yet, only in Ironic with `enforce_new_defaults` enabled[^3]. On the other hand, the SCS project is making use of this role to implement a Domain Manager persona (see the [SCS Domain Manager standard under "Related Documents"](#scs-domain-manager-standard)). +This persona will be available as a native upstream feature in Keystone starting with the 2024.2 release of OpenStack. -As a result, the "manager" role has no effect outside of the Keystone Identity API until phase 3 of the RBAC rework is implemented upstream and this standard is migrated to the proper use of `enforce_new_defaults`. -As such, it will be handled as a service-specific role for Keystone in this standard, not as a core role. -This is to ensure that the effective scope of the role in SCS clouds is clearly documented and communicated to users. -It might be elevated to a core role in future iterations of the standard when it is implemented in other services. - -[^4]: [Implementation of the "manager" role in Ironic for the 2024.1 release](https://github.com/openstack/ironic/blob/stable/2024.1/ironic/common/policy.py#L76-L82) - -### Open questions - -#### Incorporating future upstream defaults into this standard - -Due to the ongoing RBAC rework in upstream OpenStack[^2], not all changes which are to be introduced by it will be included in the first iteration of this standard to avoid prematurely adopting role and policy definitions which might still change before being stabilized or have unresolved compatibility issues with certain services. - -This results in a need of keeping this standard in sync once the upstream rework finishes. -It is currently unknown when the upstream rework will conclude exactly and how this standard will need to be adjusted as a result. - -This primarily concerns the new scoping and defaults in `oslo.policy`: - -```ini -[oslo_policy] -enforce_new_defaults = True -enforce_scope = True -``` +As a result, the "manager" role has no effect outside of the Keystone Identity API until phase 3 of the RBAC rework is implemented upstream but can be used for identity-related functionality in Keystone. -Not all OpenStack services enable these options yet. -Once those options default to `True` for additional services in a future OpenStack release, this standard must be updated to properly account for the resulting changes in policy and role defaults. -Due to the fact that the details on how the remaining compatibility issues will be addressed upstream are still unknown, the full implications on when and how this standard will need to be updated specifically remains an open question. -However, at the very least this will most likely result in the following changes to this standard: - -- mandate the use of the new olso.policy options in all APIs -- remove the service-specific roles of Barbican and Octavia from the standard -- add the reader role to the core roles of this standard -- move the manager role from service-specific roles to core roles -- remove the design considerations sections related to the above -- if applicable, update any policy generation workflows to use the new role model - -[^2]: [OpenStack Technical Committee Governance Documents: Consistent and Secure Default RBAC](https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html) - -[^3]: [Current parameter defaults in `oslo_policy/opts.py` (2023-12-11)](https://github.com/openstack/oslo.policy/blob/a1e76258180002b288e64532676ba2bc2d1ec800/oslo_policy/opts.py#L26-L51) +[^3]: [Implementation of the "manager" role in Ironic for the 2024.1 release](https://github.com/openstack/ironic/blob/stable/2024.1/ironic/common/policy.py#L76-L82) ## Standard ### Roles -This standard establishes the following roles in SCS clouds. -**Core Roles** MUST be present in the Identity API at all times. -**Service-specific Roles** MUST be present in the Identity API as long as the corresponding service (denoted in parentheses) is part of the infrastructure. - -**Core Roles:** +This standard establishes the following default roles in SCS clouds. +The roles mentioned below MUST be present in the Identity API at all times. +- reader - member +- manager - admin - service -**Service-specific Roles:** - -- manager (Keystone) -- key-manager:service-admin (Barbican) -- creator (Barbican) -- observer (Barbican) -- audit (Barbican) -- load-balancer_observer (Octavia) -- load-balancer_global_observer (Octavia) -- load-balancer_member (Octavia) -- load-balancer_quota_admin (Octavia) -- load-balancer_admin (Octavia) -- ResellerAdmin (Swift + Ceilometer) -- heat_stack_user (Heat) - #### Role Definitions The following overview will explain the roles' purposes and target scopes. @@ -201,49 +144,34 @@ Core Roles: | Role | Primary Target(s) | Purpose | |---|---|---| +| reader | customer | read-only access to resources in the scope of authentication (e.g. project) | | member | customer | read and write access to resources in the scope of authentication (e.g. project) | +| manager | customer | identity self-service capability within a domain, to assign/revoke roles between users, groups and projects | | admin | CSP | cloud-level global administrative access to all resources (cross-domain, cross-project) | | service | internal | internal technical user role for service communication | -Service-specific Roles: - -| Service | Role | Primary Target(s) | Purpose | -|---|---|---|---| -| Keystone | manager | customer, CSP | slightly more elevated privileges than *member*, able to manage core resources or settings of a project or domain; currently this is limited to managing identity resources within a domain | -| Barbican | audit | customer | allows read-only access to metadata of secrets within a project; does not allow secret retrieval or decryption | -| Barbican | observer | customer | allows read-only access to secrets within a project, including retrieval and decryption | -| Barbican | creator | customer | allows access to, creation and deletion of secrets within a project, including retrieval and decryption, equal to the member role | -| Barbican | key-manager:service-admin | CSP | management API access for the cloud administrator, e.g. for project quota settings | -| Octavia | load-balancer_observer | customer | access to read-only APIs | -| Octavia | load-balancer_global_observer | CSP | access to read-only APIs including resources owned by others | -| Octavia | load-balancer_member | customer | access to read and write APIs | -| Octavia | load-balancer_quota_admin | CSP | admin access to quota APIs only, including quota resources owned by others | -| Octavia | load-balancer_admin | CSP | admin access to all LB APIs including resources owned by others | -| Swift | ResellerAdmin | Ceilometer (internal) | assigned to technical users of Ceilometer to integrate with Swift for access privileges in the object storage API to store statistics for metering | -| Heat | heat_stack_user | internal | assigned to technical user accounts resulting from other resources' creation in Heat templates | - -### API Policies - -TODO: what does the CSP need to adhere to when it comes to API policy configuration? +### API configuration -#### Key Manager API +All API services MUST be configured to use the Secure RBAC role model by enabling `enforce_new_defaults` and `enforce_scope` of the oslo.policy library. -For the Key Manager API, the policy rule called "creator" MUST be adjusted to incorporate the "member" role as shown below. -This can be achieved by adding the following entry to a `policy.yaml` for Barbican (usually located at "`/etc/barbican/policy.yaml`"): +If custom policy rules to any API by a CSP, the following MUST be adhered to: -```yaml -"creator": "role:creator or role:member" -``` +1. The `policy_file` option of the oslo.policy library MUST be set to the name of the policy override file and not rely on default paths. +2. The custom policy rules MUST NOT extend the privileges of the roles mentioned in this standard. -Exemplary contents of a "`/etc/barbican/barbican.conf`": +Example configuration entries: ```ini [oslo_policy] -enforce_new_defaults = False -enforce_scope = False +enforce_new_defaults = True +enforce_scope = True policy_file = policy.yaml ``` +#### API Policies + +TODO: what does the CSP need to adhere to when it comes to API policy configuration? + ## Related Documents ### SCS Mandatory and Supported IaaS Services From df703551bbc4093b586c6c029b588635b4962873 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Mon, 9 Sep 2024 14:52:48 +0200 Subject: [PATCH 18/25] Add more regulation to policy rules, add Octavia quirks Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index bf84fd241..30312020d 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -154,10 +154,7 @@ Core Roles: All API services MUST be configured to use the Secure RBAC role model by enabling `enforce_new_defaults` and `enforce_scope` of the oslo.policy library. -If custom policy rules to any API by a CSP, the following MUST be adhered to: - -1. The `policy_file` option of the oslo.policy library MUST be set to the name of the policy override file and not rely on default paths. -2. The custom policy rules MUST NOT extend the privileges of the roles mentioned in this standard. +If custom policy rules are added to an API by a CSP the `policy_file` option of the oslo.policy library SHOULD be explicitly set to the name of the policy override file and not rely on the corresponding default path. Example configuration entries: @@ -170,7 +167,15 @@ policy_file = policy.yaml #### API Policies -TODO: what does the CSP need to adhere to when it comes to API policy configuration? +The following applies to all APIs that use RBAC policies: + +- Custom policy rules MUST NOT extend the privileges of the core roles mentioned in this standard beyond their default permissions. +- If roles with custom permission sets are required, new roles and corresponding policies MAY be added as long as their names differ from the core roles and they do not impact the core roles. + +The following applies only to the Octavia v2 LBaaS API: + +- The scoping-compatible variant of [OpenStack Default Roles Policy Override File](https://docs.openstack.org/octavia/2024.1/configuration/policy.html#openstack-default-roles-policy-override-file) MUST be used as a base to align the LBaaS API with the standardized reader, member and admin role set. + As of the 2024.1 release of Octavia, this template is provided as [keystone_default_roles_scoped-policy.yaml](https://github.com/openstack/octavia/blob/stable/2024.1/etc/policy/keystone_default_roles_scoped-policy.yaml). ## Related Documents From dca05da141babadc706dcb38945ae0e9a2741d2c Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Thu, 19 Sep 2024 17:14:40 +0200 Subject: [PATCH 19/25] Update test instructions to re-use the manager role if possible Signed-off-by: Markus Hentsch --- Tests/iam/iaas-roles/README.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Tests/iam/iaas-roles/README.md b/Tests/iam/iaas-roles/README.md index 4abbae003..94570e569 100644 --- a/Tests/iam/iaas-roles/README.md +++ b/Tests/iam/iaas-roles/README.md @@ -9,10 +9,15 @@ The test suite strictly requires an OpenStack user that possesses the following 1. the "`member`" role in the project referenced as authentication target 2. access permissions to the "`list_roles`" in the Identity API -The second requirement (access to "`list_roles`") is usually not granted to users with the "`member`" role in default configurations and only works for user accounts also possessing the "`admin`" role. -So the test would require an user account possessing both the "`member`" and "`admin`" role. +The second requirement (access to "`list_roles`") is usually not granted to users with the "`member`" role in default configurations and only works for user accounts also possessing the "`manager`" role in the domain. +So the test would require an user account possessing both the "`member`" role in a project as well as the "`manager`" role in the domain. -One alternative way to address this without granting the "`admin`" role to the test account is to create a dedicated role in the cloud environment which only has access to the role list endpoint and assign it to the user account intended for testing (in addition to the "`member`" role). +Note that the "`manager`" role only works this way starting with OpenStack Keystone 2024.2. +If an older Keystone release is used, see the alternative instructions below. + +#### Alternative using a dedicated role + +One alternative way to address this is for older Keystone releases is to create a dedicated role in the cloud environment which only has access to the role list endpoint and assign it to the user account intended for testing (in addition to the "`member`" role). To achieve this, first the role has to be created and assigned: @@ -22,7 +27,8 @@ openstack role add --user ... --project ... member openstack role add --user ... --project ... scs-conformance-tester ``` -Finally, the policy definition for the role list endpoint has to be extended to allow this role: +Finally, the Keystone API policy definition for the role list endpoint has to be extended to allow this role. +The following is an example entry for `/etc/keystone/policy.yaml` of the Keystone service: ```yaml "identity:list_roles": "... or role:scs-conformance-tester" From 1557c087e5ecb69558de065e5495b3507f55a4a5 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Thu, 19 Sep 2024 17:15:10 +0200 Subject: [PATCH 20/25] Add remark about the standard being applicable to 2024.2 and later Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 30312020d..ce5cb515e 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -11,6 +11,12 @@ SCS aims to provide a standardized role model for Role-Based Access Control (RBA The goal of this standard is to define IaaS roles for SCS clouds with sensible and consistent permission sets. It is closely guided by the OpenStack defaults to achieve compatibility and interoperability. +:::note + +The standard described below is only applicable to OpenStack releases 2024.2 or later. + +::: + ## Terminology The following special terms are used throughout this standard document: From 67a4a1df1116786f9f05ed20b99796dde0185794 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Thu, 19 Sep 2024 17:15:52 +0200 Subject: [PATCH 21/25] Improve phrasing Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index ce5cb515e..412908a6f 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -33,10 +33,10 @@ The following special terms are used throughout this standard document: ## Motivation -The permission settings of OpenStack RBAC roles are preconfigured in the OpenStack API implementations and can be adjusted individually in service-specific deployment configuration files (usually the respective "`policy.yaml`") optionally. +The permission settings of OpenStack RBAC roles are preconfigured in the OpenStack API implementations and can optionally be adjusted in service-specific deployment configuration files (usually the respective "`policy.yaml`") individually. In contrast to many of OpenStack's IAM and IaaS resources however, these settings cannot be changed via its API at runtime, only via configuration files. -Changing these settings can have a wide range of implications and require careful testing and maintenance. -For this reason it is important to have a secure and sensible default configuration in SCS clouds that is both intuitive and flexible enough to cover all necessary use cases of permission models desired by CSPs and customers. +Changing these settings can also have a wide range of implications and requires careful testing and maintenance. +For these reasons it is important to have a secure and sensible default configuration in SCS clouds that is both intuitive and flexible enough to cover all necessary use cases of permission models desired by CSPs and customers. ## Design Considerations From 2af152eb2109fa089a76498cc26d373aac336e94 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Thu, 19 Sep 2024 17:16:08 +0200 Subject: [PATCH 22/25] Move role overview to design considerations Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 30 ++++++++++++------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 412908a6f..1da37f032 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -46,6 +46,21 @@ Meanwhile the standardized roles and permission sets should cover all scenarios Due to the high level of modularity and the large amount of available services for OpenStack clouds, this standard cannot address all possible manifestations of OpenStack clouds. This standard will therefore only cover IaaS APIs and services that are classified as either mandatory or supported by the SCS project. +### Core Roles + +The following overview will list the roles which are considered core roles by this standard and explain their purposes as well as target scopes. +Roles marked as "internal" are roles only meant to be assigned to technical user accounts intended for internal use by OpenStack services. + +Core Roles: + +| Role | Primary Target(s) | Purpose | +|---|---|---| +| reader | customer | read-only access to resources in the scope of authentication (e.g. project) | +| member | customer | read and write access to resources in the scope of authentication (e.g. project) | +| manager | customer | identity self-service capability within a domain, to assign/revoke roles between users, groups and projects | +| admin | CSP | cloud-level global administrative access to all resources (cross-domain, cross-project) | +| service | internal | internal technical user role for service communication | + ### Scope Enforcement Compatibility The API policy library used by OpenStack (oslo.policy) introduced two new [configuration options](https://docs.openstack.org/oslo.policy/latest/configuration/#oslo-policy) during the ongoing RBAC rework of OpenStack[^2]: @@ -141,21 +156,6 @@ The roles mentioned below MUST be present in the Identity API at all times. - admin - service -#### Role Definitions - -The following overview will explain the roles' purposes and target scopes. -Roles marked as "internal" are roles only meant to be assigned to technical user accounts intended for internal use by OpenStack services. - -Core Roles: - -| Role | Primary Target(s) | Purpose | -|---|---|---| -| reader | customer | read-only access to resources in the scope of authentication (e.g. project) | -| member | customer | read and write access to resources in the scope of authentication (e.g. project) | -| manager | customer | identity self-service capability within a domain, to assign/revoke roles between users, groups and projects | -| admin | CSP | cloud-level global administrative access to all resources (cross-domain, cross-project) | -| service | internal | internal technical user role for service communication | - ### API configuration All API services MUST be configured to use the Secure RBAC role model by enabling `enforce_new_defaults` and `enforce_scope` of the oslo.policy library. From ed3b75540eab7dbb29e44cbfcfbc489bbb56ff6b Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Mon, 30 Sep 2024 11:18:17 +0200 Subject: [PATCH 23/25] Remove paragraph about Barbican creator role ... it is part of the SCS Key Manager standard now. Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 9 --------- 1 file changed, 9 deletions(-) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 1da37f032..8aa3e9894 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -121,15 +121,6 @@ Using the alternative configurations would streamline Octavia's policies with th However, both of the alternative policy files that omit the Octavia-specific roles currently state "The [oslo_policy] `enforce_scope` and `enforce_new_defaults` must be `True`.". This would require the new defaults and scope-enforcing options. -### Key Manager Role Model - -The OpenStack policy defaults for the Key Manager service Barbican establish service-specific roles as documented above. -Unless the new scoping defaults (`enforce_new_defaults`) are used, this leads to users possessing the generic "member" role being unable to access the Key Manager API to create and manage secrets. -This in turn renders encryption features like the volume encryption of OpenStack's volume service unusable for customers unless the corresponding users are assigned the Barbican-specific "creator" role in projects additionally. -This creates unnecessary management overhead on the CSP side and ambiguity for users since the role is only useful in Barbican but its name does not communicate this. - -To improve user experience and make the encryption features easily accessible, this standard should demand using the new role model and scoping defaults for the Key Manager API. - ### Inclusion of the "manager" role The current RBAC rework in upstream OpenStack[^2] describes a "project-manager" persona utilizing a new "manager" role on project scope to perform more privileged operations than "member" (see "Phase 3" of the document). From 5bfe232ed3ec91b3d6abd06d6ed298758765b734 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Mon, 30 Sep 2024 11:26:03 +0200 Subject: [PATCH 24/25] Reference the Key Manager standard in related documents Signed-off-by: Markus Hentsch --- Standards/scs-03XX-v1-standard-roles.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Standards/scs-03XX-v1-standard-roles.md b/Standards/scs-03XX-v1-standard-roles.md index 8aa3e9894..2a112a871 100644 --- a/Standards/scs-03XX-v1-standard-roles.md +++ b/Standards/scs-03XX-v1-standard-roles.md @@ -189,6 +189,12 @@ This list is decisive for the standard on roles as all applicable services need **Link:** [SCS Standards: Domain Manager configuration for Keystone](https://docs.scs.community/standards/scs-0302-v1-domain-manager-role) +### SCS Key Manager standard role adjustment + +**Description:** Implementation notes of the [SCS Key Manager standard](https://github.com/SovereignCloudStack/standards/blob/main/Standards/scs-0116-v1-key-manager-standard.md) that describe a policy adjustment to redirect the "creator" role to the "member" role for Key Manager setups not yet using the `enforce_new_defaults` option in order to enable generic project members to manage secrets and access encryption functionalities. + +**Link:** [SCS Standards: Key Manager Standard Implementation Notes](https://github.com/SovereignCloudStack/standards/blob/main/Standards/scs-0116-w1-key-manager-implementation-testing.md#policies) + ### Consistent and Secure Default RBAC **Description:** Upstream rework of the default role definitions and hierarchy across all OpenStack services. From 688da00d2acb05ba971a68b20687f7be1dcc7fc5 Mon Sep 17 00:00:00 2001 From: Markus Hentsch Date: Mon, 30 Sep 2024 11:46:07 +0200 Subject: [PATCH 25/25] Remove outdated tests from test script Signed-off-by: Markus Hentsch --- Tests/iam/iaas-roles/standard-roles-check.py | 160 +------------------ 1 file changed, 1 insertion(+), 159 deletions(-) diff --git a/Tests/iam/iaas-roles/standard-roles-check.py b/Tests/iam/iaas-roles/standard-roles-check.py index 7fe817031..e0c98b337 100644 --- a/Tests/iam/iaas-roles/standard-roles-check.py +++ b/Tests/iam/iaas-roles/standard-roles-check.py @@ -5,46 +5,13 @@ import openstack -# Name of the application credential that will be created during the test -# to temporarily scope the authentication to a specific role for testing -# purposes. -APP_CREDENTIAL_NAME = "scs-member-role-credential" - CORE_ROLES = { + "reader", "member", "admin", "service" } -# The dict index key here equals the corresponding endpoint type as per -# Keystone's service catalog. Those roles will only be checked if that -# endpoint type is registered. -# Denoted by a colon, optionally the service name can also be matched against. -SERVICE_ROLES = { - "load-balancer": { - "load-balancer_observer", - "load-balancer_global_observer", - "load-balancer_member", - "load-balancer_quota_admin", - "load-balancer_admin ", - }, - "identity": { - "manager", - }, - "key-manager": { - "key-manager:service-admin", - "creator", - "observer", - "audit", - }, - "object-store:swift": { - "ResellerAdmin", - }, - "orchestration:heat": { - "heat_stack_user", - } -} - def connect(cloud_name: str, password: typing.Optional[str] = None ) -> openstack.connection.Connection: @@ -70,55 +37,6 @@ def connect(cloud_name: str, password: typing.Optional[str] = None ) -def delete_application_credential(conn: openstack.connection.Connection, - credential_name: str) -> None: - existing_credential = conn.identity.find_application_credential( - conn.current_user_id, - credential_name - ) - if existing_credential: - print( - f"INFO: deleting application credential " - f"'{credential_name}' ..." - ) - conn.identity.delete_application_credential( - conn.current_user_id, - existing_credential - ) - - -def reconnect_with_role(conn: openstack.connection.Connection, - target_role_name: str - ) -> openstack.connection.Connection: - """ - Uses the existing cloud connection to create a new application credential - in the Identity API limited to the role specified via target_role_name. - Creates a new cloud connection using the application credential and - returns it, effectively scoping the returned connection to the specific - role. - """ - credential_name = APP_CREDENTIAL_NAME - delete_application_credential(conn, credential_name) - app_credential = conn.identity.create_application_credential( - conn.current_user_id, - credential_name, - roles=[{"name": target_role_name}] - ) - - # Open a new connection using the application credential - new_conn = openstack.connect( - region_name=conn.config.config["region"], - auth_type="v3applicationcredential", - auth={ - "auth_url": conn.auth["auth_url"], - "application_credential_id": app_credential.id, - "application_credential_secret": app_credential.secret, - }, - ) - - return new_conn - - def check_list_of_roles(conn: openstack.connection.Connection, expected_roles: typing.Iterable[str]) -> None: """ @@ -133,62 +51,6 @@ def check_list_of_roles(conn: openstack.connection.Connection, print(f"Role '{role}' is present: PASS") -def check_key_manager_permissions(conn: openstack.connection.Connection - ) -> None: - """ - Limits the authentication to the "member" role using an application - credentials restricted to that role and verifies that the member role - has sufficient access to the Key Manager API functionality. - """ - secret_name = "scs-member-role-test-secret" - member_conn = reconnect_with_role(conn, "member") - - def _find_secret(secret_name_or_id: str): - """Replacement method for finding secrets. - - Mimicks the behavior of Connection.key_manager.find_secret() - but fixes an issue with the internal implementation raising an - exception due to an unexpected microversion parameter. - """ - secrets = member_conn.key_manager.secrets() - for s in secrets: - if s.name == secret_name_or_id or s.id == secret_name_or_id: - return s - return None - - try: - existing_secret = _find_secret(secret_name) - if existing_secret: - member_conn.key_manager.delete_secret(existing_secret) - - member_conn.key_manager.create_secret( - name=secret_name, - payload_content_type="text/plain", - secret_type="opaque", - payload="foo" - ) - - new_secret = _find_secret(secret_name) - assert new_secret, ( - f"Secret created with name '{secret_name}' was not discoverable by " - f"the user" - ) - member_conn.key_manager.delete_secret(new_secret) - except openstack.exceptions.ForbiddenException as e: - print( - "Users of the 'member' role can use Key Manager API: FAIL" - ) - print( - f"ERROR: {str(e)}" - ) - exit(1) - finally: - delete_application_credential(conn, APP_CREDENTIAL_NAME) - print( - "Users of the 'member' role can use Key Manager API: PASS" - ) - - def main(): parser = argparse.ArgumentParser( description="SCS Standard Roles Conformance Checker") @@ -222,28 +84,8 @@ def main(): cloud, password=getpass.getpass("Enter password: ") if args.ask else None ) - service_catalog = [ - (svc.get("type"), svc.get("name")) for svc in conn.service_catalog - ] check_list_of_roles(conn, CORE_ROLES) - for service_identifier in SERVICE_ROLES: - if ":" in service_identifier: - # match both service type and service name - svc_type, svc_name = service_identifier.split(":", 1) - if (svc_type, svc_name) not in service_catalog: - # if the service is not present, do not check its roles - continue - else: - # match only service type - if service_identifier not in [svc[0] for svc in service_catalog]: - # if the service is not present, do not check its roles - continue - print(f"INFO: service '{service_identifier}' is present and its " - f"roles will be checked ...") - check_list_of_roles(conn, SERVICE_ROLES[service_identifier]) - - check_key_manager_permissions(conn) if __name__ == "__main__":