Sample petition

Engineering use case

Let's look at a common use case to compare the difference between an Indent Petition and other approaches. The scenario is:

• A customer reported a potentially serious issue in their account.
• After the on-call engineer is paged, they need to work with the support engineer to investigate.
• The support engineer doesn't have standing permissions like the on-call engineer and can't help debug the isssue.

According to security and compliance policies, engineers need to get approval from an engineering manager and the system owner to get permanent access or just one of the on-call engineers in case of an emergency. This routing logic is not very complicated and can be expressed in a few dozen lines of code.

Since this is an emergency workflow, any practical implementation has to ensure that the process is fault-tolerant and scalable.

Status quo

Since it's an emergency, the support engineer will usually just ask the on-call engineer, who likely has broad admin privileges, to grant them access. This can be problematic (or impossible) if access is provisioned based on group membership from an identity provider. In that case, the support engineer will message an IT engineer or someone they know happens to have admin permissions to quickly grant them access. After the incident is resolved, no one remembers to revoke access which is convenient for the support engineer to do their work faster in the future; but, can come up as a violation in the next compliance audit.

General-purpose automation

As the team grows, the status quo stops working because the number of resources grows faster than the company and typically faster than the IT team's headcount. To help automate requests, IT, engineering or security teams will instrument an existing general-purpose automation tools. Whether it's Zapier, Workato or "Company X" Workflows, this works great at first.

Inevitably, users are stuck waiting for requests since it's not clear what stage in the process their request is at. Then user experience feedback comes in asking for round-robin routing, multi-step requirements, disabling self approvals, break-glass escalation or provisioning debugging. At some point, more engineers get pulled in to build fault-tolerance guarantees into a drag-and-drop automation tool.

Custom-built tooling

Some teams with engineering bandwidth will build a custom tool for requesting and approving access. It usually starts with a very specific use case, like support engineers need to access customer data, and purpose, like satisfying privacy compliance and contractual obligations. There are two likely outcomes:

1. Tooling lasts 3-6 months before the engineer who worked on it switches teams and its usage surpasses the initial scope. Whoever changes it last, owns it - which means no one does.
2. Some companies can't afford to let the access control tools to go unmaintained given how critical they are to keeping their operation secure. In some companies, this turns into 5-10 engineers spending 50-100% of their time maintaining the system.

Indent approach

The Indent access control model aims to encompass the breadth of resources across companies' cloud environments, while simplifying the process for everyone. Admins can configure integrations that allows end-users to make self-service access requests and be kept in the loop while waiting. Reviewers, usually managers who are busy in meetings, are automatically messaged for pending tasks waiting on their review.

High-level diagram

Here’s what the overall process looks like when an engineer requests permanent access using Indent to an AWS account that is provisioned via Okta Group:

Why did they get messaged?

How did Indent know to message an engineering manager and the system owner? Let's take a look at the policy to find what caused these messages.

In this case, we have two requirements that must be met. First, the user's manager must approve. If the manager approves, the system owner needs to decide if they should get indefinite access or start with a day or a week. Here is the underlying configuration for this initial use case:

{
  "needManager": true,
  "requirements": [
    {
      "name": "system-owner",
      "reviewers": [
        { "email": "henry@example.com" },
        { "kind": "okta.v1.Group", "displayName": "Senior Engineering Leadership" }
      ],
      "recipients": [
        { "kind": "slack.v1.Conversation", "id": "C123", "displayName": "eng-prod-approvals" }
      ]
    }
  ]
}

Manager approval

Routing to a user's manager uses the managerId label of the user to determine who is their manager. The managerId label is typically imported from an HRIS or identity provider, which can correspond to their manager's email, externalId or id, in ascending priority. This enables Indent to construct an graph of the organization, so that if a user's manager is OOO, it can route to the fallback. In this case, the user's manager Mary was messaged on Slack for approval.

System owner

Companies typically determine system owners based on audit and data classification requirements. They're ususally a manager or team lead for a given service area. When someone leaves, another needs to take over their systems.

In this case, Henry is the current on-call engineer for production and the acting system owner. Once Mary approved, Henry got a message in the public channel so everyone can see when someone requests access to production or, in case of an emergency, a member of senior engineering leadership can approve.