From 1f6cf850b092f0fb3ce6e3e0a95a2d31bee36669 Mon Sep 17 00:00:00 2001 From: Artem Goncharov Date: Tue, 11 Feb 2025 14:43:15 +0100 Subject: [PATCH] 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.