Access Request Workflow

[JoshuaWilkes]

Common Fate has been built around the concept of Access Rules -> Access Requests
Admins create access rules by defining:

• What
• Who
• How Long
• Approval

These rules would be given a name and description, and end users would hopefully be able to find the rule which lets them request access to the thing they want to access.

We want to make this better.

This process is not very flexible, and we think that users don't care about access rules, they just care about access.
So why should they start requesting access by choosing a rule?

Instead, we are proposing a resource first request workflow which will flow something like this:

1. Selects the kind of Entitlement

The available entitlements depend on which Access Providers have been connected to Common Fate.
For example, AWS Account, Okta Group, GCP and AWS CloudWatch Log Group to name a few.

2. Select the Resources for each Entitlement

Assuming the user selects AWS Account, they will then be able to select combinations of Account and Permission Set that are available to them.
The great part here is that users will be able to select from accounts and permissions sets that are available through any of the access rules they are assigned rather than just from one per request.
The user is able to select as many "targets" as they need, these could be accounts across your Dev, Staging and Prod environments all at the same time.

Additionally, these targets don't all need to be for the same entitlement! If needed, a user will now be able to request many entitlements in the same request. Think, requesting access to an admin role in Github, and an AWS account to setup an OIDC connection for Github actions.

All in the same request, tracked against the same purpose.

3. Submit a Preflight

Once all targets are selected, a preflight check is performed against the entitlements. The targets that the user requested are grouped based on access rules automatically by the backend and a response is sent to the client.

Now the user sees how long they can access each group of targets. Some targets may have matched to access rules with different configuration, like a production account with a maximum of 30 minutes access. They will also see the approval policy for each group which gives an indication of when they will be granted the access.

Finally, add a reason for access, which will apply for all of the access being requested.

4. Submit the Request

In the current version of Common Fate, requesting access to multiple targets is possible, but the effect is that under the hood, multiple requests are created, this is difficult to track, and the reason if given, is duplicated across all of the requests.

If an approval is required, the approver needs to approve each request one by one. We have had feedback about this being sub-optimal.

In the new request workflow, approvers will be able to approve a whole group of targets in a single approval step.

Our best practice for using Common Fate is that all targets on an access request should be requested for the same purpose, so users will only need to enter their purpose for access once, and after they submit their request. All the requested access can be tracked as a group and viewed in the UI on a single page.

As well as this, cancelling or revoking all access for the same purpose becomes much simpler, with a single action, all related access can be cancelled, saving valuable time and effort.

Additionally, Access Rules will allow multiple targets, meaning a team could create one catch all rule which requires approval, for all resources in their organisation.

Here are some wireframes for the proposed new workflow.

[alexjurkiewicz]

Interesting!

As we've discussed before, I think the ability to request access across multiple provisioners is useful for us. However I'm less convinced by the ability of users to heavily customise their "shopping basket" of requested access.

We are happy with giving developers a request workflow granting access to (for example) everything in production. This might include an AWS permission set, EKS admin access, and Datadog admin.

In the context of this RFC design I think the currently deployed UI is fine. It "just" needs an enhancement so that admins can "bundle" multiple workflows into a single request.

To talk about why we want this: because it's simpler. Understanding the exact permissions needed to debug an issue in production is complex and time consuming. It's not a skill developers already have and it's not going to add value for them to learn. At most in future we'd like to give developers the ability to select which of our services they need to access, and each service would have a hardcoded, admin maintained list of permissions it corresponds to. And we could do this by replacing "production access" request workflow with 200 "production access (microservice foo)" workflows and a search bar

[JoshuaWilkes]

I have been thinking about this usecase of curated requests based on known workflows in the org.

Something that may be great here is creating an access rule which grants access to a range of targets, then also being able to create the curated requests on the same screen, propagate these to users as a one click request, and also give them the option to make a custom request as described in this rfd

[ellie-narducci]

I second this. If we can allow Common Fate admins to create a curation of entitlements with a designated purpose this will greatly assist the user flow. I will add this to roadmap considerations.

[perpil]

+1 on the curated request. I'm a creature of habit, it is rare I need bespoke credentials. The credentials I need are related to the microservice or use-case I'm interested in and it's important I can get them quickly without much thinking. The way I personally handle this is to have 2 dropdowns, 1 to pick the microservice and the other to pick the use case. Another way is to set the role in my runbook, but use the dropdown to pick the account/microservice I want to operate in so I can change my runbook to work for a particular stage. If I have a reason, I always have an external id, i.e. a trouble ticket/github issue/CM. I'm ok with having multiple sets of credentials to access different accounts as long as I can associate them with the same external id. The only reason I need bespoke credentials is if I'm executing a CM which requires some special permissions (i.e. I need to update Route53 which isn't an ordinary permission I'd associate with the microservice for safety). So I'd recommend optimizing the ui for the canned use-case, but make it possible to create bespoke requests and new canned use-cases. Perhaps a good thought experiment to optimize this for is "I want to do X, give me the minimum permissions, as quickly as possible with the least cognitive load"

[ellie-narducci]

This is great, thanks for the feedback @perpil

[Nexus2k]

I like the idea and flow of this RFD but more in addition to what's existing today and not as a replacement. E.g. have an extra "Create custom access request" option that goes thru this flow next to the pre-defined access rules.

[ellie-narducci]

Thanks for the feedback @Nexus2k! If this new workflow is adopted we will be sure to integrate a way for admins to create curated policies for end users, much like the way Access Rules currently behave.