Teleport Access Requests Just in Time Infrastructure Cloud Applications
You set up teleport access requests just in time infrastructure cloud applications by linking roles to chat tools. An engineer asks for a role, a manager approves it, and the timer starts. Most teams start by mapping broad group roles to their cloud apps and servers. This habit gives users too much power once they log in to a system. A user who needs to read one table often gets full write rights. How teleport access requests just in time infrastructure cloud applications work The native flow
Teleport + Just-in-Time Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up teleport access requests just in time infrastructure cloud applications by linking roles to chat tools. An engineer asks for a role, a manager approves it, and the timer starts. Most teams start by mapping broad group roles to their cloud apps and servers. This habit gives users too much power once they log in to a system. A user who needs to read one table often gets full write rights.
How teleport access requests just in time infrastructure cloud applications work
The native flow relies on role definitions inside the main cluster control plane. First, an admin creates a base role with very few rights for daily work. Next, the admin builds a higher role that grants entry to target servers. The base role includes a rule that lets the user ask for the higher role.
When an engineer needs to fix a bug, they send a request. The system routes this prompt to a chat app or a ticket tool. A peer or manager checks the reason and clicks approve in the chat window. After approval, the user fetches a new short-lived cert with the higher role.
This cert lets the user log in to the database, server, or cloud app. When the timer runs out, the cert expires and the user loses the role. The system writes the request, the approval, and the login event to an audit log.
What role requests solve and what they leave open
Role requests solve the problem of permanent standing rights across your cloud fleet. Engineers do not hold admin keys while they sleep or do normal work. Auditors can see who asked for a role and who said yes. If an attacker steals a basic user profile, they hit a wall right away.
Still, a role request only decides who can open a session to a resource. Once the session starts, the user holds all rights tied to that role. If the approved role allows write actions, every command in that session can change data. The approval step happens before login, not when a risky query runs.
Teleport + Just-in-Time Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Database admins often bundle read and write rights into one repair role for speed. During an outage, a tired engineer with an approved role can drop a table. In the same way, a broad read role exposes raw emails and phone numbers. Role timers expire after the work, so they do not filter live queries.
Why teams separate login roles from live command rules
To close this gap, teams split entry checks from in-session command checks. Entry roles should grant the ability to reach a target system and run safe reads. High-risk actions like deletes or schema changes need a check at the command level. This approach keeps daily work fast while guarding against bad commands in prod.
Teams also pair command checks with field masking on live query results. When a user runs a select query, masking rewrites card numbers and national IDs. The engineer can check app state and fix bugs without pulling raw user secrets. Splitting login roles from query rules keeps data safe during every active session.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How do role requests differ from command approvals?
A role request grants a full login session to a server or database for a set time. A command approval checks a single query or script right before it runs.
Can temporary roles prevent accidental data deletes in prod?
No, if the temporary role includes write rights, the user can still delete rows or tables. Stopping bad deletes requires inspecting the statement during the active session.
How does data masking work during a temporary database session?
Masking inspects query results in flight and rewrites matched fields like emails or phone numbers. The user runs normal queries, and the system replaces sensitive values in the output.