ACM.36: Tools and techniques to create zero trust resource, IAM, and Trust policies on AWS (Zero Trust Policies ~ Part 1)
This is a continuation of my series on Automating Cybersecurity Metrics.
In the last post we created a IAM role policy with permissions that were much too broad. Now we want to restrict the IAM role policy to only what the role requires to perform the actions the role just did when we created our new Access Key.
As a reminder the role policy is found in this file in the GitHub repo:
/jobs/iam/DeployBatchJobCredentials/cfn/policy_batch_job.yaml
It looks like this with very broad access and no resource restrictions:
In order to see what actions the role took and create a policy we have a few options, some of which don’t currently work for all use cases.
- AWS Access Advisor — which should give us a list of actions the user took in CoudTrail logs.
- AWS Access Advisor Policy Generator — which should use the above information to generate a policy.
- CloudTrail Logs — when all else fails, we should be able to query CloudTrail logs to see what actions the user took.
- Trial and Error — Give the user or role no permissions and then try to take the actions you want to perform. Fix each error message by adding permissions as it occurs. Unfortunately, if you get error message that don’t tell you what service or resource the user couldn’t access, this will be difficult.
IAM Access Analyzer
This is interesting. I wrote about IAM Access Analyzer in a separate blog post (not part of this series) and it looks like we have a new message on the screen now that explains that this feature only works with certain AWS services.
Although the message on the screen says otherwise, access analyzer lists all the services our role used. However, it only shows the actions for the services listed: EC2, IAM, Lambda, and S3. So of the services used we can only get the specific actions taken for IAM. Let’s look at what it provides for IAM.
Click the link for IAM. Here we can see the IAM actions the role took.
Only two actions in the above list were used by our role to create the credentials. We can replace iam.* with only those two actions. Now our policy looks like this:
Warning on granting full administrative permissions:If you see iam.* in a policy that is similar to domain admin in a Windows Active Directory environment. Understand who has these permissions and why. Limit their use if possible to only activated when needed, requiring MFA, or other restrictions to limit their potential abuse. What I'm showing you here is a better alternative. Create jobs for specific actions and use those jobs with specific roles and policies instead of giving full IAM access.Also, just because a user has to "switch" to an IAM role doesn't mean much. If an attacker has access to their active session or user credentials, they too can "switch" to the IAM role. This is why, although SSO is handy, it is also risky when you give a user access to a lot of powerful roles across the enterprise.An Azure you can use a feature called Just-In-Time access which you can set up to require a second party to authorize permissions before performing some administrative actions. You can do the same thing on AWS, you just need to create that functionality yourself. I hope that functionality comes to AWS someday:
https://docs.microsoft.com/en-us/azure/defender-for-cloud/just-in-time-access-overview?tabs=defender-for-container-arch-aksIn fact, I wrote a blog post about the concept for AWS before the Azure feature was available with an IOT button to allow access to connect to a VPN. Same concept, different application.
https://aws.amazon.com/blogs/aws/just-in-time-vpn-access-with-an-aws-iot-button/
When I tested earlier it did not appear that IAM Access Analyzer showed cross-account actions. I need to further explore this concept now that it is clear that this feature only works for certain services because I believe I was testing KMS at the time. In fact, I could not find the cross-account logs at all. This page states that actions should be present in both accounts. We’ll revisit that if I get back around to setting up cross-account KMS key management.
What would be great is if this IAM policy generator UI would allow you to select a user or role and then it would only include the actions taken by that user or role, and any resources it accessed. Then it would let you select from that subset as it does below to include which items you want in your policy. Then it would output a policy **in either JSON or YAML** (there should be an easy conversion library to do that) which you could use in a CloudFormation template.
SSO (I know it has a new name, but it’s still SSO) seems to be off on it’s own island and lacking some of the functionality in this post — and all my posts really. I hope these useful features are not lost in the push for integration.
Access Advisor Policy Generator
As of yet, I have not been able to get the IAM Access Advisor Policy Generator to work. It seems to me that is possibly related to the above issue where IAM Access Advisor does not show you all the actions taken by an IAM role. I presume I was using services that the policy generator did not support but the error message after it ran did not tell me that.
However, if you are only using the services shown on the above screen shot, this may work for you.
Click on any user or role and scroll to the bottom of the page. Click the Generate policy button and follow the instructions on the screen.
This is a really great feature. However I’d like to be able to choose which of the actions a user took that I want to include in my policy when generated, as well as detailed resources I want to allow the user to access. It also needs to work with cross-account roles.
CloudTrail
One way to a zero-trust policy we’re going to review actions taken in CloudTrail logs with AWS Athena. In order to make sure you can use Athena at the end of this post, make sure you have CloudTrail enabled with an S3 bucket. If you don’t have a trail or a bucket follow this tutorial to set that up:
CloudTrail logs may take 5 minutes or so to appear, depending on how you have it configured. You can find the details of the timing of log entries in the CloudTrail documentation.
Let’s check CloudTrail for the actions take by our role. Copy the name of the role.
Navigate to CloudTrail. Click View Full Event History at the bottom of the history list. Click Create Athena Table.
Choose the bucket that contains your CloudTrail logs.
Click Create Table.
Click the link at the top to go to the Athena table.
Here’s where I hit an error and stopped for a while. I submitted the request to Amazon via the #awswishlist to help resolve this issue.
I ended up getting covid in between and hadn’t heard back so I went ahead and took another crack at solving this problem but hit the following road blocks:
I’ve used Athena in the past and it was part of my cloud security class. But at this point, I’ve spent so much time on this and I’m not trying to write a blog post on any of that I’m just trying to query cloud trail to fix my policy. This post is already quite long so I’ll continue it in the next where I try out CloudTrailLake instead.
Follow for updates.
Teri Radichel
If you liked this story please clap and follow:
Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2022
All the posts in this series:
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
