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. Identify the account source and owner
Separate local users, LDAP and Keystone/external identities. Record the owner, company/tenant, parent admin and required resources. Do not assume identical emails or display names imply the same access scope; plan initial validation with an approved test account.
Expected resultIdentity, scope and check results are recorded.
022. Verify authority to create a user
The inspected add_user code requires a superuser to select Parent Admin; a customer_admin creates a user beneath itself. Regular-user creation is denied. Validate this source contract in the installed release; do not assume a reseller/distributor portal or automatic invitation flow exists.
Expected resultIdentity, scope and check results are recorded.
033. Check parent and tenant mapping
Compare identity, company/tenant, Parent Admin and role_ep/group fields with the intended records. The code transfers the parent’s cust_no to the new child user. A wrong parent may affect data scope; do not move an existing production account to another customer for testing.
Expected resultIdentity, scope and check results are recorded.
044. Complete password and identity handling securely
The authorized user should set a local password through the secure entry flow; keep passwords/app passwords out of guides, logs and screenshots. Do not assume external-identity passwords can be changed in a local-account form. Validate 2FA, password reset, first-login requirements and session revocation separately in the installed release.
Expected resultIdentity, scope and check results are recorded.
055. Separate editing from deletion effects
Before identity/group changes, record existing parent/tenant and resource visibility. The inspected delete_user path may mark child users and related server records is_deleted when deleting a customer_admin. A soft-delete flag does not guarantee UI recovery; a temporary-disable alternative was not verified in this inspection.
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.