IAM Permissions

An IAM Principal can have multiple policies attached to it. These policies determine what the principal is authorized to do in your account.

Each policy consists of one or more statements that consist of:

1. An optional statement Identifier (Sid (opens in new tab))
2. Action - a list of things the policy allows or denies
3. Resources - the ARNs of resources the statement applies to
4. Effect - either Allow or Deny
5. Condition - optional conditions that must be satisfied for the policy to grant permission

AWS provides many AWS Managed Policies (opens in new tab) that contain a list of actions that usually map to a specific job function. However, AWS customers can also create custom policies that are more fine-grained. For example, you can craft an IAM policy that only allows someone to read from one specific S3 Bucket or to start or stop, but not terminate, a specific EC2 instance.

Customer policies can be either Customer Managed Policies (opens in new tab) or Inline Policies (opens in new tab) directly attached to a specific principal and cannot be shared. Inline policies are best to ensure a direct relationship between a principal and the policies granted. In contrast, managed policies can reuse the policy across multiple principals.

The most powerful AWS managed policy is the AdministratorAccess policy shown below.

           Patton:~ chris$ aws iam get-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
{
    "Policy": {
        "PolicyName": "AdministratorAccess",
        "PolicyId": "ANPAIWMBCKSKIEE64ZLYK",
        "Arn": "arn:aws:iam::aws:policy/AdministratorAccess",
        "Path": "/",
        "DefaultVersionId": "v1",
        "AttachmentCount": 3,
        "PermissionsBoundaryUsageCount": 0,
        "IsAttachable": true,
        "Description": "Provides full access to AWS services and resources.",
        "CreateDate": "2015-02-06T18:39:46+00:00",
        "UpdateDate": "2015-02-06T18:39:46+00:00",
        "Tags": []
    }
}
Patton:~ chris$ aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --version-id v1
{
    "PolicyVersion": {
        "Document": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Effect": "Allow",
                    "Action": "*",
                    "Resource": "*"
                }
            ]
        },
        "VersionId": "v1",
        "IsDefaultVersion": true,
        "CreateDate": "2015-02-06T18:39:46+00:00"
    }
}

        

Looking at the policy statement, we can see it allows all actions on all resources.

"Statement": [
    {
        "Effect": "Allow",
        "Action": "*",
        "Resource": "*"
    }
]

In the remaining tasks in this room, we will go through all the different elements of an IAM Statement in more depth.

There is another managed policy called ReadOnlyAccess. Using the commands above, go look at the permissions granted to the ReadOnlyAccess user. At the time of this writing, the VersionId was v83. Use the AWS CLI (as shown above) to answer the following question:

Select the Cloud details button at the top of the room:

Where needed generate the environment required for the room. The "Generate Environment" button will appear if the room contains an environment that needs to be generated. 

For any issues with the environment, select the "Reset Environment" button. Review this article for more information.

To view the credentials required for the environment, select the credentials tab. You can use these credentials to access the environment in various ways. More information can be found here:

• ec2:StopInstance
• s3:GetObject
• sts:AssumeRole
• iam:ListUsers

Effect can be either Allow or Deny. With AWS IAM, there is a default implicit deny. All policy statements that match the request's Action, Resource, and Condition are evaluated. If there is any explicit deny, then the action is denied. Otherwise, if there is an explicit allow, the action is allowed. Otherwise, the final decision is to deny the request.

For the following question, look at this policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:Describe*",
                "secretsmanager:ListSecrets",
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": ["*"],
            "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:HR-Passwords*",
            "Effect": "Deny"
        }
    ]
}

Only required for resource policies, not identity-based policies, the Principal Element (opens in new tab) specifies the Principal that is allowed or denied access to a resource. If the principal is "*", the policy applies to anyone or all AWS customers (depending on the Service). We’ll cover resource policies in the next room.

The following resource policy grants public access to read a bucket, and only allows user snape the ability to write to the bucket:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AlowPublicRead",
            "Effect": "Allow",
            "Principal": {
                "AWS": [ "*" ]
            },
            "Action": [
                "s3:GetObject",
            ],
            "Resource": "arn:aws:s3:::dark-arts-class-notes/*"
        },
        {
            "Sid": "AlowPublicRead",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:user/snape"
                ]
            },
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::dark-arts-class-notes/*"
        }     
    ]
}

You can specify any of the following principals in a policy:

• AWS account and root user
• IAM roles
• Role sessions
• IAM users
• Federated user sessions
• AWS services
• All principals

Conditions are optional elements that users can add to a policy. They evaluate against specific keys and values in the context of the request.

The context of the request is specific to the action and resource type. For example, the condition keys available for S3 can be found in the S3 Actions Table (opens in new tab) (scroll to the right on the inner table if you don’t see the condition keys column).

All conditions must be met for the condition block to evaluate true. However, if multiple values for a condition key are provided, the presence of any of those values allows the condition to return true.

Condition statements have special operators (opens in new tab) that are used to evaluate the conditions. Examples are StringEquals, StringNotEquals, StringNotLike, StringLikeIfExists, etc.

There are a number of global condition context keys (opens in new tab) that you can add to your statements based on the attributes of the API call. One of the most common ones is aws:SourceIp - allowing or denying an action based on the IP address it's coming from.

Another popular context key is aws:ResourceTag/tag-key. This condition key can be used to grant or deny access based on the specific tags of the resource. If the statement were:

{
    "Sid": "ManageHouseServer",
    "Effect": "Allow",
    "Action": "ec2:TerminateInstance",
    "Resource": "arn:aws:ec2::123456789012:instance/*",
    "Condition": {
        "StringEquals": {
            "aws:ResourceTag/hogwarts-house": "Hufflepuff"
        }
}

This use of aws:ResourceTag is a fundamental building block of Attribute-Based Access Control (or ABAC).

In the next room, we'll see a global context key, aws:PrincipalOrgID, used to ensure only members of the TryHackMe community are able to invoke a Lambda function.

Given this Statement:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-logs-bucket/AWSLogs/AccountNumber/*",
  "Condition": {
    "StringNotEquals": {
      "aws:SourceVpc": "vpc-abcdef2",
      "aws:PrincipalServiceName": "glue.amazonaws.com"
    }
  }
}

AWS IAM has the concept of NotAction (opens in new tab), NotResource (opens in new tab), and NotPrincipal (opens in new tab). These can be used in more complex cases, but be careful. Doing an allow on all principals except one would allow all AWS customers access to the resource.

You can use NotAction to grant broad access to an account while reserving sensitive actions for special administrators. This is one way to allow someone to administer an account but not modify the network.

NotPrincipal is useful for explicitly denying access to a resource except for a small number of users. For example, this policy will explicitly deny access to the dynamo table ForbiddenForest to all users of account 012345678901 except Hagrid:

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "NotPrincipal": {"AWS": [
            "arn:aws:iam::012345678901:user/Hagrid"
        ]},
        "Action": "dynamodb:PutItem",
        "Resource": [
            "arn:aws:dynamodb:eu-west-2:012345678901:table/ForbiddenForest"
        ]
    }]
}

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {"AWS": [
            "arn:aws:iam::012345678901:user/*"
        ]},
        "Action": "dynamodb:PutItem",
        "NotResource": [
            "arn:aws:dynamodb:eu-west-2:012345678901:table/ForbiddenForest"
        ]
    }]
}