Connect
Credentials
Each source has a credential that can be rotated or revoked without changing its configuration. A credential authenticates telemetry senders only: it lets one source push to the OTLP endpoint, and it never signs anyone in to the console.
How it works#
A credential is a bearer secret bound to one source. When a sender presents it, MonitOps looks the credential up, compares the secret against a stored digest and, if it matches, takes the tenant, the source and the source's policy from the source's configuration. Only the secret is confidential. The credential identifier is a lookup key, not proof of anything, and it is safe to quote in a support request.
MonitOps keeps a digest of the secret and nothing else. The plaintext appears in the response that issues the credential and in no list, detail view, audit entry or event afterwards. Credentials do not expire on their own: they remain valid until an administrator revokes them or the source is disabled.
Only administrators can list, issue or revoke credentials. Viewers and operators can read source configuration but not credentials.
Procedure: issue a credential#
- Open the source on Sources.
- Choose to issue a credential.
- Copy the secret from the response into the sender's secret store. It is shown once, in this response only.
- Configure the sender with it as the bearer value. See Connect a source.
A source can have at most two active credentials at a time, so that a replacement can be issued before the old one is revoked. Issuing is also limited per source per day.
Procedure: rotate a credential#
Rotation is three steps in a fixed order, so that the sender is never without a valid credential.
- Issue a replacement. The source now has two active credentials.
- Switch the sender to the new secret and restart or reload it.
- Revoke the old credential explicitly. Do this only after the sender is using the new one.
The console explains this manual switch. It does not infer that the sender has switched, and it does not display usage it cannot measure. Check the source's freshness and admission counts on Sources after step 2, before you revoke.
Procedure: revoke a credential#
- Open the source and find the credential by its identifier.
- Choose to revoke it.
Revocation is permanent and idempotent. A revoked credential is never restored, and revoking it again changes nothing. The audit record and the source's identity remain. Senders using it receive 401 once the revocation takes effect, which is after a short, bounded interval, because recent authority lookups are held briefly; a request already authorized may finish.
Disabling a source denies all of its credentials. Re-enabling the source does not unrevoke any credential that was revoked.
What survives rotation#
Rotation and revocation change the credential, not the source. The following stay as they were:
| Survives | Why |
|---|---|
| Source policy, including metadata rules and allowed services | Policy belongs to the source configuration, and the configuration version does not change |
| Service and entity identity | Identity is resolved within the source's authority, not the credential's |
| Daily allowances and usage | Metering is per source |
| Rate-limit state | Rate keys are the tenant and source, not the credential |
Recover a lost issuance#
Issuing is not repeatable: the request carries an identifier generated by the caller, and the server creates the secret and returns it once. If the response is lost, for example because the connection dropped, the secret cannot be fetched again, and asking again with the same identifier is refused rather than replaying it.
- List the source's credentials. If the identifier you sent is present, the issue committed.
- If it committed but you did not receive the secret, revoke that credential by its identifier.
- Issue a new credential with a new identifier.
- If the identifier is not in the list, the issue did not commit, and you can issue again.
Do not retry an issue automatically with a different identifier: a lost response and a committed issue look the same to the caller until you check the list.
Credentials for services and browser sessions#
Two kinds of access are kept apart.
| Source credential | Browser session | |
|---|---|---|
| Used by | A telemetry sender | A person in the console |
| Authenticates to | The OTLP endpoint | The console and the API |
| Established by | An administrator issuing it | Single sign-on, or a break-glass local account |
| Ends by | Revocation or disabling the source | Logout, timeout or administrative revocation |
A source credential never authenticates browser APIs, and a browser session never authenticates telemetry. See Roles and access.
What you see in the console#
Each credential is listed with its identifier and status, never its secret. Issuing and revoking are recorded in the audit trail with the actor and time, without the secret, the digest or any authorization header.
Failure states#
| Situation | Result |
|---|---|
| Invalid, revoked or unknown credential | The sender receives 401; admission is denied |
| Credential store cannot be read | The request is refused with a retryable error. It is never treated as authorized |
| Third active credential requested | Refused; revoke one first |
Related#
Last updated October 2026