Saturday, April 16, 2016

AWS Security Group – five basic rules



AWS Security Groups are instance level virtual firewalls. It enables flexible and logical security segmentation well suited for protecting apps in the cloud. While its basic concept is easy to understand, certain specifics can be confusing in practice, and I summarize the top five principles worth revisiting.

1.       Security Group rules aggregate
Security Group can have multiple rules, an instance can also have multiple Security Groups. What happens when multiple rules from one or more SGs are applied to the instance?

If rules have the same egress (towards the same target), ingress are effectively aggregated. If multiple rules are written to the same target, then the most permissive principle is applied. For example, if you have a rule that allows access to TCP port 80 from a subnet and another rule that allows access to TCP port 80 from everywhere, then everyone has access to TCP port 80.


2.       Rules to different targets don't mix
However, rules towards different targets never mix. For example, if an ingress rule allows everyone (0.0.0.0/0) to access ssh; another ingress rule allows from IP 10.1.1.1 to access everything (All Traffic), since the rules are towards different targets, they remain independent of each other. In other words, ingress don't mix if target of rules are different. It is basic but can get confusing when applying complex SGs.

3.       Intra-SG communication not allowed by default (except in default SG)
Initially, you may notice instances can already communicate with each other without you doing anything. Later when you add SGs, it may no longer be the case. When you define a SG and place instances in it. By default, they can't talk to each other unless you add rules allowing it.

The exception is default SG, which all instances are placed into unless specified. By design, instances in default SG can talk to each other without explicit allow. If you look at the system generated default SG, it already specifies itself as a source SG in its inbound rules. This is what allows instances associated with the default SG to communicate with other instances associated with the default SG.

4.       Security Group allows outbound by default
The following are the initial settings for a security group that you create:
  • Allows no inbound traffic
  • Allows all outbound traffic

5.       No need to allow “return” traffic
So you have given your instance outbound access, have you wondered how the return traffic get through even you haven’t defined ingress rules for it? SGs are stateful — responses to allowed inbound traffic are allowed to flow outbound regardless of outbound rules, and vice versa.

Saturday, April 2, 2016

Why is Lambda function not invoked by CloudWatch Events



AWS Lambda has proven to be an increasingly versatile tool for cloud automation. It is pretty easy to get started since there is little dependency involved, and what you can do with it is limited only by imagination. However, I went through some detours with initial troubleshooting efforts, and hope to share some learning experience here.

A common occurrence is that a Lambda function not getting invoked as expected. In this typical push model, a CloudWatch event occurs which should trigger Lambda invocation. But reviewing CloudWatch provides no indication that Lambda left any logs. At this point, the most useful clue is to look at Lambda “Monitoring” tab. Shown below are clear indication that invocation occurred but failed.

So why would a Lambda function fails to get invoked? Lambda permission model is often overlooked. Specifically, Lambda function is associated with an execution role. The execution role must grant the permissions that Lambda function needs. By keeping access and control outside the function, there is clean separation between permission and the code.

For CloudWatch Events to invoke Lambda, Lambda must have authorization. Perhaps not so intuitive, the authorization for Lambda is by ways of function-level permissions. In other words, Lambda execution role needs to have CloudWatch Events permission for it to be invoked by CloudWatch Events.

One way to fix, add “cloudwatcheventsfullaccess” to the execution role assigned to Lambda function. There are obviously other permissions needed depending on your specific Lambda function, these are useful references: