From 1f6cf850b092f0fb3ce6e3e0a95a2d31bee36669 Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Tue, 11 Feb 2025 14:43:15 +0100 Subject: [PATCH 01/10] 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 4d372aca76436be2668cad347bfa2ba251a8498a Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:22:42 +0100 Subject: [PATCH 02/10] 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 286065c1ac072c296a39424522baf02dc9cb95ea Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:22:50 +0100 Subject: [PATCH 03/10] 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 4f97ada452ef22301e23800ab9513c0a58e63201 Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:22:59 +0100 Subject: [PATCH 04/10] 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 f08bc34eb3ba8c0c81d7bd5391a99dde1e54d15e Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:23:09 +0100 Subject: [PATCH 05/10] 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 976e6dbe4bdbf6f4fa29897910e734780e697607 Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:23:18 +0100 Subject: [PATCH 06/10] 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 de4c482ee5a2082fa5d337dd9d48199262eb0a72 Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:23:34 +0100 Subject: [PATCH 07/10] 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 0c4baa7e67dc2d506021844191b02aed82b3e997 Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:23:51 +0100 Subject: [PATCH 08/10] 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 8b1463d84d38b3affb0cc2f0b0224286227b3d03 Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:24:04 +0100 Subject: [PATCH 09/10] 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 00cfe7b0beecc43be1316cef03fcfb850b552583 Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Wed, 12 Feb 2025 11:26:34 +0100 Subject: [PATCH 10/10] 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.