From 95a474e07d2cb3e29dd8fafbe50d5d05fd38abcd Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Tue, 11 Feb 2025 14:43:15 +0100 Subject: [PATCH 01/11] feat: Rework domain-manager standard Life shows that not all CSPs are capable to adopt the domain manager requirement due to certain architecture decisions or security requirement. Suggest a rework that splits requirements into mandatory and recommended. Signed-off-by: Artem Goncharov --- Standards/scs-0302-v2-domain-manager-role.md | 143 +++++++++++++++++++ 1 file changed, 143 insertions(+) create mode 100644 Standards/scs-0302-v2-domain-manager-role.md diff --git a/Standards/scs-0302-v2-domain-manager-role.md b/Standards/scs-0302-v2-domain-manager-role.md new file mode 100644 index 000000000..e3b46581d --- /dev/null +++ b/Standards/scs-0302-v2-domain-manager-role.md @@ -0,0 +1,143 @@ +--- +title: Domain Manager adoption notes +type: Standard +track: IAM +status: Draft +replaces: scs-0302-v1-domain-manager-role.md +--- + +## Introduction + +After the domain manager persona has been implemented certain issues in the +standard adoption and verification started being raised by CSPs: + +- Not every CSP is using domains to separate customers. + +- CSP may rely on the Identity federation in which case it is impossible or is +prohibited to manage identities on OpenStack side (OpenStack is a service +provider and not an identity provider). + +- CSP may customize authorization policies in a different way so that domain +manager can not be implemented by simply reusing the upstream implementation. + +As such simple enforcement of the Domain Manager persona can not be achieved. + +This standard clarifies base standard and splits requirements into recommended +and mandatory to provide better granularity while still giving guidance with +the goal to provide a smooth user experience for the end users. + +Requiring customer to use CSP specific APIs to manage identity data is +contradicting with the idea of certification as such. It hinders customers from +having a smooth user experience across different cloud providers forcing them +to adapt their management strategies on such clouds. Moreover it represent a +lock-in what is contradicting with the idea of SovereignCloudStack. + +### Mandatory capabilities + +#### Assign roles to users/group on projects/domain + +One of the main initial concerns of the Domain Manager was the ability of the +customer to manage user permissions in a self-service manner. OpenStack +Keystone provides an easy possibility to smoothly integrate role assignments +with arbitrary external systems in a transparent way (a role assignment backend +plugin can be provided to persist assignments in any external system). As such +this capability MUST be supported by the CSP using OpenStack APIs or role +assignments. + +#### Project creation + +Another important requirement was to provide self-service capability for +customers to create projects as desired without requesting CSP support. This +capability MUST be available using native cloud APIs. + +#### Project editing + +Customer must be able to activate or deactivate project access without +requesting CSP support. This capability provides possibility to temporarily +disable users to authorize into certain project by modifying`enabled` property +of the project. Further control of the project name, description, options and +tags MUST be provided to the customer using native Keystone API. + +:::info + +Project deletion using Keystone API is not mandatory since CSP may have certain +expectations on the resources cleanup. This requirement is described in detail +in a dedicated chapter. + +::: + +### Recommended capabilities + +Relying on the Identity federation conceptually changes ways of identity +resource management. This makes it impossible to fulfill them as MUST +requirements. This chapter describes remaining capabilities of the initial +Domain Manager as SHOULD implement. + +#### Domains usage + +It is strongly suggested to rely on the Domain concept of Keystone to implement +multi-tenancy. + +Usage of domains by itself allows to implement form of self-service management +by the customer. Only identity resources are owned by domains (with projects +being also identity resources). Other services use projects to for resources +isolation. They do not need to be domain aware. + +Using domains allows implementing [domain +limits](https://docs.openstack.org/keystone/latest/admin/unified-limits.html#domain-limits) +which allow to set a global resources limit for the customer. Without domains +specific limits artificial control of the overall customer consumption must be +implemented. + +#### User management + +User management (creation, activation, deactivation, deletion) SHOULD be +possible using OpenStack APIs. + +When an external IdP is being used (IdP federation) there is still an +expectation that local users may be required by customers. As such creation of +users (pre-creating federated users or regular local users) within customer +domain SHOULD me possible. Keystone does not allow certain operations on +federated users (i.e. password change, MFA, name) as such allowing customers to +manage users using OpenStack APIs should not conflict with any additional +requirements. + +Security requirements on the customer side or on the CSP side to only allow +federated users to consume platform services was used as the limitating factor +forcing degrading of the capability requirement. + +#### Group management + +Management of groups SHOULD be possible using OpenStack APIs. + +In case of federated Identities there it is possible that groups on the IdP +side do not match groups on the cloud provider side. In addition to that there +might be a need to combine federated and local users. This would only be +possible when groups are managed by the OpenStack. + +It is advised to keep user groups as mapped entities between external systems +of CSP and Keystone. Upon user login (or using SCIM) user group relation may be +synchronized between both platforms. + +#### Project deletion + +As described above project deletion may be implemented differently by CSPs. +There are few ways of achieving that: + +- Forbid project deletion when resources (i.e. VMs) are still provisioned +inside of those projects. This scenario assumes that the customer is +responsible for cleaning projects before their deletion. + +- Automatically purge all project resources by the CSP when project deletion +request is received. In this scenario CSP is implementing custom functionality +to delete all resources before deleting the project. + +- Leave orphant resources. In this scenario project is being deleted by the API +with custom cleanup procedures being responsible for dropping orphant resources. + +Leaving orphant resources MAY NOT be allowed. + +Forbidding project deletion making customer responsible for the cleanup SHOULD +be preferred since it allows preventing the accidental deletion of the +resources. Supplementary methods for purging project resources MAY be offered by +the CSP. From 8f268f371b2cfb6e0dc963388cda5af14eb00a9c Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:22:42 +0100 Subject: [PATCH 02/11] Update Standards/scs-0302-v2-domain-manager-role.md Co-authored-by: Felix Kronlage-Dammers Signed-off-by: Artem Goncharov --- Standards/scs-0302-v2-domain-manager-role.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-0302-v2-domain-manager-role.md b/Standards/scs-0302-v2-domain-manager-role.md index e3b46581d..07419e5a4 100644 --- a/Standards/scs-0302-v2-domain-manager-role.md +++ b/Standards/scs-0302-v2-domain-manager-role.md @@ -27,7 +27,7 @@ and mandatory to provide better granularity while still giving guidance with the goal to provide a smooth user experience for the end users. Requiring customer to use CSP specific APIs to manage identity data is -contradicting with the idea of certification as such. It hinders customers from +contradicting the idea of standardization as such. It hinders customers from having a smooth user experience across different cloud providers forcing them to adapt their management strategies on such clouds. Moreover it represent a lock-in what is contradicting with the idea of SovereignCloudStack. From 540648270a9ccd8d42050289a5781e5eb32cd718 Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:22:50 +0100 Subject: [PATCH 03/11] Update Standards/scs-0302-v2-domain-manager-role.md Co-authored-by: Felix Kronlage-Dammers Signed-off-by: Artem Goncharov --- Standards/scs-0302-v2-domain-manager-role.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-0302-v2-domain-manager-role.md b/Standards/scs-0302-v2-domain-manager-role.md index 07419e5a4..6daabd44e 100644 --- a/Standards/scs-0302-v2-domain-manager-role.md +++ b/Standards/scs-0302-v2-domain-manager-role.md @@ -54,7 +54,7 @@ capability MUST be available using native cloud APIs. Customer must be able to activate or deactivate project access without requesting CSP support. This capability provides possibility to temporarily -disable users to authorize into certain project by modifying`enabled` property +disable users to authorize into certain project by modifying `enabled` property of the project. Further control of the project name, description, options and tags MUST be provided to the customer using native Keystone API. From a2408e948e5d30370aebe4797a216ae389ae4a2d Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:22:59 +0100 Subject: [PATCH 04/11] Update Standards/scs-0302-v2-domain-manager-role.md Co-authored-by: Felix Kronlage-Dammers Signed-off-by: Artem Goncharov --- Standards/scs-0302-v2-domain-manager-role.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-0302-v2-domain-manager-role.md b/Standards/scs-0302-v2-domain-manager-role.md index 6daabd44e..e43f6bca6 100644 --- a/Standards/scs-0302-v2-domain-manager-role.md +++ b/Standards/scs-0302-v2-domain-manager-role.md @@ -78,7 +78,7 @@ Domain Manager as SHOULD implement. It is strongly suggested to rely on the Domain concept of Keystone to implement multi-tenancy. -Usage of domains by itself allows to implement form of self-service management +Usage of domains by itself allows to implement a form of self-service management by the customer. Only identity resources are owned by domains (with projects being also identity resources). Other services use projects to for resources isolation. They do not need to be domain aware. From aef5a655790a52e2b2e2def148a1168dac65eacf Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:23:09 +0100 Subject: [PATCH 05/11] Update Standards/scs-0302-v2-domain-manager-role.md Co-authored-by: Felix Kronlage-Dammers Signed-off-by: Artem Goncharov --- Standards/scs-0302-v2-domain-manager-role.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-0302-v2-domain-manager-role.md b/Standards/scs-0302-v2-domain-manager-role.md index e43f6bca6..a1377dec6 100644 --- a/Standards/scs-0302-v2-domain-manager-role.md +++ b/Standards/scs-0302-v2-domain-manager-role.md @@ -80,7 +80,7 @@ multi-tenancy. Usage of domains by itself allows to implement a form of self-service management by the customer. Only identity resources are owned by domains (with projects -being also identity resources). Other services use projects to for resources +being also identity resources). Other services use projects for resources isolation. They do not need to be domain aware. Using domains allows implementing [domain From 9a497cee5175a0d2227e9bac7613deba2d608e6d Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:23:18 +0100 Subject: [PATCH 06/11] Update Standards/scs-0302-v2-domain-manager-role.md Co-authored-by: Felix Kronlage-Dammers Signed-off-by: Artem Goncharov --- Standards/scs-0302-v2-domain-manager-role.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Standards/scs-0302-v2-domain-manager-role.md b/Standards/scs-0302-v2-domain-manager-role.md index a1377dec6..9a5ed381c 100644 --- a/Standards/scs-0302-v2-domain-manager-role.md +++ b/Standards/scs-0302-v2-domain-manager-role.md @@ -95,9 +95,9 @@ User management (creation, activation, deactivation, deletion) SHOULD be possible using OpenStack APIs. When an external IdP is being used (IdP federation) there is still an -expectation that local users may be required by customers. As such creation of +expectation that local users may be required by customers. As such, creation of users (pre-creating federated users or regular local users) within customer -domain SHOULD me possible. Keystone does not allow certain operations on +domain SHOULD be possible. Keystone does not allow certain operations on federated users (i.e. password change, MFA, name) as such allowing customers to manage users using OpenStack APIs should not conflict with any additional requirements. From 3752e58c728878c39a6aa499407e2b52d6e93c8a Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:23:34 +0100 Subject: [PATCH 07/11] Update Standards/scs-0302-v2-domain-manager-role.md Co-authored-by: Felix Kronlage-Dammers Signed-off-by: Artem Goncharov --- Standards/scs-0302-v2-domain-manager-role.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-0302-v2-domain-manager-role.md b/Standards/scs-0302-v2-domain-manager-role.md index 9a5ed381c..bed9957e7 100644 --- a/Standards/scs-0302-v2-domain-manager-role.md +++ b/Standards/scs-0302-v2-domain-manager-role.md @@ -110,7 +110,7 @@ forcing degrading of the capability requirement. Management of groups SHOULD be possible using OpenStack APIs. -In case of federated Identities there it is possible that groups on the IdP +In the case of federated Identities the possibility exists that groups on the IdP side do not match groups on the cloud provider side. In addition to that there might be a need to combine federated and local users. This would only be possible when groups are managed by the OpenStack. From 089c906412e1a19eb6c8a2c27270a2cb76369391 Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:23:51 +0100 Subject: [PATCH 08/11] Update Standards/scs-0302-v2-domain-manager-role.md Co-authored-by: Felix Kronlage-Dammers Signed-off-by: Artem Goncharov --- Standards/scs-0302-v2-domain-manager-role.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-0302-v2-domain-manager-role.md b/Standards/scs-0302-v2-domain-manager-role.md index bed9957e7..bbd320e61 100644 --- a/Standards/scs-0302-v2-domain-manager-role.md +++ b/Standards/scs-0302-v2-domain-manager-role.md @@ -132,7 +132,7 @@ responsible for cleaning projects before their deletion. request is received. In this scenario CSP is implementing custom functionality to delete all resources before deleting the project. -- Leave orphant resources. In this scenario project is being deleted by the API +- Leave orphaned resources. In this scenario project is being deleted by the API with custom cleanup procedures being responsible for dropping orphant resources. Leaving orphant resources MAY NOT be allowed. From 015ddcf69480110907accacd162063dc820b2abe Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:24:04 +0100 Subject: [PATCH 09/11] Update Standards/scs-0302-v2-domain-manager-role.md Co-authored-by: Felix Kronlage-Dammers Signed-off-by: Artem Goncharov --- Standards/scs-0302-v2-domain-manager-role.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-0302-v2-domain-manager-role.md b/Standards/scs-0302-v2-domain-manager-role.md index bbd320e61..68a78d5f1 100644 --- a/Standards/scs-0302-v2-domain-manager-role.md +++ b/Standards/scs-0302-v2-domain-manager-role.md @@ -135,7 +135,7 @@ to delete all resources before deleting the project. - Leave orphaned resources. In this scenario project is being deleted by the API with custom cleanup procedures being responsible for dropping orphant resources. -Leaving orphant resources MAY NOT be allowed. +Leaving orphaned resources MAY NOT be allowed. Forbidding project deletion making customer responsible for the cleanup SHOULD be preferred since it allows preventing the accidental deletion of the From 82ad0fd06b6d4fdc996833de974f25bffc93bfc2 Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:26:34 +0100 Subject: [PATCH 10/11] fix linter complain Signed-off-by: Artem Goncharov --- Standards/scs-0302-v2-domain-manager-role.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-0302-v2-domain-manager-role.md b/Standards/scs-0302-v2-domain-manager-role.md index 68a78d5f1..b722bb067 100644 --- a/Standards/scs-0302-v2-domain-manager-role.md +++ b/Standards/scs-0302-v2-domain-manager-role.md @@ -27,7 +27,7 @@ and mandatory to provide better granularity while still giving guidance with the goal to provide a smooth user experience for the end users. Requiring customer to use CSP specific APIs to manage identity data is -contradicting the idea of standardization as such. It hinders customers from +contradicting the idea of standardization as such. It hinders customers from having a smooth user experience across different cloud providers forcing them to adapt their management strategies on such clouds. Moreover it represent a lock-in what is contradicting with the idea of SovereignCloudStack. From 160b5befbbd6cb31efe29e56b1ba2fdbea8c363e Mon Sep 17 00:00:00 2001 From: Kurt Garloff Date: Thu, 20 Feb 2025 14:40:07 +0100 Subject: [PATCH 11/11] Typo. Signed-off-by: Kurt Garloff --- Standards/scs-0302-v2-domain-manager-role.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Standards/scs-0302-v2-domain-manager-role.md b/Standards/scs-0302-v2-domain-manager-role.md index b722bb067..955c5406d 100644 --- a/Standards/scs-0302-v2-domain-manager-role.md +++ b/Standards/scs-0302-v2-domain-manager-role.md @@ -133,7 +133,7 @@ request is received. In this scenario CSP is implementing custom functionality to delete all resources before deleting the project. - Leave orphaned resources. In this scenario project is being deleted by the API -with custom cleanup procedures being responsible for dropping orphant resources. +with custom cleanup procedures being responsible for dropping orphaned resources. Leaving orphaned resources MAY NOT be allowed.