Related, I've been wondering if there's a tool that will generate a least-privilege policy out of an existing set of AWS CloudTrail records. It would be wonderful if I could run terraform from an admin user, pull down the API calls, and build a policy from them.
It does, but some disclaimers:
1. The generated policies have Resources set to all, not to a specific resource ARN
2. It downloads all of the CloudTrail logs. This takes a while. Cloudtracker (https://github.com/duo-labs/cloudtracker) uses Amazon Athena, which is more efficient. In the future, I'd like to see a combined approach between all three of these tools to generate IAM policies based on Cloudtrail logs.
3. It is accurate to the point where there is a 1-to-1 mapping with the IAM actions vs CloudTrail logs. As I mentioned in other comments, since not every IAM Action is logged in CloudTrail and not every CloudTrail action matches IAM Actions, the results are not always accurate.
With that being said, it is a wicked tool and you should try it out.
Thank you! I'm glad to see there's progress on this. I've been holding off putting the infrastructure automation into CI/CD, due to the incredible amount of work it would take to create a least-access policy. Tooling like this will help a lot.
Sorry for a shameless self-promotion but I've recently written a piece about how it's a common practice to grant web apps a full access to S3 resources using a simple IAM policy and what risks it causes https://pawelurbanek.com/s3-iam-config
> and there's no automated tool that will automagically sense the AWS API calls that you perform and then write them for you in a least-privilege manner.
Aardvark and Repokid revoke privileges based on AWS Access Advisor, which tells you when certain services have not been used within X amount of days/months. But it only does this for services, not for actions. So the resulting API calls are not very granular.
I have a question, I recently had the opportunity to use AWS CDK (https://docs.aws.amazon.com/cdk/latest/guide/home.html) for a project. It seemed to me that CDK automatically does this to a certain degree and if CDK is the future for AWS infrastructure provisioning, this issue should organically go away. Anyone have any input?
I don't know if it's really the future, but at least it's an alternative.
Some people claim it's the wrong way, because it's another abstraction between a CFN-template and the CFN-engine (more moving parts, etc) and using a markup language that restricts you a bit, makes things more manageable.
I haven't used the AWS CDK before. I'm more of a Terraform guy. But at a glance, I don't think it solves the issue with access levels and resource ARNs. You can still create IAM policies that have s3:wildcard, or `service:someaction` against wildcard resources.
Essentially: Even when Infrastructure as Code exists, IAC developers can still make security mistakes. Our goal with this tool was to automate the process (it is way faster to build policies with this), and by default, restrict actions according to resource ARNs. I haven't seen any other tool do that to this degree, although I would be pleasantly surprised to learn about any that do.
Edit: Not sure why HN is blocking out the wildcard character.
It does make it easier to create and change policies, and this increases your development velocity and hence the chance that youll dedicate enough time to security.
Some of the higher level constructs apply smart rules. Eg adding a load balancer target adds restricted access rules.
It's still hard to know what's been created and how everything is connected.
I made a graph visualization tool that live updates from a Cloudformation file. It solved all my visibility and understanding issues. I plan to release it soon.
It's essentially a method for managing their policies as code - but it doesn't make those policies restricted to certain resources, unless you configure it that way. Using `policy_sentry --write-policy --crud`, you have to supply a file with resource ARNs, and it will write the policy for you, rather than supplying a policy file, and hoping the ARNs fit that use case.
At first glance (by the name) I thought this was something that analyzed your AWS usage based on API logs and created an "ideal" policy for to use (or recommend permissions to remove/add).
Regarding your point on the API logs - there are some blunders on AWS's part that make "policy suggestion" difficult. Behind the scenes right now, is still AWS figuring out what IAM privileges actually correlate to what actions. A simple example of this is the privilege s3:listallmybuckets correlates to the action and subsequent CloudTrail event s3:listbuckets. It is insane to think about, but AWS never kept track of those differences.
You also have the problem that not all actions are recorded by CloudTrail (ex. cloudwatch:putmetricdata).
Now, I think that it's possible this tool could be extended to support that. For example... you could use Amazon Athena to query CloudTrail logs from an S3 bucket, and then query the logs to determine which principals touch which ARNs. For each IAM principal, create a list of ARNs. For each ARN, plug that ARN into a policy_sentry yml file, and determine the CRUD level based on a lazy comparison of the action listed in the cloudtrail log vs the reosurce ARN. And then run the policy_sentry yml file to generate an IAM policy that would have worked. But that's just my idea... actual implementation of that would be a bigger effort than what I could take on myself.
If you are interested in that kind of feature, please comment and I'll point this out to some other engineers who will be contributing to this tool as well.
> It is insane to think about, but AWS never kept track of those differences.
Integration with cloudtrail sort of lands on teams, they suddenly get told it's a priority for that quarter, they scramble around like mad, shove a fresh-out-of-college hire on it with little oversight, and you get what you get...
Unfortunately IAM Access Advisor only points to use of services (ex: S3-wide, EC2-wide), not use of IAM Actions. So it's useful, but it has serious limitations. I am hoping that they provide more granular results in the future.
Is there any way to block the creation of policies containing specific permissions or resources? I know this can be trivially circumvented but if this tool is used in ci/cd it can be a good gate.
In the Terraform use case, that is probably possible if you hack together an analysis of the JSON policy files generated by the Terraform module and then allow/warn/deny based on the results. Alternatively, you could run the IAM analysis portion of this tool after Terraform apply.
I should also mention that the IAM authoring aspect of this tool is more mature than the policy analysis feature.
In CI/CD, if you are using Terraform, I suggest using Open Policy Agent for blocking access to certain resources by evaluating a Terraform plan. I suppose it's also possible to use OPA to evaluate the JSON output of a policy_sentry YML file.
I haven't used it in production. It uses an even-more-baroque syntax than terraform's HCL dialect, and using it kind of assumes that all your modifications go through terraform.
Not sure I understand your question fully but if this doesn't support it you can tack on permission boundaries if you wish to apply a permission blacklist to a specific role. If it's account wide you can apply service control policies via AWS organizations.
In a funny not serious but also totally serious way I want to be friends with everyone who cares about the fact that this repo exists regardless of if they think its worth using.
In a funny not serious but also totally serious way: I want to hire everyone who cares about the fact that this repo exists with the know-how to apply it.
