Leverage IAM session policies to extend custodian actions to users safely

[PratMis]

Describe the feature

Some custodian users want the capability to take actions and we want to find out a way that we let us leverage a single IAM role but also control the iam permissions depending on the use case

High-Level Direction

What are Session policies?

Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or a federated user. The permissions for a session are the intersection of the identity-based policies for the IAM entity (user or role) used to create the session and the session policies. Permissions can also come from resource based policies. An explicit DENY in any of these policies overrides the ALLOW. You can create role session and pass session policies programmatically using the AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity API operations. A resource-based policy can specify the ARN of the user or role as a principal. In that case, the permissions from the resource-based policy are added to the role or user's identity-based policy before the session is created. The session policy limits the total permissions granted by the resource-based policy and the identity-based policy. The resulting session's permissions are the intersection of the session policies and the resource-based policies plus the intersection of the session policies and identity-based policies.

Build the concept of leveraging IAM session policies in the Cloud Custodian rule engine in conjunction with the assume role api operation via a flag on the CLI

The flags that are supported in the Cloud Custodian rule engine are as follows:

usage: custodian run [-h] [-r REGION] [--profile PROFILE] [--assume ASSUME_ROLE] [--external-id EXTERNAL_ID] [-p POLICY_FILTERS] [-t RESOURCE_TYPES] [-v] [-q] [-l LOG_GROUP] -s OUTPUT_DIR [-f CACHE] [--cache-period CACHE_PERIOD] [-d] [--skip-validation] [-m [PROVIDER]] [--trace [TRACER]] [configs ...]

This solution would potentially expose a new flag alongside [--assume ASSUME_ROLE]. Something along the lines of [--session-policy file://userA-session-policy.json]

The session policy could be a policy built in AWS or something we would store in any data store like s3 in the form of a json file

This would also grant us the flexibility of keeping different json files aka session policies for each pod depending on their requirement. For example - If userA wants 5 destructive actions and userB only wants 2, we could keep the session policy files separate and use the right json file at the time of assume role when the policy executions are kicked off. No ops overhead on the users expect writing policies

This would also let us leverage the enterprise pattern for all users.

Tenets

Consistency - We measure output success based on the policy execution errors and we also try to be consistent with how we run policies on the platform without our customers having to do anything on their end.

Commonality and safety - We build generic solutions that work for all customers instead of trying to build multiple workflows with regards to each use case.

Extra information or context

No response

[PratMis]

The con of using a session policy would be that it only allows 2048 characters. However, it would be a handy capability for us to open up some actions to our SRE teams wrt clean ups, building trust etc