Action, Resource, Condition Keys for AWS Services
AWS Services table work with IAM
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html
Policy JSON
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html
Grammar: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_grammar.html
Elements: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html
Policy Simulator
https://policysim.aws.amazon.com/home/index.jsp?#
Root user - first user account with complete access, only recommended to use to create the first user.
Features: grant granular permissions, provide credentials for applications on EC2 instances, MFA, ID federation to allow temporary access to user identified by internet id provider (corporate network, cognito), log in CloudTrail, PCI DSS credit card data compliance, eventually consistency, free to use
Type of access:
How it works
Principal who makes a request for action (users, roles, federated users, applications) (reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)
Specifying a principal in AWS policy document:
Account Root - don't use for everyday, has complete access to account
IAM users - within the account, can be created access key, can be application (in addition to person) but for application running on EC2 best to use role; can be attached policies (managed and inline)
Federated users - SAML2.0, ID broker, AWS Directory Service, Internet ID (Cognito, Amazon, Google, Facebook), has no permanent ID, can assume Role & Role be granted permission
IAM Roles - similar to user in that permission policies can be attached, but has no credentials, not for person/entity to identify, but for federated users or applications to ASSUME (after they have identified) and obtain temporary credential (is both Principal, i.e. ID based policies can be attached, and Resource, i.e. resource based policy - role trust policy - be attached, to specify who can assume this role)
IAM Groups - group of IAM users, but not a 'true ID' since it's not a Principal; cannot be nested; can be specified permission; can be attached policies (managed policies, i.e. can be attached to multiple principals & inline policies, i.e. just for the group; policy contain no principal - it's implied)
Temporary credentials - primarily used with roles, expire after period of time
AWS Organization - Makes cross-account easy
Permission Policies
Types (most->least frequently used):
Attach to principal (IAM user, group, role), specify what the principal can do
{
"Version": "2012-10-17",
"Statement": [ {
"Effect": "Allow",
"Action": [
"iam:GenerateCredentialReport",
"iam:Get*",
"iam:List*"
],
"Resource": "*"
} ]
}
(only some resources use resource based policies, most common: S3 bucket policies & IAM role trust policies; also SNS topic, SQS queue, etc.)
Temporary, short term credential (no need to store, rotate), based on role or federation. The credential & token works globally by default (but can be optimized for & restricted to region). Can also access through VPC (avoid through public network)
Federation:
Obtain:
Usage:
Control permission to use STS operations (AssumeRole etc.) to control who can obtain the credential, for how long etc.
See reference https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_grammar.html
Note: variables from request context (such as ${aws:username}) can be used in the document, for example user id string used in resource path etc.
Can use "*" to match more than one actions
"Action": [
"iam:GenerateCredentialReport",
"iam:Get*",
"iam:List*"
],
The values that can be substituted for policy variables must come from the current request context.
Variables about principals (including tags): https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html
Global condition keys https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html
IAM condition keys https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html
Condition Operators: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"access-project",
"access-team",
"cost-center",
"Name",
"OwnedBy"
]
},
"StringEqualsIfExists": {
"aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
Session Tags: Session tags are key-value pair attributes that you pass when you assume an IAM role or federate a user in AWS STS;
When you use temporary credentials to make a request, your principal might include a set of tags. These tags come from: Session Tags, incoming transitive session tags, IAM tags.
Take home - many information can be looked up
See more https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html
Assumption scenario:
Step 1 - Create role in Production (trusting) account
Step 2 - Grant / deny user in Development (trusted) account privilege to assume role
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateApp"
}
}
Step 3 - Switch roles
aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateApp" --role-session-name "David-ProdUpdate"