Immediate, Automated, Compliant Access Enforcement with Teleport JIT Watcher – Teleport
A common request we hear at Teleport is for immediate Just-in-Time (JIT) access. Users shouldn’t have standing access to resources, but they do need an audited escalation and approval process they can personally execute when access is required. This raises an important challenge: how do we ensure users only access the resources they truly need, without creating access sprawl or slowing teams down? One solution we’ve suggested to our customers is a lightweight, Go-based watcher application that continuously enforces JIT policies. The watcher automatically approves compliant requests, denies violations, and locks old requests when users accumulate too many. You can find the sample application at https://github.com/gravitational/rev-tech/tree/main/proof-of-concepts/jit-watcher
The Access Sprawl Challenge
In many organizations, highly privileged teams such as SREs or DevOps engineers often have wide, persistent access across multiple environments. For example, an engineer may need to deploy to three production clusters at once. Later that same day, they may pivot into dev or research environments. This keeps daily operations moving smoothly. But from a compliance standpoint, it creates increased risks:
- Standing access grows over time
- Least privilege principles are violated
- Access boundaries between environments become blurred
Manual Enforcement Doesn’t Scale
Traditional access controls rely on human review; typically:
- Managers approving requests one by one
- Security teams monitoring who has accumulated too much access
This slows down productivity, creates friction for requesters, and is inconsistent in practice. Compliance policies get applied unevenly, and teams waste valuable time chasing approvals.
Automating Compliance with a Watcher
To address this, we developed a Go-based watcher that connects to Teleport’s gRPC API using Machine ID. Machine ID allows the Watcher to authenticate to Teleport and approve or deny requests, as well as create locks. The watcher polls every 30 seconds, reviews all pending and active access requests, and enforces policy in real time.
What it does:
- Auto-approves compliant requests: No waiting for routine approvals
- Auto-denies violations: Immediate feedback with clear reasoning
- Locks old requests: Ensures users don’t hoard more resources than allowed
This transforms policy enforcement into a seamless, efficient, and fully auditable background process, reducing standing privileges while ensuring the minimum access level is enforced.
The Policies Enforced
Resource limits
The watcher sets a limit of three resources per user at any time. When someone accumulates more than three approved resources, the watcher automatically locks their oldest requests, retaining only the three newest. This means users can continuously request new access as their work evolves, but they can’t hoard permissions indefinitely.
Environment separation
The watcher prevents users from having both production and research access simultaneously. The system detects this by looking for role patterns. Requesting roles containing “prod” and “research” at the same time gets denied, and if a user has separate requests for each environment, the older one gets locked. These role names are configurable within the application.
Immediate feedback
Instead of making users wait for manual approval, policy-compliant requests get approved within seconds. Policy violations are denied immediately, along with clear explanations.
The results
- Reduced manual policy reviews: The approval team focuses on exceptions rather than routine pattern checking
- Fast approvals: Compliant requests continue getting quick approvals, now automated
- Consistent policy enforcement: No more human error in policy application
- Complete audit trail: Every policy decision is logged with clear reasoning
Deploying the Watcher as a Service
For production, the watcher should run continuously. Treat it like any other infrastructure service.
Prerequisites:
- A running Teleport cluster
- A Teleport user with requestable resources via resource access requests
- Machine ID identity file for the watcher with permissions to modify access_requests and locks
Quick start (Local test)
git clone https://github.com/gravitational/rev-tech.git
cd rev-tech/proof-of-concepts/jit-watcher
go build -o jit-watcher main.go
./jit-watcher \
-p teleport.example.com:443 \
-i /opt/machine-id/jit-watcher.identity \
-poll-interval=30s \
-d
Deploying with systemd (Linux)
# /etc/systemd/system/jit-watcher.service
[Unit]
Description=Teleport JIT Watcher
After=network.target
[Service]
ExecStart=/usr/local/bin/jit-watcher \
-p teleport.example.com:443 \
-i /opt/machine-id/jit-watcher.identity \
-poll-interval=30s
Restart=always
RestartSec=5
User=teleport
[Install]
WantedBy=multi-user.target
Enable and start:
sudo systemctl daemon-reload
sudo systemctl enable jit-watcher
sudo systemctl start jit-watcher
Conclusion
Security teams face a dilemma: how to provide developers with the speed they need without compromising compliance. The Teleport JIT Watcher shows that automation can solve both problems:
- Users get fast, self-service access.
- Security teams get enforceable guardrails.
- Organizations gain confidence that least-privilege is consistently applied.
By deploying the watcher as a long-lived service, you eliminate the need for manual policy reviews for routine access, reduce access sprawl, and maintain a clean audit trail, all without slowing teams down.
Teleport Simplifies Just-in-Time Access at Scale
Learn more about Teleport’s approach to just-in-time access, including deeper explanations of capabilities discussed in this post, like access requests, self-contained Just-in-Time Access Request plugins, Machine ID, and Teleport’s gRPC API.
Ready to get auditable and automated JIT built on short-lived certificates, not static secrets? Get in touch with our team to get started.
