Managing just-in-time permissions in a developer portal

JIT permissions ensure unrestricted access is not being given to employees who don’t need it - and the way to manage JIT permissions without creating further complexity is in a portal 

Why least privilege is needed and why it’s difficult to do

Developers often need temporary access to critical assets, such as an application in production or a database. Organizations are increasingly adopting a policy of least privilege - meaning that for security reasons, users are given the least amount of access they require to do their day-to-day jobs, reducing security risks and ensuring compliance. This comes at a time when cybersecurity insurers are scrutinizing how privileged access is managed in return for an insurance policy or lower premiums, providing additional incentive for enterprises to consider restricting privileges. 

However, while closing off access to developers may benefit an organization’s security posture, it means that developers have to fill out tickets to obtain the access that they require. This adds workload to the ops teams, who have to respond to the tickets, and hinders the velocity required, especially while dealing with incidents. What’s worse is this can even lead to temporary permissions never being revoked. This means that ‘always-on’ unrestricted access is being given to employees who don’t need it. 

Just in time permissions

Engineering teams want to reduce the workload on ops and ensure ‘always-on’ access no longer happens. They want a single source of truth where they can get reports of who accessed what and when, helping them to adhere to security requirements or use an audit trail to check what happened. 

To accomplish this, ops use  just-in-time (JIT) permissions. JIT permissions enable teams to provide users with self-service to obtain elevated privilege access to an application or system to perform a task. This access can be granular - meaning rather than granting always-on or standing access, an individual can only access privileged resources when they need them. This reduces the amount of exposure time that privileged resource or system has with any individuals outside of the core people who require access to it and allows for the developer to get the access they need in a timely manner. Just-in-time permissions provide the ideal way to implement a least-privilege policy, while keeping response times low. 

Why JIT permissions belong in an internal developer portal

One of the first classic use cases we see is platform engineers configuring portals to provide JIT permissions. Why is that?

• Firstly, one of the core pillars of a portal are self-service actions. These actions can be determined by platform engineers, in this case granting developers the JIT access they need, meaning developers don’t have to submit tickets to the ops teams. In some cases, these actions can be configured with a TTL or with an additional manual approval step.
  
• Secondly, traditional access management tools aren’t able to (and weren’t developed) to secure cloud assets. They were created at a time when the software developer lifecycle looked completely different, and today they struggle to keep up with the number of applications, data repositories and clouds in any environment.
• Specific cloud-native platforms that seek to manage permissions may aim to simplify the approach to authentication measures, but they’re yet another tool to add to a growing stack for platform engineers and developers to learn and use. This is at a time when the cognitive load for developers is at an all time high, and platform teams are seeking ways to help abstract away complexity for developers, not add to it. They themselves don’t want or need another tool to manage.

It’s for this reason that platform engineers have been implementing Internal Developer Portals - providing a centralized place for developers to perform actions. This is their go-to place for everything from finding information to spinning up dev environments. It’s therefore a natural fit to manage everything - including permissions - from the portal, making it easier to audit and for reporting.

Another advantage of implementing JIT permissions is that the portal’s software catalog holds a lot of information such as which workloads are in production, who’s on call, and what team the user is a part of. This enables platform teams to get very granular and add context while defining their permissions policy. For instance, you could give automatic access to staging and test environments or if you’re on call for a specific service and an incident is ongoing, and request a manager’s approval for production. 

The portal enables platform leaders or managers to get full visibility of all permission requests - not just JIT permissions - with audits of access patterns, meaning they can: keep track of who’s accessing what and when, gain insight into any trends, and generate reports with ease and stay compliant. The portal enables you to keep track of everything proactively, but can also help you to apply, restore or revoke credentials and permissions when necessary. All of this means you can seamlessly meet regulatory and customer security requirements, including SOC2 and PCI-DSS.

How to implement JIT permissions in a portal 

1. Start by mapping your environment

Get a full picture of your privileges by gaining an understanding which assets, resources and systems pose the highest risk, and which of these may require temporary access on a frequent basis - such as access to databases. You should also identify which users and accounts have the most privileges and if these are suitable going forward. A portal with a flexible data model enables you to customize the portal to fit your specific environment and the unique way your organization operates. 

2. Determine which scenarios require JIT permissions

In what cases do you want to give access automatically to developers and in which cases do you need a manager’s approval? There are some more obvious scenarios where automatic access makes sense, but there are others which may only occur infrequently and therefore you need to establish criteria for any user that is requesting temporary access, decide which accounts are eligible and how long the permission should be granted for each scenario. 

3. Determine responsibilities

Determine which person or people review permission requests, and train them on different scenarios. 

4. Always ensure TTL

Ensuring you limit the lifespan or lifetime of a permission is crucial - as is making sure it works. Once the timespan has elapsed, the permission is revoked, so developers can gain access for troubleshooting without the long-term security risks. You can also determine if you want to let the user decide how long they want the permission or if it is pre-defined. Port offers flexible forms that you can adapt to any scenario. 

5. Why was permission requested? Just ask

Consider adding a field into the self-service action form which asks for the reason for the permission request, especially if a manual approval is required. This is useful for auditing purposes too. 

‍

‍The Port Takeaway 

A policy of least privilege is difficult to enforce if your developers are submitting tickets to ops every time they require access to something. Just in time permissions are the solution to this problem, but legacy tools are not cut out for the job and cloud-native specific JIT tools add more cognitive load for developers. Internal developer portals can provide JIT permissions by utilizing self-service actions, with customizable forms, making life easier for developers and managers. In addition, portals provide TTL automations and visibility for managers in one, centralized, easy-to-use place. 

Want to start implementing JIT permissions? Check out our IAM Permission Management guide.