The cloud is becoming increasingly popular. It is the driving force of the modern world, and engineers are starting to shift their careers accordingly. Whatever your profession, chances are you will have to work or interact with the cloud. Terms such as VPCs, subnets, security groups, and ECS will no longer sound unfamiliar. But have we really grasped the gravity of this seismic shift?
Until now, most of us have been most concerned about cost when we thought about "moving to the cloud", with cost savings being the primary motive during the first wave towards adoption. SaaS companies or consultancies that emerged during this first wave were focused towards cost optimization. Tools which identify idle cloud resources, allow scheduled cloud shutdowns, and allow the fetching of a spot instance with the lowest cost are used as examples of potential cost savings. But there is something more fundamental and more important than cost that we need to pay attention to: Security.
Basic Concepts of Cloud Security
Engineers love to solve problems, design solutions and quickly deploy to the cloud for a sense of achievement. Security is often an afterthought. The engineering and developer communities need to better understand a few basic aspects of cloud security to make the journey more fun, secure and navigable.
I personally come from a background where as an engineer I wouldn’t have to bother with security except with ports that we would use for communication among components, or encryption/decryption of application data. Network security, application security, and endpoint security would be taken care of by experts. I would simply write my code, integrate it into a working machine, and be done. Deployment teams would have network engineers, database admin, operations engineers and an army of experts to deploy it. I would offload the application to the deployment teams, but would seldom interact with them when it came to security.
The cloud has changed everything through DevOps. It's a phrase that has been thrown around ever since 2009, when Patrick Debois coined the term to describe the growing movement of software delivery in both small startups and large enterprises. At the time, I didn't understand what he was talking about. Now, it is a part of my daily life.
Why is it so important to me now? Two main reasons: first, cloud is an abstraction which works with programmable APIs. We all use APIs to bake our applications. Second, the abstraction typically wraps all the physical aspects of the hardware and instead gives us software constructs like IAM, Security groups, and Subnets.
Many of us do not realize the implications of these two together. We as engineers are controlling physical aspects indirectly. By virtue of APIs, the speed at which this happens has increased exponentially. Because of this, the work which experts used to do is now our responsibility.
That is what the Shared Responsibility Model is all about. Most of the onus of security is on engineers. Many of you will have encountered a Gartner warning,“Through 2025, 99% of cloud security failures will be the customer’s fault.”
AWS is aggressively expanding its offering. At this moment there are 200+ services offered. EC2, RDS, S3, SQS, and Lambda are used heavily, while some are used marginally. However, there is one service which you have to deal with no matter what, and that is IAM (Identity and Access Management). This service forms the backbone of the AWS cloud as it deals with Identity and Authorization. In essence it is the fabric of AWS cloud. Almost every API call needs to pass through an IAM check, resulting in a massive 400M/sec requests throughput.
Understanding the IAM Model
IAM is about understanding what identities have which accesses and to what degree. Understanding IAM is crucial for any well written application and its secure deployment in the cloud, especially in a serverless world.
Identity could be anything, be it a user who is logged into a console session, an API using an STS token, compute like EC2 or even an abstracted compute such as a lambda function. It is critical to understand that almost anything in the cloud can assume an identity. That means any cloud resource (think of a cloud resource as any entity which can either provide compute, network or storage) can assume an identity which could have wide reaching consequences.
Principals, Actions, Resources, Conditions
In AWS parlance, identities are called ‘Principals’. Principals directly control what actions are allowed, and can be thought of as actors in the cloud. 'Actions' can be anything that can be initiated with an API. Each cloud resource type has its own set of actions that can be carried out. E.g. S3 have actions such as Create/Delete/ListBucket. The action is the second piece of information that forms the IAM model.
IAM also controls which 'Resources' these actions can be performed upon. Allowing actions on the resources would be too straightforward, and that is where conditions come into the picture. 'Conditions' check if any specific conditions are met before that action is allowed. The actions on any resource are always in Deny state to begin with, and that ensures that unless a user explicitly allows an action, that specific action cannot be carried out.
When we put all these four terms together in one diagram the IAM model becomes easier to understand:
Shown in the above diagram, it becomes apparent that the cloud resources can be both Principal as well as Resource. That means in practice a Lambda function can execute another Lambda or any SQS can execute Lambda. The resources can have direct and indirect relationships, some of which will not be obvious. These relationships can form a chain or a graph, and may have disastrous consequences if not understood.
The IAM model helps us to understand this at a conceptual level. The IAM policy is a document which combines these four parts. The policy can be attached to identities such as users, groups, roles or cloud resources, which then acquires the permissions to perform specific actions within the constraints of conditions listed in the IAM policy. IAM Policy is like a key, which can change hands easily. Be careful to whom you hand over keys directly or indirectly.
Types of Policies
Identity based policies
A policy is in effect only when it is attached to an IAM entity (user, group or role). When a policy specifying a Resource is attached to a user, this user is the Principal (Actor) of the action. A simple IAM policy:
"Effect":"Allow", "Action": "s3:ListAllMyBuckets","Resource":"arn:aws:s3:::*"
This policy allows the attached entity to list all S3 buckets in the account. If this policy is attached to lambda through a service role, the lambda would be able to list all S3 buckets, or if policy is attached to EC2, the EC2 would be able to list all S3 buckets.
Resource based Policies
Can there be scenarios with no identity? Absolutely! This is the case for anonymous access, or when an AWS service does not use a service role, such as an API Gateway, or when cross-account access is required as in the case of Lambda.
When there is no identity, identity-based policies can not be used and there comes into play the other variation of IAM Policy — Resource based Policies. Resource based policy is used when you wish to give access of a resource to a Principal (actor). In this policy we specify who has access to the resource and what actions they can perform on the resource. Resource based policies are supported by only a handful of AWS services.
The S3 bucket policy shown below gives anonymous access to the bucket. In this policy there is a new field, Principal, and this particular policy allows anonymous access to the S3 Objects. Thus in resource based policies, resources can control who has access to them*.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": [ "s3:GetObject" ], "Resource": [ "<arn>/*" ] } ] }
Another important class of policy in a resource-based policy is known as 'Trust Policy'. This allows services and identities to assume the role. As an example, a cross-account access role can use a trust policy to allow access from a different account. Many third party SaaS services use these types of policies to access AWS accounts.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<id>:root" }, "Action": "sts:AssumeRole" } ] }
This is the awesome power of IAM policy. It is the reason why you have to be aware of the content of the policy. Any misconfiguration in an IAM Policy can quickly escalate to a security risk.
IAM Best Practices
Let's take a look at a few interesting observations regarding IAM policies and best practices for managing them.
Least Privilege (grant least privilege)
Each IAM should have the permissions which are required for the task at the hand, and nothing more. While most of the time, we begin by following this principle, over time temptation to reuse these IAM policies is hard to resist. It leads to fat IAM policies which also become vulnerable.
One IAM Policy per Task
As a rule, there should be one IAM policy per task. Resist the temptation to reuse policies. The caveat is, when following the "one IAM Policy per task" rule, it can quickly lead to many IAM policies within the cloud environment. In order to track and know which IAM policy is mapped to what cloud resource, or if any IAM policy is mapped to multiple cloud resources, it quickly goes beyond manual tracking and must be maintained through automation and tooling.
IAM Policy Tracking
What is needed is a tool which analyzes the IAM policies and the cloud resources, and displays a map which visualizes these relationships. There are a few open source and free tools in this area to identify and visualize the IAM relationships:
Attribute Based Access Control
A problem with the least privilege principle is how to write a limiting access policy. It is hard to consistently write such policies at scale. For each policy you need to consult AWS documentation for actions specific to the cloud resource. Going through AWS documentation by referring to allowed actions quickly becomes cumbersome. An alternative is to use "Attribute Based Access Control" policies.
Alternatively you can use iamlive , which generates the IAM policy using client side monitoring. (You may need to put some effort to make it truly least privileges.)
Cross-Account IAM roles: A Warning
Be aware of cross-account IAM roles. These roles open a door to even the most secure cloud environment. It is particularly dangerous when access is given to unknown accounts.
Unfortunately this is no easy task without help of any external tool. AWS has AWS Access Analyzer for this purpose, as does JupiterOne. It helps to have a graph-based visualization of the cross-account roles, and to confirm only legitimate AWS accounts are accessing the environment.
Tools and Resources
- github.com/Netflix/repokid — This tool can help to remove access to unused services. This comes from Netflix and that means it is battle tested tool. This tool uses another Netflix tool which need to be deployed and in that sense, it is little cumbersome to deploy and use. Read this excellent post for details.
- github.com/flosell/trailscraper — a downside of this tool is false positives. Since it is a heuristic based tool which attempts to map the CloudTrail events to IAM actions sometimes it generates false positives
- github.com/duo-labs/cloudtracker — this tool uses Athena for queries and may cost you some $$$.
- github.com/salesforce/policy_sentry — this tool was recently released and can be used to write least privilege policies.
- JupiterOne - offers a free, lifetime license to allow you to explore your AWS environments for cross-account policies through expandable/contractable graphs
Take Aways
- As engineers we need to understand the IAM model and master the art of writing secure IAM policies.
- Cloud resources can have direct and indirect relationships and thus the IAM can have long reaching consequences.
- Visualizing these complex relationship is important.
- Writing IAM policies which adhere to best practices is a daunting task. Automation and tools can make life easier.
