AWS

Amazon AWS Summit Intel

Screen+Shot+2019-05-20+at+2.23.28+pm.jpg

Great to be able to share this from the AWS Summit and Paul Migliorini, Amazon Web Services’s ANZ lead (as reported by CRN, read the whole story here).

When asked whether AWS's largest partners like Accenture, Deloitte and DXC were getting in on the machine learning action as well, Migliorini said global systems integrators are investing heavily in those areas, but are working with consultancies of all sizes.

"You're looking at these organisations with really deep specific capabilities… Kablamo, DiUS, and Intellify, these sorts of companies… they're working with these larger integrators as well in that really cohesive way for customers. And I think that's one really nice thing about the evolution of the way the partner ecosystems are working today."

Miglironi wrapped up with his three key messages for the channel, which included his call for partners to challenge AWS harder.

"The first is that success will come from thinking long term about customer success, which means that putting a focus on outcomes, no matter how small project or revenue is, everyone will be rewarded by customers for the long term. So we want our partners together with us to think long term and to put customer outcomes ahead of any other short term game.

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.


Why I’m joining Kablamo

KABLAMO 0157.jpg

Today, I join a special group of people who are creating a truly amazing company. In a short period of time, Allan Waddell and his team at Kablamo have built a strong reputation in the Australian cloud marketplace – they’re known for delivering high impact customer outcomes, making Agile more than just a buzzword, and for being some of Australia’s smartest cloud and application engineers.

In short, Kablamo is a leader in  a new generation of cloud application partners.

Most enterprise IT service providers say people are their most important asset, but very few practice what they preach. They talk about delivering outcomes for customers but end up only delivering big invoices. They claim to put the customer at the core of their delivery, but don’t take time to really understand their customers’ needs and match these needs with relevant and modern service offerings. In every case, Kablamo is different.

And people are taking notice.

It isn’t often that you get a chance to be a part of the next big thing. I believe Kablamo is that next big thing.  In less than two years, Kablamo already counts some of Australia’s largest organisations as customers. Kablamo’s team are execution engineers, “black ops” code warriors who deliver and educate, working on site with customers and enabling their organisations to move faster via the speed and quality of delivery.  This combination of getting important things done securely and rapidly, whilst investing their customers with lasting cloud knowledge, means  customer teams inherit the capabilities they need to make the most of cloud.  The reputation for delivering, for guiding customers along their cloud journey, is the reason such an impressive list of enterprises already work with Kablamo. 

When I spend time with Kablamo people, I see common traits of humility, accountability, curiosity, creativity and bravery. I see values that align with my own and values upon which we can build a truly world class business.

Today is another step forward in Kablamo’s journey to reshape what customers expect from their technology and cloud partners.  

I am honoured and grateful for the opportunity to partner with Allan, as Co-Chief Executive Officers of Kablamo, and to take this young organisation forward on an exciting mission. I look forward to working with many of the people I have met on my journey so far and I equally look forward to meeting new people and organisations. I have no doubt that today marks the beginning of a fulfilling new chapter in my story, and I look forward to sharing the ride with you all.

-- Angus Dorney, Co-CEO Kablamo

COMMON HURDLES OF DIGITAL TRANSFORMATION IN ENTERPRISE

COMMON HURDLES OF DIGITAL TRANSFORMATION IN ENTERPRISE

Kablamo's Founder and CEO shares his experiences of the common obstacles facing digital transformation within enterprise organisations - and how to overcome these.