Not the hero we want, but the hero we need
TL;DR; You can use the Policy Simulator of AWS to test your IAM policies. This allows you to quickly find the correct access rights and to debug problems with your policies.
Recently I started experimenting with AWS. Following the least privilege principle, I created a separate development account for my experiments. Right at the beginning I ran into a brick wall – AccessDenied! I know I am doing something wrong, but what exactly? This is where the AWS IAM Policy Simulator saved my day.
Let me first express my frustration with AWS IAM. It could be that I am naïve and that the problem with access management is really complex. Or it could be, that AWS built an overly complex solution and is now stuck with it. In both cases there is no excuse for an official AWS tutorial about Elastic Kubernetes Service starting with the prerequisite that you grant yourself full access admin privileges. I decided to do it the right way und create a separate account with the least privileges it needs to work with EKS.
Instead of using the AWS CLI, I took eksctl. This is a third-party tool, but even AWS has officially accepted it for managing EKS clusters. Fortunately, eksctl has a list with the necessary policies. However, my fortune did not last long, because the first call with eksctl returned AccessDenied! Now what?
Per default AWS is blocking all calls, which are not explicitly allowed. This leaves me with two options. Either I do not have sufficient rights to access EKS or some other policy I have defined is explicitly blocking my access.
What I find frustrating here is the lack of information. The “explicit deny” in the error message does not help me to narrow it down. I tried to find more information in CloudTrail, but for some reason even my admin account, could not access the service. One of those days…
This is where the IAM Policy Simulator helped me to bring some light in the dark world of AWS policies. Maybe I am new to AWS, but I don't understand why the simulator is not more visible. There is just one button on the Permissions page of a group. Otherwise you have to know it exists, in order to find it. Beware you may need some addition rights to access the simulator.
When you open the simulator, you can choose the user and what calls you want to simulate with this account. Don't worry about using a delete command for example. No real calls will be sent to your AWS account.
One of the reasons I love the simulator is that it doesn't just show “allowed” or “denied”. When my simulated call was denied, the exact part of the policy blocking my call was highlighted.
And suddenly everything made sense. In my attempts to secure the AWS account, I created a new policy. This policy allows non-admin users to manage their own credentials, like access keys, etc. But you can do this only after you have logged in with multi-factor authentication. Without MFA you are more or less only allowed the manage the MFA devices.
What I overlooked was that sending CLI commands does not use MFA. I have added the correct access rights according to the eksctl documentation. However, my earlier experiments with MFA were the reason I was being blocked now. Because I have added the MFA constraint some time ago, I completely forgot about it.
Removing the DenyAllExceptListedIfNoMFA block proved to be a quick fix in this case. I don't have bad feelings about this. I made a habit of always changing the generated passwords and creating a virtual MFA device with every new account. My team is small enough, that we don't need such rigid control with explicit deny policies.
In retrospective I should have found the problem even without the simulator. However, AWS IAM is not exactly easy to work with. I want a simple solution to manage identity and access. However, until we get this simple solution, I`ll need all the help I can get. AWS IAM Policy Simulator – not the solution we want, but the help we currently need.
Top comments (0)