Security and access control for an observability platform

Treat telemetry as sensitive data

It's easy to think of monitoring data as harmless operational noise. Look at what it contains:

• Traces carry URLs, sometimes with customer identifiers, and database statements in db.query.text when instrumentation captures them.
• Logs contain whatever developers wrote, sometimes including tokens, email addresses and stack traces with arguments.
• Topology is an accurate map of your systems, which is exactly what an intruder would like to have.
• Change history shows who did what and when.
• RUM session timelines describe what a named person did in an application.

So a person with broad read access to observability data can often learn as much as someone with access to several of the underlying systems. Two threats follow: outsiders gaining access, and insiders seeing more than their job requires. Hosting on your own infrastructure addresses the data-leaving-the-network question. It doesn't address either of those, which is what the rest of this page is about.

Single sign-on with OIDC and PKCE

Wrentrix supports OIDC SSO with PKCE. For an internal tool, that means your people sign in with the accounts they already have, and joiner-mover-leaver handling and multi-factor rules stay where you have already set them up: at your identity provider.

PKCE (Proof Key for Code Exchange, RFC 7636) closes a specific hole in the authorization code flow. Without it, someone who intercepts the authorization code can exchange it for tokens. With it, the client first creates a random secret, and sends only its hash in the authorization request:

code_verifier  = high-entropy random string, kept by the client
code_challenge = BASE64URL(SHA256(code_verifier))

GET /authorize?response_type=code
    &client_id=wrentrix
    &redirect_uri=https://wrentrix.example.internal/...
    &scope=openid profile
    &code_challenge=<code_challenge>
    &code_challenge_method=S256
    &state=<random>

When the client redeems the code, it sends the original code_verifier. The identity provider hashes this and compares. A stolen code alone is useless. The redirect URI above is shortened on purpose. Take the real one from your own installation. The OIDC, PKCE and LDAP guide walks through this flow for internal applications in general, including group claims and common configuration mistakes.

Things to check with your identity team before enabling:

• Use S256, not plain, as the challenge method.
• Register the exact redirect URI and don't use wildcards.
• Confirm how groups are delivered, and that a user in many groups doesn't produce an oversized token.
• Decide what happens to a session when someone leaves. Short token lifetimes shorten the window between an account being disabled and access ending.

LDAP sync and group-based roles

Wrentrix syncs with LDAP and maps LDAP or SSO groups to team-based RBAC with scoped views. The point of this mapping is that access comes from a group that already has an owner and a review process, and that you aren't maintaining a second list of who works where.

An example mapping, using invented group names, would look like this on paper:

Think through a few design issues before you begin:

Scope is a trade-off with diagnosis. A narrowly scoped developer can't see the service upstream of theirs, so during an incident they may be blind. Most organisations end up with scoped write access and a broader read view for on-call roles. Decide this consciously, and note that the on-call group sees more, so review membership accordingly.

Keep admin groups small. Whoever can change alerts, integrations and remediation targets can effectively silence monitoring or launch automation.

Test with a real non-admin account. Scoping mistakes are invisible to the admin who configures them. Log in as a member of one team and verify what can't be seen, and not only what can.

Decide who owns reviews. Periodic access reviews are a common requirement in regulated companies. A clean mapping to directory groups means that this review happens in one place.

If you need a break-glass account for when the identity provider is down, plan it with your security team. Ask us how local access fits with your setup.

The audit log

Every change is written to an audit log. A useful audit trail answers these questions in the event of an incident or an audit:

• Who silenced this alert, and when?
• Who changed the threshold, or the SLO target?
• Who added a remediation action, and who approved it when it ran?
• Who changed a team's scope, or who added an integration?

The value of those records depends partly on how they're handled. A log that administrators can quietly edit is weak evidence. Regulated organisations often forward audit data to a separate system that platform administrators cannot alter. How to export the log, and how long it's kept, are worth checking against your own policy, so raise them when you talk to us.

When remediation goes through Ansible AWX job templates, AWX keeps its own job history as well. Between them, you can reconstruct the chain from an alert to an action.

Running with the least privilege

The platform's own footprint is the other half of the story. Wrentrix pods run under OpenShift's default restricted-v2 SCC, without root, and without extra SCCs. That means no privileged containers to justify, and a smaller set of permissions for a compromised container to abuse. You can check the SCC yourself:

oc get pod <pod> -n wrentrix -o jsonpath='{.metadata.annotations.openshift\.io/scc}'

The restricted-v2 guide covers what this SCC enforces. Your security team will also want to read the agent's RBAC in the downloaded YAML, since it decides what the agent can read at the cluster level. Because oc apply works from a file you hold, you can review it line by line, and compare it between versions.

The admission webhook needs a similar look. A mutating webhook sits in the pod creation path, so check which namespaces it applies to, and confirm that it fails open. The webhook guide explains the fields involved.

Network paths to document

Security reviews typically ask for a complete list of connections. For an on-premise deployment, the list is short, and everything is internal:

There is no outbound line to a vendor: no license calls, no telemetry and no external model. An air-gapped deployment is the proof, since it works with no route out at all. Ports and encryption settings depend on your install, so confirm them against your own configuration.

What is still your job

Being honest about this avoids unpleasant surprises in an audit:

• What goes into telemetry. If an application logs card numbers, they are in your logs. Fix that in the application. Whether controls exist for masking sensitive attributes in Wrentrix is something to ask about, and collectors in your pipeline can also remove attributes before export.
• Storage security. PostgreSQL hardening, disk encryption and backups are your responsibility in a self-hosted system.
• Network segmentation and TLS between components, according to your standards.
• Regulatory interpretation. Tools don't make an organisation compliant. Requirements under frameworks such as KVKK, GDPR, DORA or PCI DSS depend on your context, as the data residency page describes. This is not legal advice, and we make no claim of any certification on this page. For specific security questionnaires, write to info@wrentrix.com.

Frequently asked questions

Does Wrentrix support SSO?

Yes, through OIDC with PKCE, along with LDAP sync. Teams and scoped views can be mapped from LDAP or SSO groups, so access follows the groups you already manage. Whether other single sign-on protocols fit your environment is a question to ask us.

What is PKCE and why does it matter for an internal tool?

PKCE binds an authorization code to the client that requested it, by having the client prove it holds a secret whose hash it sent earlier. It stops an intercepted code from being exchanged for tokens. It's a low-cost protection, and recommended for authorization code flows.

Can I limit which teams see which services?

Yes. Team-based RBAC provides scoped views, mapped from LDAP or SSO groups. Decide how far on-call engineers can see beyond their own team, since narrow scoping can make it harder to diagnose failures that start in a dependency.

Is every change logged?

Yes, there is an audit log of every change. Check how it fits your retention and export requirements, since regulated organisations often keep audit records in a separate system that platform administrators can't alter.

Does Wrentrix need root or privileged access on OpenShift?

No. It runs under the default restricted-v2 SCC with least-privilege pods, no root and no extra SCCs. You can verify this using the openshift.io/scc annotation on the running pods.