BEFORE YOU BEGIN
Check before you begin
Local user hierarchy, Django Group permissions and the Skyline/Keystone role matrix are separate layers. This guide describes inspected code/design behavior; it is not a blanket security acceptance that every installed endpoint enforces identical controls.
Visual/acceptance limit: no real user/role/permission screen was captured in this inspection; another screen was not substituted. Content is based on local user/group/storage handlers and Keystone RBAC design. No account, password, role/group, permission, tenant or external-identity changes or user deletion were performed.
- Account source, parent and tenant/project identity
- Hierarchy role, group and effective permissions
- Resource/storage assignments and allowed actions
- Approved test account and access review
011. Separate hierarchy roles from operation groups
role values such as super_admin/customer_admin/user relate to customer hierarchy. role_ep and Django Group membership carry operational permissions. is_superuser and endpoint-specific checks may also affect access. A role name or group label alone does not define every authorization boundary.
Expected resultIdentity, scope and check results are recorded.
022. Inspect the group catalog
The inspected group catalog defines manager (Backup & Restore Manager), viewer (Viewer) and system_operator (System Operator). The viewer description relates to view_ codenames; manager/system_operator descriptions contain broad-permission markers. These descriptions do not replace effective endpoint or tenant-isolation testing.
Expected resultIdentity, scope and check results are recorded.
033. Translate work requirements into permissions
List monitoring/reporting, policy creation/execution, restore, storage administration and user administration separately. Inspect actual permission codenames in the installed group instead of assigning a broader group than required. Do not grant restore or user administration merely because a label contains operator/manager.
Expected resultIdentity, scope and check results are recorded.
044. Identify accounts affected by group edits
The inspected edit_group path updates group permissions; editing a user may clear existing groups and assign the selected group. Record members, parent/tenant and responsibilities before group changes. Changing a label and changing a permission set are different operations.
Expected resultIdentity, scope and check results are recorded.
055. Assess Keystone roles separately
The Skyline design separates reader listing, member policy modification/execution and admin restore/storage modification. This matrix is not identical to local viewer/manager/system_operator groups. External issuer + user_id + project_id mapping and verified-token roles are authoritative; do not assume body-supplied roles/projects are trusted.
Expected resultIdentity, scope and check results are recorded.
066. Validate access in a separate test session
Using an approved test account, verify the correct tenant/project and resource list. Assess viewing separately from policy runs, restore, storage changes and user management. Verify denial of unauthorized actions without starting production jobs or changing settings. Hidden menus are not proof of endpoint authorization.
Expected resultIdentity, scope and check results are recorded.
077. Document the access review
Record account, role/group, customer/project, resource assignments, approver and review date. Review local and external identity access separately after job changes or departure. This inspection changed no user, group, password, 2FA, LDAP/Keystone mapping or permission; validate session termination/revocation behavior separately in the installed release.
Expected resultIdentity, scope and check results are recorded.
COMMON QUESTIONS
Does a group name alone prove authorization?
No. Validate group permissions, hierarchy, tenant/project, resource assignments and endpoint action controls together.