Delivering managed service with privileged access
What changed
Every content update is versioned. Select a version to compare it with the one before.
Version 1 → 2
Small fix2 lessons updated
Small corrections such as typos or translation fixes. Learners are not notified.
Providers often work at a customer with an account they own: a managed administrator account, a monitoring account. Creating it again in every tenant means many copies of one password that go out of step at the first rotation. A **shared vault item** avoids that.
### How it works
On the main tenant, open the vault item and choose **Share to Tenants** (or **Share Vault Item** on the tenant's **Shared Vault Items** tab). The customer tenant gets a read-only vault item with the same name, marked `Shared from provider`. The secret is **not copied**: every use reads it from the main tenant at that moment. A password rotated on the main tenant is current in every tenant at once.
### Two use modes
- `Sessions only` (default): the item opens sessions. Its secret is not shown, not exported through the vault API and not placed into script tokens.
- `Sessions and reveal`: the tenant's own vault policies decide who may reveal it. Use it only when the tenant needs the value itself.
The tenant assigns the shared item to resources, spaces and policies like any other vault item. It cannot edit or rotate it.
### Stopping a share
Suspend, resume or revoke from the main tenant. A suspended, revoked or expired share stops working at once for new sessions in that tenant. **Revoke** also removes the tenant's vault item with its assignments; sharing again creates a new item that must be assigned again.
::diagram msp-shared-vault-item
### Limits
- Not shared: personal vault items, items that are themselves shared, and the types `OTP`, `Single Sign-On`, `Ephemeral`, `Pool` and `Kubernetes Token`.
- The user name of a shared item stays visible to tenant users who may see the item.
- For a remote tenant, a shared item works only while the link to the provider is up.
> Tip: Give every share a `Reason` and, for project work, a `Share ends` date.
A managed service is judged on what it can prove. Monopam writes the provider's work into the audit trail of **both** sides, so neither depends on the other's word.
### What is recorded
| Event | Where |
| --- | --- |
| `Provider Access Granted`, `Provider Access Changed`, `Provider Access Revoked` | Main tenant |
| `Provider Session Started` | Main tenant and customer tenant |
| `Provider Session Rejected`, with the `Reason` | Customer tenant |
| `Credential Shared`, `Credential Share Changed` | Main tenant and customer tenant |
Requests and approvals are part of the same trail: the request, then the approval or the rejection, with who asked.
::diagram msp-evidence-both-sides
### Who did it
Every audit entry written inside a delegated session carries the actor details `Provider Session`, `Provider Role` and `Grant Id`. An action in the customer tenant can therefore be traced to a named person of the provider, the role held at that moment and the grant that allowed it. In the tenant's `Users` list, provider staff carry a `Provider` badge.
### Uses of shared vault items
Each use of a shared vault item is audited on the main tenant, at most one entry a minute per share.
### Sessions and recordings
What happens inside a session is recorded as for any Monopam session; the course on session management covers recording, live sessions and session notes. What this lesson adds is the answer to the question a customer asks first: who from the provider was in, and on whose decision.
> Tip: For a service review, start from **System → Provider Access** for the list of grants, then use the audits of the customer tenant for the entries of the period.