Draft: Roles Standard #378
Conversation
Signed-off-by: Markus Hentsch <[email protected]>
…DR entry Signed-off-by: Markus Hentsch <[email protected]>
Signed-off-by: Markus Hentsch <[email protected]>
|
|
||
| ### Limited scope of OpenStack services covered by this standard | ||
|
|
||
| Currently, SCS does not enforce a list of OpenStack components/services it covers and/or supports exactly. |
There was a problem hiding this comment.
How do we want to address this?
There was a problem hiding this comment.
See the corresponding action item here: https://github.com/SovereignCloudStack/minutes/blob/main/iam/20231018.md?plain=1#L65-L72
Quote:
- = predefine policy.yaml files for all services that have an API
There was a problem hiding this comment.
I introduced an issue to work on this: #469
|
|
||
| ## Decision | ||
|
|
||
| This standard establishes a set of roles consisting of current OpenStack defaults and the stable parts of the ongoing OpenStack RBAC rework[^1]. |
There was a problem hiding this comment.
How to we handle the roles / policy modifications / policy extensions itself? Are they part of this standard?
There was a problem hiding this comment.
I'm currently looking into figuring out the best strategy for this to fill in the core part of the standard.
Aside from the Domain Manager, we do not diverge from the current upstream roles so far. Hence I'm considering proposing a simple set of rules (e.g. the CSP must not extend the rights of the "reader" or "member" roles beyond the upstream policy definitions, etc.) and a best-practice approach to ensuring/applying the default rule sets of upstream OpenStack.
Signed-off-by: Markus Hentsch <[email protected]>
Signed-off-by: Markus Hentsch <[email protected]>
First Update regarding the progress of upstream RBAC development Signed-off-by: josephineSei <[email protected]>
include newly introduced manager role with project-manager persona into the standard. Signed-off-by: josephineSei <[email protected]>
There was a problem hiding this comment.
@bitkeks what do you think about integrating a pointer to a set of policy adjustments?
| Since the stable parts of the rework are already included in recent OpenStack releases, they can be used as-is. | ||
|
|
||
| On a per-service basis, a CSP applying this standard MUST either | ||
| **a)** not configure a `policy.yaml` or `policy.json` file for the OpenStack service at all (i.e. using its defaults) or |
There was a problem hiding this comment.
| **a)** not configure a `policy.yaml` or `policy.json` file for the OpenStack service at all (i.e. using its defaults) or | |
| **a)** use the predefined policy options from the SCS for certain services and do not configure a `policy.yaml` or `policy.json` file for the rest of the OpenStack service at all (i.e. using its defaults) or |
This suggestion includes a hint to a possible repository or document or website for policy-options, that should be adjusted in SCS-deployments compared to the default policies.
|
|
||
| - the default OpenStack roles (`admin`, `manager`, `member`, `reader`) MUST NOT be changed regarding their permissions | ||
| - for custom permission sets a new role MUST be added and the name of the role MUST NOT match with any of the existing default role defined by OpenStack (`admin`, `manager`, `member`, `reader` etc.) or the name `domain-manager` | ||
| - in case of Keystone, a `domain-manager` role MAY be added; in this case its definition MUST adhere to the Domain Manager SCS standard |
There was a problem hiding this comment.
| - in case of Keystone, a `domain-manager` role MAY be added; in this case its definition MUST adhere to the Domain Manager SCS standard | |
| - in case of Keystone, a `domain-manager` role MAY be added; in this case its definition MUST adhere to the Domain Manager SCS standard | |
| - the policy enhancements provided by the SCS MUST be included |
This suggestion should include a hint to a possible repository or document or website for policy-options, that should be adjusted in SCS-deployments compared to the default policies.
|
Closing this in favor of the rework #590 based on the latest findings of SovereignCloudStack/issues#396 |
Adds a standard to define all RBAC roles and permissions in the SCS IaaS layer.
Resolves SovereignCloudStack/issues#396