SigNoz API keys inherit service-account and role scope
SigNoz connects logs, traces, metrics, dashboards, and service accounts in one observability control plane. API keys are used by collectors, scripts, and integrations, but a key is not a free-standing permission object. It is attached to a service account and inherits the role scope assigned to that account.
The SigNoz authentication guide describes role-based access control and custom roles. The service account documentation says service accounts have the signoz-viewer role by default and advises against assigning elevated roles to integration accounts. The Logs API documentation says API keys can be created and managed only by users with the Admin role by default.
That combination is a useful starting point, but it creates two questions for every key: which service account owns it, and which role does that account carry? A key with an administrative role can do much more than ingest telemetry. It may manage dashboards, users, roles, service accounts, or other keys depending on the deployment edition and current IAM configuration.
Key creation is a privilege
The SigNoz transactions reference lists API-key and service-account operations among the resources controlled by roles. A custom role can be narrow, but it still has to be reviewed as code. A role that can add a key to a service account can extend that account's access without changing its other resources.
Keep ingestion keys separate from query and administration keys. An OpenTelemetry collector needs to send data, not change users or delete dashboards. A dashboard export job may need read access to saved views but not to user management. Use a distinct service account for each integration and environment.
Do not place API keys in browser code or a public dashboard. Treat a SigNoz key like a bearer credential. Store it in a secret manager, rotate it when an integration is retired, and record the date, owner, and purpose. The SigNoz service-account documentation describes revoking a key from the service account and warns that systems using the revoked key lose API access.
Measurement and limitation
Count-only probes on 2026-11-10 at 18:44 to 18:45 UTC used sub_type=all, page 1, and pagesize 1. The application query app="SigNoz" returned 32 assets; title="SigNoz" returned 2,719. The application fingerprint is more specific, while the title query may find installations whose HTML title is more visible than their application fingerprint.
The selected ZoomEye search is a candidate inventory. It does not prove that API keys exist, that a key is exposed, or that the key's role is excessive. A matching endpoint still needs owner verification and an authenticated policy review.
Review the effective role
For each service account, list its roles, the transactions those roles allow, the keys attached to it, and the last observed use. Compare the role with the integration's actual calls. If a collector only writes telemetry, remove dashboard, user, role, and key-management transactions.
Test a denied operation with the real key. A collector key should fail when it tries to list users or create another key. Rotate one key and verify that only the intended integration loses access. Check whether keys are shared across development, staging, and production, and split them if the blast radius is too wide.
Monitor key creation, role assignment, service-account changes, and unusual API methods. Log the service-account identity and key identifier, not the key value. Review the self-service API-key configuration if viewers or custom roles can create keys. The documentation's narrow-service-account pattern is useful because it limits who can add a key without granting general administration.
Treat observability as a sensitive system
SigNoz often stores telemetry that includes service names, environment labels, request paths, user identifiers, and error content. Access to the observability plane can reveal how systems fail and where they are exposed. Put the UI and API behind TLS and an appropriate identity layer, restrict public endpoints, and review dashboard sharing separately from API-key scope.
An API key is only as safe as the service account behind it. Keep that account small, attributable, and replaceable.
Top comments (0)