Granular and Seamless Just-in-Time (JIT) Access with Teleport

As software companies grow, they start to see exponential growth in resources needed to support the business. A startup can quickly go from a few servers and a handful of databases to a sea of Kubernetes clusters. Managing access to all of these resources comes with a myriad of problems. One problem at scale is deciding who can access what resources and how to provide relevant access to those resources on-demand.

In Teleport 10, we've released Resource Access Requests, which allows engineers to request just-in-time access to infrastructure resources and therefore build an inventory of resources they need to access without the need to think about roles and privileges. This blog post explains how Teleport's existing role-based Access Request and the newly released Resource Access Request feature offer a granular and seamless just-in-time (JIT) access experience for infrastructure access.

What is just-in-time (JIT) access?

Just-in-time access refers to a secure access workflow where users are granted access to roles or resources only when they need them. This workflow allows administrators to implement Zero Standing Privilege where users are not pre-assigned with roles and privileges, and are assigned with a role only when they require access. Implementing JIT access is a critical security control. It is usually based on an approval workflow where users request administrators with details for access requirements during access time. Upon verification, administrators approve the request, allowing users to continue access.

How Teleport implements just-in-time access

Teleport's just-in-time system is based on Teleport Access Requests. In a nutshell, Teleport Access Request is a workflow available in Teleport where users who need to access roles and resources initiate a request to administrators with a reason for access. Upon verification, administrators may grant or deny access to roles and resources. Once approved, the end-user has a customizable time-boxed period to perform actions defined in the role.

The basic requirement of the just-in-time implementation involves assigning an access request and access granting workflow along with the condition (properties) of access granted. There are various ways a JIT system can be implemented. Below, we match three JIT requirements with the Teleport Access Request:

1. Access requesting system

• Description: User flow to request access.
• Teleport implementation: User-initiated flow or automatically initiated from tsh client. Users can request access to roles and resources.

2. Access granting system

• Description: Administrative flow to review the request and grant or deny access.
• Teleport implementation: Administrators are notified via ChatOps platform (Slack, Mattermost, etc.). Upon clicking the notification, the request details are opened in Teleport Web UI.

3. Properties of the access granted

• Description: Properties that are granted upon approval. These may include shared secrets, proxy-injected credentials, access to roles, network connectivity to resources that are subject to access, and whitelisting resources for access.
• Teleport implementation: Short-lived and scoped access certificates that automatically expire after allocated time-to-live.

How Teleport enables granular and seamless just-in-time access

So how does Teleport’s Access Request offer a granular and seamless JIT access? Below are the five major points of Teleport’s Access Request feature:

1. Short-lived and scoped access principle

This is probably the most important factor to consider in a JIT system. If the access is granted for a day when the user only needs to access the resource for an hour, the notion of "just-in-time" fails here because of long-lived access.

Teleport issues a new time-bound, short-lived, and scoped certificate to users, which can be used to access the resources they need to access. The time-to-live for the requested roles can be set in a role config file as:

max_session_ttl: 1h

2. Avoiding “blanket” roles

As infrastructure resources grow, administrators often create and grant "blanket" roles that cover multiple resources. Such blanket roles allow users to access resources they may not need to, potentially giving malicious users a chance to access unauthorized resources.

With Teleport Resource Access Request, the scope of the granted roles can be limited to only required resources in a granular fashion.

3. Reducing roles fatigue

Users only need to know the details of the resource they need to access, not the roles. When privileged management systems are implemented to address the principle of least privilege, the number of roles and privileges may grow exponentially, which can become challenging for administrators to set up and track.

In Teleport Access Request, administrators can configure pre-authorized roles during the initial setup. The users are only allowed to request roles that they are entitled to. During the time of access, users only need to search for the name of the resource they want to access, and Teleport automatically assigns users with the pre-authorized role.

4. Granular scope with role, resource and TTL

With Teleport Access Request, the scope of just-in-time access can be narrowed down to role, resource, and time-to-live (TTL), enabling a granular level of access control. The combination of roles, resources and ttl allows to:

• Promote principles of least privilege (only assign required roles).
• Reduces attack surface (scope down roles to only resources that users need to access).
• Reduce threats of privilege theft (auto expiring access grants).

5. Extensible API

Teleport out-of-the-box integration with ChatOps platforms like Slack or Mattermost makes it very easy for modern teams to have seamless access granting experience as most of the teams heavily rely on these platforms for day-to-day communication. Teleport also provides an access request API enabling teams to roll out custom approval workflow or integrate with in-house ticketing systems.

Just-in-time workflow using Teleport Access Requests

Teleport supports two methods of Access Requests: role-based and resource.

Role-based Access Request

Available since Teleport 7, role-based Access Request allows users to request access to login roles. First, Teleport administrators would assign a user with a role that only allows requesting for another role. Then when the user needs to access a privileged role to access remote resources, the user can initiate an Access Request asking for a required role.

This Access Request flow is as simple as executing the following command:

$ tsh login --request-roles="kube-member" --request-reason="Need access to Kubernetes cluster for debugging"

Once the user sends an access request, the Teleport administrator receives a notification in the configured ChatOps or ticketing platform. Below is a sample notification as received in Slack.

Then upon review, if the request seems truthy, the administrator can grant a role with command as simple as:

$ tctl request approve --roles=kube-member --reason='Approved' e5baed8-6207-4261-90ea-3d325b61804c

Requests can also be granted or denied by using Teleport Web UI.

Resource Access Request

With Teleport 10, we've now released Resource Access Request, which, instead of roles, allows requesting access to a list of infrastructure resources. Along with the feature to request access to resources, we've added a search feature that can be used to search available resources (in-scope of access) as well as guided workflow in tsh client, which automates the resource access request process.

When a user needs to access a specific resource, for example, an SSH server, but needs to initiate an Access Request, the regular tsh ssh command will automatically create an Access Request for the user (given the user is in the scope of resource access request).

$ tsh ssh user@resource1
ERROR: access denied to user connecting to resource1 on cluster teleport.example.com
You do not currently have access to alice@resource1, attempting to request access.
Enter request reason: grant access
Creating request...
Request ID: ab43fc70-e893-471b-872e-ae65eb24fd76
Username: user
Roles: access
Resources: ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]
Reason: "debug production node"
Reviewers: [none] (suggested)
Status: PENDING
hint: use 'tsh login --request-id=<request-id>' to login with an approved request
Waiting for request approval...
Approval received, reason="okay"
Getting updated certificates...
resource1:~ user

In a large infrastructure, it may not be possible to remember all the names of resources. To address this, we've also implemented a resource search feature that can be used to search for resources. The example below shows searching for a Linux server in the Teleport cluster:

$ tsh request search --kind node

Name                                 Hostname    Labels       Resource ID
------------------------------------ ----------- ------------ ------------------------------------------------------

b1168402-9340-421a-a344-af66a6675738 iot         test=test    /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738

bbb56211-7b54-4f9e-bee9-b68ea156be5f node        test=test    /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f
To request access to these resources, run

> tsh request create --resource /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738 
--resource /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f \
--reason <request reason>

Integration with ChatOps platforms and request granting/denying workflow remains the same for administrators. A notification is sent, and all approvals are completed within Teleport.

Try Teleport Access Requests access today!

Both Teleport role-based Access Requests and Resource Access Requests are available in Teleport 10 (Enterprise license required).

👉 Sign up for Teleport Cloud or download Teleport 10 from our download page.
👉 Read product documentation on Teleport Access Request to get started and the tutorial on setting up Role-based Access Request.
👉 Join the Slack channel, where Teleport users and developers hang out for community support.

Also in Teleport 10:

We've also released Passwordless Access, Proxy Peering, Machine ID for Kubernetes and many other cool features in Teleport 10. Read more on what's new in Teleport 10.