You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use Case:
A service to be deployed into an AWS EKS cluster is required to use IRSA and must explicitly define all AWS actions required to be accessed, wildcard actions are not allowed.
What happened:
Disagreement in configuration between prefix and IamRole configuration resulted in service not being able to access AWS resources while the policy was allowed by the iam_manager.
The prefix list configured contained action ec2:Describe (no wildcard), while the role to be generated included action ec2:DescribeTags, the iam_manager policy check allowed the action due to aforementioned prefix. The problem is that the permission boundary generated in AWS only includes the explicit action ec2:Describe, so while the policy check passes during resource resource validation it later fails AWS authorisation as ec2:DescribeTags is not allowed. I did not notice this discrepancy until I ran the AWS policy simulator which resulted in:
Implicitly denied by a Permissions Boundary Policy (no matching statements)
What you expected to happen:
In the example provided for allowed_policies.txt there are action's ending with wildcards i.e. s3:*. This give the impressions naively that while the documentation says prefix its executing a regular expression check during policy checks.
This discrepancy occurs because there are two point of truth the allowed_policies.txt used for the permission boundary (wildcards allowed) and the config map (no wildcards). Would it not be better to validate actions in the same way as AWS using wildcard globbing, to avoid this confusion.
Environment:
iam-manager version: 0.0.7
Kubernetes version : 1.18.9
This is an interesting problem which i have in my mind for a quite a bit of time. I would love to do the same way AWS is validating the policy but i didn't find it anywhere in their repos. If we find it and we can just use import the library and use same functions instead of reinventing the same logic
Use Case:
A service to be deployed into an AWS EKS cluster is required to use IRSA and must explicitly define all AWS actions required to be accessed, wildcard actions are not allowed.
What happened:
Disagreement in configuration between prefix and IamRole configuration resulted in service not being able to access AWS resources while the policy was allowed by the iam_manager.
The prefix list configured contained action ec2:Describe (no wildcard), while the role to be generated included action ec2:DescribeTags, the iam_manager policy check allowed the action due to aforementioned prefix. The problem is that the permission boundary generated in AWS only includes the explicit action ec2:Describe, so while the policy check passes during resource resource validation it later fails AWS authorisation as ec2:DescribeTags is not allowed. I did not notice this discrepancy until I ran the AWS policy simulator which resulted in:
What you expected to happen:
In the example provided for allowed_policies.txt there are action's ending with wildcards i.e.
s3:*
. This give the impressions naively that while the documentation says prefix its executing a regular expression check during policy checks.This discrepancy occurs because there are two point of truth the allowed_policies.txt used for the permission boundary (wildcards allowed) and the config map (no wildcards). Would it not be better to validate actions in the same way as AWS using wildcard globbing, to avoid this confusion.
Environment:
iam-manager version: 0.0.7
Kubernetes version : 1.18.9
Policy Spec
The text was updated successfully, but these errors were encountered: