Browse and search documentation
Users projects and permissions
Assign appropriate access to administrators, operators and approvers, then verify project boundaries and multi-factor authentication.
On this page
How permissions affect access
Identity, role permissions, project membership and resource scope jointly determine access. Opening a module does not grant every action in it. Viewing a host does not automatically allow terminal access, diagnostic downloads or job execution.
| Responsibility | Access to review |
|---|---|
| Platform administrator | Users, projects, roles, runtime configuration and licensing |
| Operator | Assets, required connections and jobs within assigned projects |
| Approver | Review action evidence, targets and risk, then approve or reject under policy |
| Auditor | Record queries and separately authorized export or playback |
Configure and verify
- Use an authorized administrator to create or confirm users in the user and access-management pages. Avoid sharing one administrator account.
- Confirm each project’s resources, add users to projects they actually manage and assign roles required for their work.
- With an operator account, verify allowed assets and tasks work while resources in other projects remain inaccessible.
- Review MFA and approval requirements separately for connections, jobs and high-risk changes. Do not solve ordinary access issues by granting global administration.
MFA and account recovery
Current MFA uses TOTP codes and single-use recovery codes. Follow account-security enrollment and store recovery codes securely without sharing them. Complete fresh verification when an operation requires recent authentication.
If codes keep failing, check authenticator and device time synchronization. Recovery codes are single use. Keep a tested local emergency administrator before enabling enterprise identity so an identity-provider outage does not remove all administrative access.
Authorization and approval differ
Permissions determine whether you may request an action; approval evaluates that specific request under team rules. User, target and policy checks still apply after approval. Do not reuse an old approval after changing targets or parameters.
Routine remote connections normally follow recent MFA, with additional access review configurable by the team. High-risk actions and some protocols have separate requirements. Single-operator use does not mean all approvals are automatically granted.
Review access after team changes
- Remove unnecessary projects and roles after a departure or role change, and review service accounts and credentials still in use.
- When access fails, record the page, action, project and time. Never include passwords, recovery codes or complete tokens in support messages.
Send your deployment version, page and a redacted description so we can investigate and update the guide.
weiwendi@aiops.red