Getting started with AWS Certificate Manager (and Route53)

…with your own domain not hosted in Amazon Route 53 and a wild card certificate.
A main premise I follow when it comes to deploying or architecting any service in the cloud, whatever vendor I use, is full encryption between layers and intent to add elasticity on each service (adding them to what AWS calls Auto Scaling Groups).
For a pretty cool new project (wink wink) that we are working in the Security Operations Group at Alfresco, we need to deploy a bunch of AWS resources and we want to use https between all the services. Since we will use AutoScaling groups and ELB, we want to configure all ELB with HTTPS and to do so we have to provide the certificates. We can do that manually or automated with CloudFormation, and the CloudFormation option is what we have chosen as in many other projects. We also want to use our own certificates.
This article is to show you how to create your own wild card certificate with AWS Certificate Manager and use Route53 for a subdomain that you own. For example, if you have a domain that is not hosted in Route 53, like in my case with which is hosted at using their own name servers. I’ll use a subdomain called for this example.
Long story short, the whole process is something like this:
  1. Add a hosted zone in Route 53
  2. Configure your DNS server to point the custom subdomain to Route 53
  3. Create the wildcard certificate
So let’s go ahead:
  1. Start creating a hosted zone in Route 53. This new hosted zone will be a subdomain of our main domain that we will be able to manage entirely in AWS for our wild card certificates and obviously for our load balancers and URLs domain names instead of using default names, in my case, I create a hosted zone called “”:

  1. Now we have to go to our DNS server and add all records that we got in the previous step, in my case I will do it using web panel, if you use Bind or other solution you have to create a NS zone called (something like that, like a 3rd level domain) and then point the Name servers that we got from AWS Route 53 above. Here an example, easy:

3. Once we have all DNS steps done, let’s create our wild card certificate with AWS Certificate Manager for * Remember that to validate the certificate creation you will get an email from AWS and you will have to approve the request by following the instructions on the email:

This is the email to approve the request:

Here is the approval page:

Once it is approved you will see it as “issued”. And you are ready to use it. Now, from CloudFormation we can call Route 53 and use your own certificate to make all communications through HTTPS when needed.
Hope you get this article helpful. The Trooper is coming!

Bypassing AWS IAM: How important it is to look closely at your policies

If you are dealing everyday with dozens of users in AWS and you like to have (or believe that you have) control over them; that you like to believe that you drive them like a good flock of sheep, you will feel my pain, and I’ll feel yours.

We manage multiple AWS accounts, for many purposes. Some accounts with more restrictions than others, we kinda control and deny to use some regions, some instance types, some services, etc. Just for security and budget control (like you do as well, probably).

That being said, you are now a “ninja” of AWS IAM because you have to add, remove, create, change, test and simulate easy and complex policies pretty much everyday, to make your flock trustfully follow its shepherd.

But dealing with users is great to test the strength of your policies. I have a policy where explicitly denied a list of instance types to be used (a black list with “ec2:RunInstances”). Ok, it denies to create them, but not to stop them, change instance type and start them again. You may end up feeling that your control is like this:

Let me show you all the technical details and a very self-explanatory demo in this video:

What do you think? Is it an expected behavior? It is actually. But I also think that the “ec2:ModifyInstanceAttribute” control should be more granular and should have “instanceType” somehow related to “ec2:RunInstances”. A limitation from AWS IAM, I guess.
In case you want to try by yourself, here you go below all commands I used (you will have to change the instance id, profile and region), if you want to copy a similar IAM policy, look at here in my blog post How to restrict by regions and instance types in AWS with IAM:
# create an allowed instance
aws ec2 run-instances --image-id ami-c58c1dd3 \
--count 1 --instance-type t2.large --key-name sec-poc \
--security-group-ids sg-12b5376a --subnet-id subnet-11fe4e49 \
--profile soleng --region us-east-1

# check status
aws ec2 describe-instances --instance-ids i-0152bc219d24c5f25 \
--query 'Reservations[*].Instances[*].[InstanceType,State]' \
--profile soleng --region us-east-1

# stop instance
aws ec2 stop-instances --instance-ids i-0152bc219d24c5f25 \
--profile soleng --region us-east-1

# check status
aws ec2 describe-instances --instance-ids i-0152bc219d24c5f25 \
--query 'Reservations[*].Instances[*].[InstanceType,State]' \
--profile soleng --region us-east-1

# change instance type
aws ec2 modify-instance-attribute --instance-id i-0152bc219d24c5f25 \
--instance-type "{\"Value\": \"i2.2xlarge\"}" \
--profile soleng --region us-east-1

# start instance type
aws ec2 start-instances --instance-ids i-0152bc219d24c5f25 \
--profile soleng --region us-east-1

# check status
aws ec2 describe-instances --instance-ids i-0152bc219d24c5f25 \
--query 'Reservations[*].Instances[*].[InstanceType,State]' \
--profile soleng --region us-east-1

# terminate instance
aws ec2 terminate-instances --instance-ids i-0152bc219d24c5f25 \
--profile soleng --region us-east-1

Deploy the new Alfresco One Reference Architecture in few minutes with AWS CloudFormation

…On AWS, in High Availability, Auto scalable and Multi AZ support.

Back in 2013 we (at Alfresco) released an AWS CloudFormation template that allow you to deploy an Alfresco Enterprise cluster in Amazon Web Services and I talked about it here.
Today, I’m proud to announce that we have rewritten that template to make it work with our new modern stack and version of Alfresco One (5.1). We also put a lot of effort in place to make this new template an Alfresco One Reference Architecture, not only because it is in hight availability, but because we use our latest automation tools like Chef-Alfresco and our experience on tuning but also best practices learned during our latest benchmarks and related to architecture security. In addition to that and to make it faster to deploy, we are using the official Alfresco One AMI published in the AWS Marketplace.
I’d like to mention some features you will find in this new template:
  • All Alfresco and Index nodes will be placed inside a Virtual Private Cloud (VPC).
  • Each Alfresco and Index nodes will be in a separate Availability Zone (same Region).
  • We use Alfresco One with Alfresco Offices Services and Google Docs plugin.
  • All configuration is done automatically using Chef-Alfresco, you don’t really need to know about Chef to make this work.
  • An Elastic Load Balancer instance with “sticky” sessions based on the Tomcat JSESSIONID.
  • Shared content store is in a S3 bucket.
  • MySQL database on RDS instances in Multi-AZ mode.
  • We use a pre-baked AMI. Our official Alfresco One AMI published in the AWS Marketplace, based on CentOS 7.2 and with an all-in-one configuration that we reconfigure automatically to work for this architecture and save time.
  • Auto-scaling rules that will add extra Alfresco and Index nodes when certain performance thresholds are reached.
  • HTTPS access to Alfresco Share not enabled by default but all set to enable it.
As a result of this deployment you will get this environment:
Our CloudFormation Template and additional documentation is available in Github.
In the video below you can see a quick demo about how to deploy this infrastructure in just few minutes of user intervention. Isn’t is cool? Do you know how much time you save doing it this way? And also set up a production and test environment exactly the same way, faster, easier and cheaper!

Prowler: an AWS CIS Security Benchmark Tool

screenshot-2016-09-14-22-43-39In this blog post I’m happy to announce the recent release of Prowler: an AWS CIS Security Benchmark Tool.

At Alfresco we run several workloads on AWS and, like many others companies, we use multiple AWS accounts depending on use cases, projects, etc.

To make sure we have a foundation security controls applied to each  account, AWS counts with a service called Trusted Advisor which has, among other features, a section for Security Best practices, it checks some services and give us some recommendations to improve Security of our account, 3 checks are free the rest of them (12) are available only for customers with Business or Enterprise support plan:


Trusted Advisor is fine, but it is not enough comprehensive and it is not free. Here is a screenshot of Trusted Advisor in the AWS Console on a Business support plan account:

In addition to that AWS service, few months ago the Center or Internet Security (CIS) along with Amazon Web Services and others, released the CIS AWS Foundations Benchmark. In that document we can find a collection of audit checks and remediations that cover the security foundations for these main areas in AWS:

  • Identity and Access Management (15 checks)
  • Logging (8 checks)
  • Monitoring (16 checks)
  • Networking (4 checks)

The 89 pages guide goes through 43 recommendations by explaining why that check is important, how to audit it and how to remediate it in case you don’t have it properly configured.

If you try to follow all these checks manually it may take you a couple of days to have all of them checked. This is why in Alfresco we decided to write a tool to make it faster, thus I wrote “Prowler”, a command line tool based on AWS-CLI that creates a report in a minute and shows you how is your AWS account configured in terms of security (using fancy color codes).


Prowler, whose name comes from the Iron Maiden song with the same name, works in Linux, OSX and Windows (with Cygwin), with AWS-CLI installed. It also requires an AWS account with at least the SecurityAudit policy applied as specified in the documentation. For more information, details and sample reports visit the project repository in Github here

Please, go ahead, check it out and give me feedback!

Hope it helps!

UPDATE! Right after I published this post, I was pointed in Twitter by @MonkeySecurity about Scout2, which is a tool we use here since long time and it is very helpful. It has many different checks and it is complementary to Prowler, don’t forget to give it a try! And also use SecurityMonkey if you are not doing so already!

UPDATE2! Another tool to perform AWS security checks is the CloudSploit Scans, more info here.



Security Monkey deployment with CloudFormation template

netflix-security-monkey-overview-1-638In order to give back to the Open Source community what we take from it (actually from the Netflix awesome engineers), I wanted to make this work public, a CloudFormation template to easily deploy and configure Security Monkey in AWS. I’m pretty sure it will help many people to get their AWS infrastructure more secure.

Security Monkey is a tool for monitoring and analyzing the security of our Amazon Web Services configurations.

You are maybe thinking on AWS CloudTrail or AWS Trusted Advisor, right? This is what the authors say:
“Security Monkey predates both of these services and meets a bit of each services’ goals while having unique value of its own:
CloudTrail provides verbose data on API calls, but has no sense of state in terms of how a particular configuration item (e.g. security group) has changed over time. Security Monkey provides exactly this capability.
Trusted Advisor has some excellent checks, but it is a paid service and provides no means for the user to add custom security checks. For example, Netflix has a custom check to identify whether a given IAM user matches a Netflix employee user account, something that is impossible to do via Trusted Advisor. Trusted Advisor is also a per-account service, whereas Security Monkey scales to support and monitor an arbitrary number of AWS accounts from a single Security Monkey installation.”

cloud-formationNow, with this provided CloudFormation template you can deploy SecurityMonkey pretty much production ready in a couple of minutes.

For more information, documentation and tests visit my Github project:

How to restrict by regions and instance types in AWS with IAM

The use case is easy, and if you work with AWS I’m pretty sure that you have faced this requirement at some point: I don’t want a certain group of users of a particular AWS account to create anything anywhere. I had to configure the security of one of our AWS accounts to only allow users to work with EC2 and a few other AWS services in only two regions (N. Virginia and Ireland in this case). In addition to that, and to keep our budget under control, we wanted to limit the instance types they can use, in this example we will only allow to use EC2 instances that are not bigger than 16GB of RAM (for a quick view of all available EC2 instances types see

Thanks to the documentation and AWS Support, I came across this solution (as an example). The only issue is that, at the moment, we can not hide features in the AWS Console, but at least AWS Support is very clear and supportive on that. They know how challenging is IAM for certain requirements.

Go to IAM -> Policies -> Create Policy -> Create Your Own Policy and use the next json code or in this gist link  as reference to write your own based on your requirements. After that you have to attach that policy to the role/user/group you want to.

Hope this helps.