/access-review

name: "Cove Console Access Review"
description: >
  Reviewing who can sign in to the Cove Management Console for each customer
  and with which role, spotting leavers and over-privileged accounts, and
  reading the user-action audit log (cove_audit_actions_list, admin-gated in
  Conduit and needing an Administrator API user in Cove) to see who changed
  devices, retention, users or customers.
when_to_use: >-
  When someone runs a quarterly access review of the backup console, offboards
  a technician, or needs to know who changed or deleted something in Cove.
  Use when: cove users, cove access review, cove roles, backup console
  access, cove audit log, who deleted backup, who changed retention,
  technician offboarding, or cove superuser.

Cove Console Access Review

Overview

Backup console access is high-value: a console user can delete devices, change retention, or restore data to another machine. MSPs review it each quarter, after a technician leaves, and when a client's security questionnaire asks who can reach their backups. These tools only read. Remove or change users in the Cove console.

Permissions

| Tool | Conduit tier | Cove role needed | |------|--------------|------------------| | `cove_users_list` | read | Supporter | | `cove_user_roles_list` | read | Supporter | | `cove_audit_actions_list` | **admin-gated**: only Conduit members with the admin tier can call it | Administrator or SuperUser. Other roles get error 13501. |

`cove_users_list` returns names and email addresses of your staff and your customers' staff. Keep the output with the people doing the review.

If the user is not a Conduit admin, or the connected API user is a Supporter, do the user and role review and say plainly that the audit log part needs both a Conduit admin and an Administrator API user.

Anti-triggers

• **Device backup status**: use `cove-backup-health`.
• **Customer states, products or storage**: use `cove-customer-inventory`.

Workflows

Quarterly access review

1. `cove_auth_context_get` for the root `PartnerId`. 2. `cove_partners_list` with `fetch_recursively: true` and `fields: [0, 1]` to get every customer ID and name. 3. `cove_users_list` with `partner_ids`: the root plus the customers to review, at most 100 IDs per call. Split larger trees into batches. 4. `cove_user_roles_list` to name the roles. 5. Flag, in this order:

• **SuperUser** accounts. There should be very few; each needs an owner

who can justify it.

• **API users** with Administrator or SuperUser. The connector itself

needs only Supporter unless someone uses the audit log.

• Users at the root customer who are not on the current staff list the

reviewer gives you.

• Users at an end customer whose email domain is not the MSP's or that

customer's.

• Shared or generic logins (`admin`, `backup`, `support`).

6. Report one row per user: customer, login, name, email, role, and the flag that applies. Users with no flag go in a count, not the table.

Technician offboarding check

1. Run steps 1 to 4 above for the whole tree. 2. Find every account that matches the leaver's name or email, at every customer level. MSP staff often have logins at several end customers. 3. If the audit log is available, call `cove_audit_actions_list` for the last 30 days with `user_id` set to each matching account, to see what they did before leaving. 4. List the accounts to remove. Removal happens in the console.

Who changed or deleted something (admin-gated)

`cove_audit_actions_list` needs `from` and `to` as Unix seconds. Narrow it:

| Argument | Use | |----------|-----| | `partner_id` | Actions performed in this customer | | `entity_partner_id` | Actions on things owned by this customer | | `include_all_sub_partners` | Include every sub-customer | | `user_id` | Actions by one console user | | `entity` | e.g. `Account` (device), `AccountProfile`, `Partner`, `User`, `Product` | | `operation` | e.g. `Remove`, `Delete`, `Modify`, `Add`, `PasswordReset` | | `result` | `Succeeded` or `Restricted` | | `count_limit` | 1 to 1000, default 100 | | `reverse_order` | `true` for newest first |

Common questions:

• **Who removed a device?** `entity: "Account"`, `operation: "Remove"`, over

the window the device disappeared in.

• **Who changed retention or a profile?** `entity: "AccountProfile"` or

`entity: "Product"`, `operation: "Modify"`.

• **Failed attempts?** `result: "Restricted"` shows actions Cove refused.

If the result reaches `count_limit`, there may be more. Split the window in half and query each part instead of reporting a partial list as complete.

Gotchas

• Error 13501 on `cove_audit_actions_list` means the API user's Cove role is

below Administrator. A Conduit permission denial is a different message and means the Conduit member is below the admin tier. Tell the user which one happened.

• Cove adds a suffix to API user login names, so they look different from

the name typed when they were created.

• Passwords are never returned; password fields come back redacted.
• `cove_user_roles_list` takes an optional `partner_id`; whether Cove uses it

is unconfirmed, so do not rely on it to show per-customer roles.