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. Define access scope together with resources
Assess access using user/group, company/tenant, parent, project and resource identities together. Backup lists, repository assignments, report recipients and restore destinations may not share identical boundaries. Record tenant filtering and endpoint action controls as separate acceptance criteria.
Expected resultIdentity, scope and check results are recorded.
022. Prepare positive and negative access tests
List resources each test account should and should not see. Assess viewing, create/edit/delete, run and restore separately. Do not test by attempting unauthorized changes to production; use approved test tenants/resources and procedures that stop before final writes.
Expected resultIdentity, scope and check results are recorded.
033. Validate storage assignment and quota
In the local storage-scope code a child user may inherit the customer_admin parent’s storage assignments and tenant quota. Empty/invalid assignments produce an empty scope. A visible storage name alone is not write/restore authorization; also check backend identity mapping, quota and repository access. Do not manually edit legacy database fields through the user procedure.
Expected resultIdentity, scope and check results are recorded.
044. Validate external project boundaries
The Skyline/Keystone flow validates tokens and maps issuer/user/project to a local external_identity. The design rejects unmatched identities with 403; do not assume automatic tenant creation. Recheck resource/action scope after changing projects. Keep tokens out of URLs and logs.
Expected resultIdentity, scope and check results are recorded.
055. Check effective access for consequential operations
Compare actual endpoint controls for restore, storage changes, user/group edits and report delivery with the installed release. Specialized paths such as _is_storage_admin may require is_superuser or mena_admin/super_admin; do not decide from the Group catalog alone. Unrestricted administrator assignment is not a substitute for validation.
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.