New IAMCTL tool compares several IAM policies and functions
If you have several Amazon Web Services (AWS) accounts, and you also have AWS Identity and Access Management (IAM) roles the type of multiple accounts which are supposed to be comparable, those roles may deviate over time from your own intended baseline because of guide actions performed directly out-of-band called drift. Within regular compliance checks, you need to concur that no deviations are had by these roles. In this article, we present an instrument called IAMCTL which you can use to extract the IAM functions and plans from two accounts, evaluate them, and record out the data and differences. We shall explain how exactly to use the tool, and will explain the key concepts.
Prerequisites
Before you install IAMCTL and begin using it, below are a few prerequisites that need to stay put on the computer where you’ll run it:
To check out along in your atmosphere, clone the data files from the GitHub repository, and run the steps within order. You won’t incur any fees to run this device.
Install IAMCTL
This section describes how exactly to install and run the IAMCTL tool.
To install and operate IAMCTL
-
- At the order line, enter the next command:
You shall see output like the following.
Figure 1: IAMCTL device installation output
- At the order line, enter the next command:
concur that your installation was successful
- To, enter the next command.
You shall see results much like those in figure 2.
Figure 2: IAMCTL help message
Given that you’ve successfully installed the IAMCTL tool, another section shall demonstrate how to utilize the IAMCTL commands.
Example use scenario
Here is a good example of how IAMCTL may be used to find differences in IAM roles between two AWS accounts.
Something administrator for something team is attempting to accelerate something launch in the center of testing cycles. Developers have discovered that exactly the same version of these application behaves differently in the development environment when compared with the QA environment, plus they suspect this behavior is because of differences in IAM policies and roles.
The application form called “app1” primarily reads from an Amazon Simple Storage Service (Amazon S3) bucket, and runs on an Amazon Elastic Compute Cloud (Amazon EC2) instance. In the development (DEV) account, an IAM can be used by the application form role called “app1_dev” to gain access to the S3 bucket “app1-dev”. In the QA account, an IAM can be used by the application form role called “app1_qa” to gain access to the S3 bucket “app1-qa”. That is depicted in figure 3.
Figure 3: Showing the “app1” application in the development and QA accounts
Setting up the scenario
To simulate this setup for the purpose of this walkthrough, you must create the EC2 instance or the S3 bucket don’t, but concentrate on the IAM role just, inline policy, and trust policy.
As noted in the prerequisites, you’ll switch between your two AWS accounts utilizing the AWS CLI named profiles “dev-profile” and “qa-profile”, which are configured to indicate the QA and DEV accounts respectively.
Start by by using this command:
The command creates a directory structure that appears like this:
Iamctl_test
|- qa
|- dev
Now, switch to the dev folder to perform all of the following example commands contrary to the DEV account, employing this command:
To create the mandatory policies, develop a file named “app1_s3_access_policy first.json” and add the next policy to it. You shall utilize this file’s content as your role’s inline policy.
Second, develop a file called “app1_trust_policy.json” and add the next policy to it. You shall utilize this file’s content as your role’s trust policy.
Now utilize the two files to generate an IAM role with the name “app1_dev” in the account through the use of these command(s), run in exactly the same order as right here:
In the QA account, the IAM role is known as “app1_qa” and the S3 bucket is known as “app1-qa”.
Repeat the steps from the last example contrary to the QA account by changing dev to qa where shown in bold in the next code samples. Change the directory to qa employing this command:
To create the mandatory policies, develop a file called “app1_s3_access_policy first.json” and add the next policy to it.
Next, develop a file, called “app1_trust_policy.json” and add the next policy.
Now, utilize the two files created up to now to generate an IAM role with the name “app1_qa” in your QA account through the use of these command(s), run in exactly the same order as right here:
Up to now, you have two accounts having an IAM role created in all of them for your application. With regards to permissions, you can find no differences apart from the real name of the S3 bucket resource the permission is granted against.
You may expect IAMCTL to generate a minor set of differences between your QA and DEV accounts, assuming all the IAM policies and roles will be the same, but to be certain about the present state of both accounts, in IAMCTL it is possible to run an activity called baselining.
Through the procedure of baselining, you’ll generate an equivalency dictionary that represents all of the known string patterns that decrease the noise in the generated deviations list, and you’ll introduce a noticeable become among the IAM roles in your QA account, followed by your final IAMCTL diff showing the deviations.
Baselining
Baselining is the procedure for bringing two accounts to an “equivalence” state for IAM roles and policies by establishing set up a baseline, which future diff operations can leverage. The procedure is really as simple as:
- Run the iamctl diff command.
- Capture all string substitutions into an equivalence dictionary to eliminate or reduce noise.
- Save the generated detailed files as a snapshot.
You can proceed through these steps for the baseline now.
Go on and run the iamctl diff command against both of these accounts utilizing the following commands.
The total outcomes of running the init command are shown in figure 4.
Figure 4: Output of the iamctl init command
If you go through the iamctl_test directory now, shown in figure 5, you can view that the init command created two files in the iamctl_test directory.
Figure 5: The directory structure after running the init command
Both of these files are the following:
- iam.jsonA reference file which has all AWS actions and services listed, among other activities. IAMCTL uses this to map the resource listed within an IAM policy to its corresponding AWS resource, predicated on Amazon Resource Name (ARN) regular expression.
- equivalency_list.jsonThe default sample dictionary that IAMCTL uses to suppress false alarms when it compares two accounts. That’s where the known string patterns that require to be substituted are added.
Note: A best practice would be to make the directory where you store the equivalency dictionary and that you run IAMCTL to be always a Git repository. Achieving this enables you to capture any modifications or additions for the equivalency dictionary through the use of Git commits. This will not merely offer you an audit trail of one’s historical baselines but additionally gives context to any additions or modifications to the equivalency dictionary. However, achieving this is not essential for the standard functioning of IAMCTL.
Next, run the iamctl diff command:
Figure 6: Consequence of diff command
Figure 6 shows the full total outcomes of running the diff command. You can view that IAMCTL considers the app1_qa and app1_dev roles as unique to the QA and DEV accounts, respectively. It is because IAMCTL uses role names to choose whether to compare the role or tag the role as unique.
You’ll add the strings “dev” and “qa” to the equivalency dictionary to teach IAMCTL to substitute occurrences of the two strings with “accountname” with the addition of the follow JSON to the equivalency_list.json file. You’ll tidy up some defaults already within there also.
Figure 7 shows the equivalency dictionary before these actions are taken by you, and figure 8 shows the dictionary after these actions.
Figure 7: Equivalency dictionary before
Figure 8: Equivalency dictionary after
There’s one more thing to here notice. In this example, one common role was flagged as having an improvement. To learn which role that is and what the difference is, go directly to the detail reports folder listed in the bottom of the summary report. The directory structure of the folder is shown in figure 9.
Observe that the reports are manufactured under your house directory with a folder structure that mimics enough time stamp down to the next. IAMCTL does this to keep uniqueness for every run.
Figure 9: Files written to the output reports directory
You can see there’s a file called common_roles_in_dev_with_differences.csv, also it lists a job called “AwsSecurity***Audit”.
You can see there’s another file called dev_to_qa_common_role_difference_items.csv, also it lists the granular IAM items from the DEV account that participate in the “AwsSecurityAudit” role when compared with QA, but that have differences. You can view that entries in the DEV be had by the file account number in the resource ARN, whereas in the qa_to_dev_common_role_difference_items.csv file, all entries have the QA account number for exactly the same role “AwsSecurityAudit”.
Add both of the account numbers to the equivalency dictionary to substitute them with a placeholder number, as you don’t want this role to obtain flagged as having differences.
Now, re-run the diff command.
As you can plainly see in figure 10, you obtain back the consequence of the diff command that presents that the DEV account doesn’t have any differences in IAM roles when compared with the QA account.
Figure 10: Output showing no differences after completion of baselining
This concludes the baselining for the QA and DEV accounts. You will introduce a big change now.
Introducing drift
Drift occurs if you find an improvement in actual vs expected values in this is or configuration of a resource. There are many explanations why drift occurs, but also for this scenario you’ll use “intentional have to react to a time-sensitive operational event” as grounds to mimic and introduce drift into everything you have built up to now.
To simulate this noticeable change, add “s3:PutObject” to the qa app1_s3_access_policy.json file as shown in the next example.
Put this new inline policy on your own existing role “app1_qa” employing this command:
The next table represents the brand new drift in the accounts.
| Action | Account-DEV Role name: app1_dev |
Account-QA Role name: app1_qa |
| s3:Get* | Yes | Yes |
| s3:List* | Yes | Yes |
| s3: PutObject | No | Yes |
Next, run the iamctl diff command to observe how it accumulates the drift from your own previously baselined accounts.
Figure 11: Output showing the main one deviation that has been introduced
You can view that IAMCTL now implies that the QA account has one difference when compared with DEV, that is what we expect in line with the deviation you’ve introduced.
Start the file qa_to_dev_common_role_difference_items.csv to check out the main one difference. Again, adjust the next path example with the output from the iamctl diff command in the bottom of the summary report in Figure 11.
As shown in figure 12, you can view that the file lists the precise S3 action “PutObject” with the role name along with other relevant details.
Figure 12: Content of file qa_to_dev_common_role_difference_items.csv showing the main one deviation that has been introduced
You can use these details to remediate the deviation by performing corrective actions in either your DEV account or QA account. It is possible to confirm the potency of the corrective action by re-baselining to make certain that zero deviations appear.
Conclusion
In this article, you learned how exactly to utilize the IAMCTL tool to compare IAM roles between two accounts, to reach at a granular set of meaningful differences you can use for compliance audits or for further remediation actions. If you’ve created your IAM roles through the use of an AWS CloudFormation stack, it is possible to start drift detection and easily capture the drift due to changes done beyond AWS CloudFormation to those IAM resources. To find out more about drift detection, see Detecting unmanaged configuration changes to stacks and resources. Lastly, start to see the GitHub repository where in fact the tool is maintained with documentation describing each one of the subcommand concepts. We welcome any pull requests for enhancements and issues.
When you have feedback concerning this post, submit comments in the Comments section below. When you have questions concerning this post, take up a new thread on the AWS IAM forum or contact AWS Support.
Want more AWS Security how-to content, news, and show announcements? Follow us on Twitter.
You must be logged in to post a comment.