8 Mar 2021
This contribution is a new feature.
In order to understand the problem that the project addresses, you need to be familiar with what a Policy is.
ConsoleMe has a Policies view interface that allows you to list all resources across your synchronized environment from the AWS configuration such as organization's IAM roles and S3 buckets.
You can manage access by creating policies and attaching them to IAM identities (users - group of users - roles) or resources.
A policy is an object that defines permissions when associated with an identity or a resource.
Here is an example of a policy that allows the user to perform all actions (
dynamodb:*) on all the tables of the DynamoDB database in the account
Identity and Access Management (IAM) is a service that helps you control access to your AWS resources.
You can use IAM to control WHO can do WHAT on which RESOURCES.
ConsoleMe has a native policy editors which allows users to create or edit IAM roles, SQS queues, SNS topics, and S3 buckets.
It would be interesting to show to the user the potential linting errors he may have in his document.
Here are the user stories we will use as a reference:
As a TYPE_OF_USER, I want SOME_GOAL so that SOME_REASON.
- As a User I want to see the different linting errors on the editor so that I can directly see which lines need updates.
- As a User I want to see the severity of the different linting errors so that I can directly focus on top priority errors.
- As a User I want to see the details of the different linting errors so that I can understand what I need to change.
CheckPoliciesHandler handler will be used to retrieve policy errors based on the provided policy string.
We will call the method
analyze_policy_string from the
parliament library which will return a
We will then need to enhance each of the elements to get the complete findings because the non-enhanced Finding representation is a simple string:
ISSUE - DETAIL - LOCATION
CheckPoliciesHandler will be mapped to a new route
In order to test our handler, we will need to mock the
parliament.enhance_finding method calls.
We can now test our handler by simulating a fetch with a given request body.
We can then test that the response of the fetch is the expected one (status code
200 and correct response body).
We will add a new entry for our route
/policies/check with a documentation about the request body and the response schema.
The idea is pretty straightforward, every time the User will edit the policy, we will trigger a timeout of
CHECK_POLICY_TIMEOUT to check the linting errors of the document.
The lint check is done with a delay to avoid too many calls when the user edits the document.
We will use the
deltaDecorations method on the editor instance.
A decoration accepts some
options and a
range with the values
The parliament library can return 6 different severity type which we will group into 3 severity levels:
MUTE | INFO | LOW
HIGH | CRITICAL
These groups allow us to display errors with a different color in the editor.
This lets the user identify the different level of severity at a glance.
The code bellow will allow us to display a highlighted area of the editor where the error is located.
hoverMessage attribute is used to display the linting error detail to the user on hover.
Here is the final result that identifies bad IAM policy patterns in the editor.
Every time we update the policy document, a timeout is triggered and when it ends, the linting error fetch is made and the errors are highlighted in the editor.
Setting up the project was a bit tedious and asked me to set up some things on my AWS account to be able to test behaviors locally.
I also had to modify the versions I had a few times, so it took me a little longer than expected.
This contribution allowed me to learn more about IAM Policies and its usage in a concrete use case.
In addition, the architecture of the project was interesting and challenged me to set up my development environment and test the platform.