aws developer tool

Effective AWS IAM

Screen Shot 2018-08-26 at 9.16.25 pm.png

Know, Don't Slow, Your Users

Ian Mckay, DevOps Engineer for Kablamo, weighs in on the effective use of AWS IAM:

When creating a secure environment in AWS, IAM is a critical part of the security provided in the solution. It's used for controlling how users compute resources and other services interact with each other, however it can also be the critical hole if you don't properly secure your policies.

For users (and sometimes administrators), security is hard. It can slow you down with authentication and provide roadblocks when you are denied access to the resources you need. Many customer environments have experienced this and create dangerous holes for users. This can be an overzealous firewall rule, a shared credential or excessive privileges to perform the actions they need to do. It's worth considering what the risks are when a business creates these shortcuts, as more and more companies are having big public security failures that crush reputations.

How IAM policies are evaluated

For developers that are new to working with IAM, the logic can be confusing at first, especially since the Amazon documentation is massive.

Here's how I explain to others how IAM policy rules are applied:

1.  If a permission isn't mentioned, it's not given

2.  If a permission is given, that action is allowed UNLESS any other policy explicitly denies that permission.

With the way rules are evaluated, the order of how the rules are applied does not matter.

Open IAM Roles

Let's look at an Amazon-provided role, ReadOnlyAccess.

This role gives the ability for a user to have read-only access to all resources within an AWS account, which is a privilege often given to users in order for them to view the resources within an AWS account. Though they have no access to perform any modifications directly, the scope of this role can unintentionally reveal information (unless explicitly denied elsewhere).

For example, this role grants permission to download all objects in every bucket in the account. Often, S3 objects may contain configuration information or even credentials that the developer may have thought secure. The role can also allow users to intercept SQS messages, get EC2 console output or get items from Kinesis or DynamoDB.

If you're looking for a role which further restricts users' access to the above resource, the ViewOnlyAccess role can alternatively be used, though you may find this to be too restrictive in some environments.

Conditional IAM Policies

One of the more powerful features of IAM policies is its ability to conditionally provide access to resources. This can help teams seperate themselves from other workloads or prevent unwanted actions. Here are some examples:

Tag-based access

The below policy grants access to perform all actions, so long as it has the "Department" tag set to "Finance". This is an easy way to segregate different parts of the business within the same account. Remember, not all services support tagging and account-wide limits still apply to everyone.

{
    "Version": "2012-10-17",
    "Statement": [ {
        "Effect": "Allow",
        "Action": [
            "*"
        ],
        "Resource": "*",
        "Condition": {
            "StringEquals": {
                "aws:RequestTag/Department": "Finance"
            }
        }
    } ]
}

TIMEFRAME RESTRICTION

The below policy grants access to perform all actions only within the timeframe shown. This is useful when users are only permitted to have access during certain periods, such as contractors.

{
    "Version": "2012-10-17",
    "Statement": [ {
        "Effect": "Allow",
        "Action": [
            "*"
        ],
        "Resource": "*",
        "Condition": {
            "DateGreaterThan": {"aws:CurrentTime": "2018-01-01T00:00:00Z"},
            "DateLessThan": {"aws:CurrentTime": "2018-02-31T23:59:59Z"}
        }
    } ]
}

IP-BASED RESTRICTION

The below policy grants access to perform all actions only when the request is made from the IP addresses specified. This can help restrict calls to only occur from within a corporate network, as an extra layer of security. Note that calls made by AWS services, such as CloudFormation when it creates resources, cannot be restricted in this way - however the call to create the stack could be.

{
    "Version": "2012-10-17",
    "Statement": [ {
        "Effect": "Allow",
        "Action": [
            "*"
        ],
        "Resource": "*",
        "Condition": {
            "IpAddress": {
                "aws:SourceIp": [
                    "1.2.3.4/24"
                ]
            }
        }
    } ]
}

Using Permission Boundaries

As of July 2018, IAM permission boundaries may be used to restrict the maximum permissions a user (or in some cases, a resource) can be assigned. If a permission boundary is set on an IAM user, the effective permissions that user has will always be the intersection of the permission boundary and their IAM policies. Here's an example of how this works in practice:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "SimpleUserPermissions",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": "*"
        }
    ]
}

The above policy is a simple example of what permissions a user might have. In this case, users can only perform S3 actions. Let's say this policy was created with the name SimpleUserPolicy. Within this account, there is a person assigned to administer the creation of users. The policy assigned to their IAM user is as follows:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "SimpleUserPermissions",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "CreateorChangeUser",
            "Effect": "Allow",
            "Action": [
                "iam:CreateUser",
                "iam:DeleteUserPolicy",
                "iam:AttachUserPolicy",
                "iam:DetachUserPolicy",
                "iam:PutUserPermissionsBoundary"
            ],
            "Resource": "*",
            "Condition": {"StringEquals": 
                {"iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/SimpleUserPolicy"}
            }
        },
        {
            "Sid": "IAMPermissions",
            "Effect": "Allow",
            "Action": [
                "iam:Get*",
                "iam:List*",
                "iam:Simulate*",
                "iam:DeleteUser",
                "iam:UpdateUser",
                "iam:CreateAccessKey",
                "iam:CreateLoginProfile"
            ],
            "Resource": "*"
        }
    ]
}

This policy grants the IAM user the same permissions as the other users (with the SimpleUserPermissions statement) as well as the ability to browse through and update user details with the IAMPermissions statement. Also granted, is the ability to create users or change their assigned policies with the CreateorChangeUser statement. Crucially, this statement has a condition that applies a permission boundary on the create/update process. The created user must be assigned the SimpleUserPolicy permission boundary or the create user call will fail.

With this, we can ensure that the created users permissions will never be escalated past the permission boundary set by the IAM user administrator.

Summary

IAM Roles and Policies are an important piece of every AWS environments security and when done correctly, can be a very powerful tool. However, these policies can very easily get out of control and can have unexpected consequences. If you are having trouble managing IAM, get in touch with us to find out how we can help you master your AWS environment security.


Introducing Kombustion: Our Open Source AWS Developer Tool

Screen Shot 2018-08-15 at 3.14.22 pm.png

The team is proud to announce the launch of Kombustion.  Here's the media release, want to give Kombustion a try?  Visit: www.kombustion.io

Australia, August 15, 2018 – Kablamo has released its most significant open source software project to date, Kombustion. The AWS plugin provides an additional layer of intelligence for AWS CloudFormation, reducing the time and complexity of managing thousands of lines of code across AWS environments of any size. 

The tool provides benefits for developers and engineers who use AWS, as tasks that previously took days or weeks can now be completed in minutes or a few hours.  For example, setting up a new Virtual Private Cloud in an AWS cloud account has typically required significant work to define and manage up to 30 different AWS resources. With Kombustion, a best practice AWS Virtual Private Cloud can be set up with a small amount of configuration to an existing plugin.

“We developed Kombustion to help solve a common challenge for all AWS CloudFormation users. It was built in-house, and we’d been using it ourselves, but after seeing the benefits Kombustion delivered to our team, we decided to open source the project and share it with everyone,” said Allan Waddell, Founder and Co-CEO of Kablamo. “Our Kablamo values align strongly with the open source software community and we are proud to play our part in making AWS an even better experience for its users.”

CloudFormation is a native AWS service, which provides the ability to manage infrastructure as code. Kombustion is a CloudFormation pre-processor, which enables AWS users to codify and re-use best practices, while maintaining backwards compatibility with CloudFormation itself.

Kombustion is especially useful where multiple CloudFormation templates are required. It enables developers, DevOps engineers and IT operations teams to reduce rework and improve reusability in the management of CloudFormation templates, whilst also enabling access to best practices via freely available Kombustion plugins.

Liam Dixon, Kablamo Cloud Lead and Kombustion contributor, said while the core functionality has been built, it was essentially a foundation and he hoped the wider AWS community would help make the tool even better.

“Different AWS users have different ways of pre-processing CloudFormation templates, but we saw the opportunity to develop a freely available tool with the potential to become widely used in Australia and overseas,” Dixon said. “Kombustion’s publicly available, plugin-based approach, means that the AWS developer community can reduce rework and share best practices in areas such as security, network design and deploying serverless architectures.”

As well as reducing the time and complexity of managing multiple AWS instances, other Kombustion benefits include:

  • Adoption can be incremental so there is no need to completely rewrite current CloudFormation templates;
  • Kombustion plugins can be installed from a Github repository;
  • Cross-platform functionality means Kombustion works on Linux, FreeBSD and MacOS; and,
  • Kombustion is completely free to use, for both personal and commercial use   

The first release of Kombustion is available for download today at: www.kombustion.io  Kablamo is calling for the AWS community to test and provide feedback on Kombustion, and to contribute towards future iterations of the project.