Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discrepancy between iam.policy.action.prefix.whitelist and AWS permissions boundary #75

Open
Jacob-Morgan opened this issue Mar 10, 2021 · 1 comment

Comments

@Jacob-Morgan
Copy link

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

Policy Spec

---
apiVersion: iammanager.keikoproj.io/v1alpha1
kind: Iamrole
metadata:
  namespace: services
  name: jdv6e5fpi3m7mxpt
  annotations:
    iam.amazonaws.com/irsa-service-account: jdv6e5fpi3m7mxpt
spec:
  PolicyDocument:
    Statement:
      - Effect: "Allow"
        Action:
          - "ec2:DescribeTags"
        Resource:
          - "*"
        Sid: "ReadEc2Tags"
@mnkg561
Copy link
Contributor

mnkg561 commented Jun 8, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants