Roll back IAM role / resource policy with context from AWS Config

[castrapel]

AWS Config provides us with the historical policy context of IAM roles and other resources in a configuration history timeline. We want the ability to "revert" roles and resources to a previous state when provided with this context.

Please let us know if you're interested in working on this issue.

[sheikhrachel]

I'm interested! Do you have more details about what the desired user flow would be for this addition?

[castrapel]

Hi @sheikhrachel, thanks so much for your interest! I'm happy to discuss this over Meet or Zoom with you, feel free to reach out to me on Discord (curtis#9958) if you're interested.

Here are some of my initial thoughts:

It will be easier to implement the V1 MVP of this feature as view-only for end-users of ConsoleMe (End users can see a role's historical policies), and only allowing administrators to perform "Roll backs" for "IAM roles" (If desired, we can even just start with a read-only feature and add roll backs in a second PR).

Later, we can consider adding support for:

1. Rolling back other resource types
2. Adding a "request rollback" feature, where end-users can request the rollback of a role that an administrator would need to approve.

For this feature, I'm thinking about a new tab on the IAM role policy editor (example) (Perhaps called "History").

It would show the historical context of a role based on what AWS Config provides. End-users can view the role's JSON policy context at a certain point in history. Administrators can click a magic button to roll it back (It's fine if we want to defer the roll back functionality for V2). There are some screenshots of the resource timeline below. However you'll note that the view of the policy here isn't very readable. We'll want to parse the JSON and make it prettier. I can help with the backend code for this.

Here's what the "Resource Timeline" feature looks like in AWS:

Here's what the policy diff view looks like (We might be able to use the MonacoDiffComponent to show this in the UI):

What are your thoughts?

[sheikhrachel]

I think v1 as read-only for all users makes the most sense. The initial work I've scoped is:
Backend:

• migrate the ResourceDetailHandler endpoint from /api/v2/resources/ to /api/v2/resources/detail
• create a new /api/v2/resources/history endpoint served by ResourceHistoryHandler to fetch from list_discovered_resources
• create a new /api/v2/resources/history_item endpoint served by ResourceHistoryItemHandler to fetch from get_resource_config_history

Frontend:

• Create a new History tab. I'm unsure of how we want to prompt user input of a resource type (EC2, S3, etc), but definitely open to discussion. Preset buttons might be useful, but I'd love to hear more of your thoughts on it.
• Once a user has selected a resource type, we pass this into /api/v2/resources/history to fetch all discovered resource items for that type, and display a list of blocks for those items. Currently the response object gives us the resource name, resource id, and resource deletion time, but we can fetch other resource-specific metadata elsewhere if needed.
• A user can tap onto one of the blocks and open up a new view, served from /api/v2/resources/history_item. This gives us the full history of resource versions, and we can serve this through MonacoDiffComponent. I'm unsure if this is best served with another list of condensed block items that correspond to all of the resource versions, and expanding a block here can show the MonacoDiffComponent for that version vs the current version.

Extras:

• Both endpoints support pagination, we can wire these into < and > buttons that make additional calls to the respective endpoint
• /api/v2/resources/history_item supports returning the payload sorted in both forward and chronological order, we can tie this up to a button as well and insert it as a boolean is_forward_order. It also supports ingesting a date range to fence in the payload range. We can read this in from a field and convert it to the correct datetime object. I'm thinking this would live in a layer of inputs and they don't execute changes until a user presses a submit button.
• /api/v2/resources/history supports filtering the return for non-deleted resources and for specific resource ids, but I'll hold back on adding user support for that until we talk about whether we want to provide that or not.

v2 will include adding in the endpoint for rolling a resource back and adding that handling to the final user view if they are an administrator. But I'm anticipating that to be an easy lift once I make it over the front-end hurdle of v1 and get more familiar with the codebase.

[castrapel]

This sounds like a reasonable start to me.

For History, I'm thinking about starting with only IAM roles, and in future iterations, S3 buckets, SNS topics, and SQS topics. As we support policy edits and requests to additional resource types, we can also add history support for those resources (As well as rollback).

Frontend:

We could support this view in the context of the existing Policy Editor for a given resource (And just show an extra view for history). We would already have context on what resource ARN the user is viewing, and perhaps additional metadata that would be useful for querying

History view - this one's a bit subjective, and I'm open to differing opinions here. We could by default show a MonacoDiffView and having a date dropdown for the left view, and a date dropdown for the right view. By default, Right side = latest, and left side = version previous from latest.