Actions table query reports Conditions incorrectly

[eddydee123]

I installed policy_sentry yesterday with pip.

$ policy_sentry --version
policy_sentry, version 0.13.1

When I query the Conditions table for Actions which support iam:PermissionsBoundary, iam:CreateRole comes up:

$ policy_sentry query action-table -s iam -c iam:PermissionsBoundary
IAM actions under iam service that support the iam:PermissionsBoundary condition only:
iam:AttachRolePolicy
iam:AttachUserPolicy
iam:CreateRole <=======
iam:CreateUser
iam:DeleteRolePermissionsBoundary
iam:DeleteRolePolicy
iam:DeleteUserPermissionsBoundary
iam:DeleteUserPolicy
iam:DetachRolePolicy
iam:DetachUserPolicy
iam:PutRolePermissionsBoundary
iam:PutRolePolicy
iam:PutUserPermissionsBoundary
iam:PutUserPolicy

But when I query the Action table for iam:CreateRole, the condition_keys element does NOT contain iam:PermissionsBoundary:

$ policy_sentry query action-table -s iam -n CreateRole
{
    "iam": [
        {
            "action": "iam:CreateRole",
            "description": "Grants permission to create a new role",
            "access_level": "Permissions management",
            "api_documentation_link": "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html",
            "resource_arn_format": "arn:${Partition}:iam::${Account}:role/${RoleNameWithPath}",
            "condition_keys": [
                "aws:ResourceTag/${TagKey}",  <======
                "iam:ResourceTag/${TagKey}"
            ],
            "dependent_actions": []
        },
        {
            "action": "iam:CreateRole",
            "description": "Grants permission to create a new role",
            "access_level": "Permissions management",
            "api_documentation_link": "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html",
            "resource_arn_format": "*",
            "condition_keys": [
                "aws:ResourceTag/${TagKey}",  <======
                "iam:ResourceTag/${TagKey}"
            ],
            "dependent_actions": []
        }
    ]
}

Maybe this is because the SAR has more than one entry in the resource_types[] array? TBH I'm not even sure how to interpret this phenomenon in the SAR, which shows up as split cells in the table, e.g. iam:CreateRole

Actually, trying other Actions it seems policy_sentry just doesn't report Condtion Keys at all? e.g.

$ policy_sentry query action-table -s lambda -n CreateEventSourceMapping
{
    "lambda": [
        {
            "action": "lambda:CreateEventSourceMapping",
            "description": "Grants permission to create a mapping between an event source and an AWS Lambda function",
            "access_level": "Write",
            "api_documentation_link": "https://docs.aws.amazon.com/lambda/latest/dg/API_CreateEventSourceMapping.html",
            "resource_arn_format": "*",
            "condition_keys": [],  <======
            "dependent_actions": []
        }
    ]
}

compare with https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html#awslambda-CreateEventSourceMapping

[gruebel]

hey @eddydee123 thanks for reaching out.

I checked the code and it doesn't process the * resource case correctly. So what exactly would you expect as a result for CreateRole? I'm not so sure, if the condition keys related to * should be merged with specific resources 🤔

this would be a possible result

$ policy_sentry query action-table -s iam -n CreateRole
{
    "iam": [
        {
            "action": "iam:CreateRole",
            "description": "Grants permission to create a new role",
            "access_level": "Permissions management",
            "api_documentation_link": "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html",
            "resource_arn_format": "arn:${Partition}:iam::${Account}:role/${RoleNameWithPath}",
            "condition_keys": [
                "aws:ResourceTag/${TagKey}",
                "iam:ResourceTag/${TagKey}"
            ],
            "dependent_actions": []
        },
        {
            "action": "iam:CreateRole",
            "description": "Grants permission to create a new role",
            "access_level": "Permissions management",
            "api_documentation_link": "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html",
            "resource_arn_format": "*",
            "condition_keys": [
                "iam:PermissionsBoundary",
                "aws:TagKeys",
                "aws:RequestTag/${TagKey}"
            ],
            "dependent_actions": []
        }
    ]
}

[eddydee123]

@gruebel thanks for the swift response
After looking more deeply, I think this is how the SAR is formatted. In every case where the Action supports both a specific Resource Type and a Condition Key, the cells for Resource and Condition are split. If it only supports one or the other, there is a single unsplit row:

For Actions which support both Resource Types and Condition Keys, you can certainly use both in a single Statement. (I'm not at my machine to verify this, but I've seen it countless times).

So to take the iam:CreateRole example, IMHO the correct behavior is to merge them into a single record:

{
    "iam": [
        {
            "action": "iam:CreateRole",
            "description": "Grants permission to create a new role",
            "access_level": "Permissions management",
            "api_documentation_link": "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html",
            "resource_arn_format": "arn:${Partition}:iam::${Account}:role/${RoleNameWithPath}",
            "condition_keys": [
                "iam:PermissionsBoundary",
                "aws:TagKeys",
                "aws:RequestTag/${TagKey}"
            ],
            "dependent_actions": []
        }
    ]
}

Not sure if that's possible?

If not, your suggestion is also good. Just don't know where the

"condition_keys": [
                "aws:ResourceTag/${TagKey}",
                "iam:ResourceTag/${TagKey}"
            ]

thing comes from?

[gruebel]

For Actions which support both Resource Types and Condition Keys, you can certainly use both in a single Statement. (I'm not at my machine to verify this, but I've seen it countless times).

I know you can. For me it is more important to return a response, which is clear for the user.

If not, your suggestion is also good. Just don't know where the thing comes from?

You can find them in the resourse type table almost at the bottom of the site.

So, if it is merged, then it would be something like this

{
    "iam": [
        {
            "action": "iam:CreateRole",
            "description": "Grants permission to create a new role",
            "access_level": "Permissions management",
            "api_documentation_link": "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html",
            "resource_arn_format": "arn:${Partition}:iam::${Account}:role/${RoleNameWithPath}",
            "condition_keys": [
                "iam:PermissionsBoundary",
                "aws:TagKeys",
                "aws:RequestTag/${TagKey}",
                "iam:ResourceTag/${TagKey}"
            ],
            "dependent_actions": []
        },
        {
            "action": "iam:CreateRole",
            "description": "Grants permission to create a new role",
            "access_level": "Permissions management",
            "api_documentation_link": "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html",
            "resource_arn_format": "*",
            "condition_keys": [
                "iam:PermissionsBoundary",
                "aws:TagKeys",
                "aws:RequestTag/${TagKey}"
            ],
            "dependent_actions": []
        }
    ]
}

I think I should still return the * case, because otherwise I would interpret iam:CreateRole needs to have a resource ARN set.

[eddydee123]

Yes you're right, it should return a separate element for the "Resource" : "*" case.
Thanks for pointing out the Condition Keys associated with the Resource Types - they don't make this easy to follow do they?!

So is this something that could be fixed?

[gruebel]

yeah, no problem to fix it. I just wanted to agree on the returned payload before implementing it 😅