Right after that output, we can see something called the Pacu CLI:

What this is showing us is that we are in the Pacu CLI, our active session is named Demo, and we have no active keys. We can add some AWS keys to the Pacu database in a few different ways, such as using the set_keys command, or importing them from the AWS CLI.

We have already set up our AWS keys to work with the AWS CLI, so the simplest approach will be to import them from the AWS CLI. We can import our Test AWS CLI profile by running the following Pacu command:

   import_keys Test 

This command should return the following output:

Imported keys as "imported-Test"

Now if we run the whoami command, we should be able to see that our access key ID and secret access key have been imported, and if we look at the Pacu CLI we can see that now instead of No Keys Set, it says the name of the keys we imported. The location of the Pacu CLI indicates what the active set of credentials are:

Now that we have Pacu set up, we can retrieve the list of current modules by running the ls command from the Pacu CLI. To automate one of the processes that we worked through earlier in this chapter, we are going to use the iam__enum_permissions module. This module will perform the necessary API calls and parsing of the data to gather a confirmed list of permissions for our active set of credentials. This module can also be run against other users or roles in the account, so to get a better understanding of its capabilities, run the following command:

   help iam__enum_permissions 

Now you should be able to see a description of the module and what arguments it supported. To run this module for our own user, we don't need to pass in any arguments, so we can just run the following command to execute the module:

   run iam__enum_permissions 

If the current set of credentials has permission to enumerate their privileges (which they should, because of what we set up earlier in the chapter), the output should indicate that the module successfully gathered the permissions for that user or role:

Now that the permissions for our user have been enumerated, we can view the enumerated data by running the whoami command again. This time, most of the data will be filled in.

The Groups field will contain information on any groups that our user is a part of and the Policies field will contain information on any IAM policies attached to our user. Identifying information such as the UserName, Arn, AccountId, and UserId fields should be filled in as well.

Towards the bottom of the output, we can see the PermissionsConfirmed field, which holds true or false, and it indicates whether we were able to successfully enumerate the permissions we have. The value will be false if we are denied access to some APIs and are not able to gather a complete list of our permissions.

The Permissions field will contain each IAM permission that our user is given, the resources those permissions can be applied to, and the conditions required to use them. Just like the script we wrote earlier in the chapter, this list contains permissions granted by any inline or managed policies attached to our user, as well as any inline or managed policies attached to any groups that our user is a member of.