Elastic Security

Icon

Security for the Cloud

Read-Only Credentials For EC2

A common concern of EC2 users with regard to using third-party tools like Elastic Detector is the fact that those tools require the users’ AWS EC2 credentials to work. In the wrong hands, those credentials can be misused to cause significant damage by e.g. shutting down instances. Fortunately, AWS provides a solution called Identity and Access Management (IAM).

In this blog-post, we want to give you a step-by-step hands-on description how to use IAM to generate “Read-Only” credentials for EC2, i.e. credentials that allow third-party providers to call only those API methods that retrieve information, and prevent API calls that modify something. With the help of the IAM command line tools it is possible to define groups of users and associate a certain policy to them, which defines which API calls are allowed under which conditions.

1. Install IAM Client Tools
First of all, you need to download the IAM command line tools from Amazon and deploy them on your machine.

Therefore, go to http://aws.amazon.com/developertools/4143 and click the download button.

Unzip the downloaded file. Detailed Installation Instructions can be found in the README file.

Basically, the EC2 Credentials (the “root” credentials) must be written into a specific file, the environment variables $AWS_IAM_HOME$ (path to IAM directory created during unzip) and $AWS_CREDENTIAL_FILE$ (path to credentials file) must be set, and the tools included into the environment path (variable $PATH$).

Make a test if the tools are correctly installed by typing:

iam-userlistbypath -h

The tool should respond by showing you all options of that command.

2. Create A Group
Create a group ExternalProviders.

iam-groupcreate -g ExternalProviders

Check that the group was successfully created.

iam-grouplistbypath

You should see something like

arn:aws:iam::123456789012:group/ExternalProviders

3. Create A User
Create a user named Secludit for the group ExternalProviders.

iam-usercreate -g ExternalProviders -u Secludit -k

Store the credentials that are displayed. Those are your read-only credentials.
Check if the user was created and linked to the group

iam-userlistgroups -u Secludit

You should see something like

arn:aws:iam::123456789012:group/ExternalProviders

4. Add The Read-Only Policy
The following command adds a policy named ReadOnly to the group ExternalProviders.

iam-groupaddpolicy -g ExternalProviders
-p ReadOnly -e Allow
-a cloudwatch:GetMetricStatistics
-a cloudwatch:ListMetrics
-a ec2:Describe* -r '*'

The option -a specifies which API calls are allowed. Our specification tells IAM that all calls of the EC2 API are allowed that start with ‘Describe’ (e.g. DescribeInstances, DescribeSecurityGroups, DescribeSnapshots, etc) and to use the CloudWatch API to retrieve statistics.

Now execute the following command to be sure that everything worked fine.

iam-grouplistpolicies -p ReadOnly -g ExternalProviders -v

You should see

{“Version”:”2008-10-17″,”Statement”:
[{"Effect":"Allow",
"Action":["ec2:Describe*",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"],
“Resource”:["*"]}]}

5. Revoke The Credentials
Last, but not least – here is how to revoke the credentials. You do not need to remove them from the third party provider tools you use, you can do simply the following do invalid them:

iam-groupdelpolicy -g ExternalProviders -p ReadOnly

This removes the policy and thus revokes any access rights for all users of the group ExternalProviders.

Note: for most EC2 management consoles (that e.g. allow to launch or stop machines), read-only credentials are not enough. Consult your third-party provider to know exactly which API calls need to be enabled. You can do a lot more and finer-grained restrictions with IAM than shown in this post, e.g. restrict access to certain IP addresses or specific resources. Don’t hesitate to contact us for questions on that topic.

Filed under: AWS, Solutions, ,

Cloud Predictions for 2011

The end of the year is the time for predictions (by the way, does anybody have a look at the predictions from last year?). A quite complete and profound list of predictions was published by Forbes’ CIO Central blog. Instead having a look into my own crystal ball, some remarks and questions from my side on those predictions that refer to general trends in the cloud market and the cloud infrastructure part:

Replace most new procurement with cloud strategies: CFOs will sing the praise of cloud IT? Why didn’t they do this already in 2010 – what has changed in the meantime? The blog cites preferences in deployment solutions and lack of innovative on-premises options – which are a bit weak arguments unless major infrastructure investments are necessary and planned for 2011.

Start with private clouds as a stepping stone to public clouds: private clouds are not a stepping stone for public clouds, but rather a different choice in my opinion. Why would anybody make this huge investment in creating a private cloud when he is willing to switch to a public cloud short time later? Building a private cloud also requires new hardware (since transforming an existing machine park is hardly possible without deconnecting machines temporarily). However, I could very well imagine hybrid scenarios as stepping stone: think of companies like CloudSwitch, Amazon’s VPC, and the recently announced feature of importing VMWare images into EC2 – and you can see that the efforts of playing around with hybrid clouds have become rather small. Certain usecases – like handling temporary peak demand – will also drive hybrid clouds.

Get real about security: for the majority of the early adopters of cloud computing, security concerns were less important than the benefits (OPEX instead CAPEX, scaling, pay-per-use). I expect the next wave of adopters to be more fastidious when it comes to security. That’s by the way is the reason why we believe in software like Elastic Detector that automates monitoring and security for cloud infrastructures.

Move to private clouds as a back up to public clouds: replace “private” by “hybrid” and I agree. Data integration and security are the key competencies needed for migrating (part of) the internal infrastructure of an enterprise to the cloud.

Begin the transition from best of breed purpose built solutions to cloud mega stacks: it seems very clear to me that once enterprises go for SaaS solutions, they also need the customization facilities provided by PaaS platforms. Salesforce with force.com and it’s acquisition of Heroku point clearly into this direction.

Leverage apps market places and ecosystems for the last mile: this prediction is a logical evolution from the need of customization. I fully agree.

Superior user experience and scale won’t be mutually exclusive: while ease-of-use and scale are not mutually exclusive, this is very well the case for ease-of-use and the need for customization and integration. The ease-of-use of SaaS solutions is to a large degree due to its restriction to a minimum and the concentration of specific usecases.

Shift all new custom app development to the cloud: yes, the development and deployment of new projects are a major driver of cloud computing solutions.

Expect DaaS and PaaS to merge in 2011: yes, customization requires both data related and programming logic related facilities. Merging them in a common platform makes perfectly sense.

Demand better virtualization: virtualization will evolve, tools will be more powerful, virtualization technology more efficient. However, this is a process that is ongoing since several years now and I don’t see an important acceleration here. Even more important I consider standardization and compatibility between different virtualization technologies that I guess will play a much more important role in the next couple of months.

Simplify the overall technology landscape: I rather expect that different technologies – cloud and non-cloud technology – will co-exist during a transition phase that may take quite some time. Thus, I rather expect a more heterogeneous and thus also more complicated technology landscape in large organizations. Things are surely different for small organizations that are willing to adopt the public cloud and thus restructure their IT from scratch.

Conclusions: Cloud Computing is no longer a question of “if” or “when”, but a question of “how”. Companies are convinced about the financial benefits of cloud computing. I thus expect them to push for interoperability, standardization, customization, and integration. They will also ask for security, management, and monitoring solutions that deal with the elastic character of cloud computing. When SaaS providers offer more and more customization facilities – and IaaS providers more and more additional services on top of their basic infrastructure offer, they both seem to merge into something that resembles PaaS. If you look for a bottom-line for he predictions, here it is: 2011 could be the year of PaaS.

Filed under: Discussions, ,

Cloud Acquisitions 2010: Go PaaS?

Let’s have a look at the major acquisitions in the cloud computing space in 2010.

Virtualisation company buys SaaS Provider. Big one buys Infrastructure (IaaS) Providers. Big one buys cloud management tool. OS Platform provider buys cloud management tool. Big SaaS provider acquires Platform (PaaS) provider. IaaS Provider buys cloud management tool. This all sounds very confusing, right? In which direction do all those players finally go?

I would say they go all into the same direction. The final destination is PaaS (Platform as a Service). The picture below visualizes the path, which is for some longer and more complicated then for others. The companies in the yellow rectangle in the middle have all been acquired in 2010. The buyers come from different directions, but they all have the same destination.

Since Amazon EC2 launched their IaaS offer, traditional hosters (Rackspace), the traditional Big 4 (but also ISPs and Telecoms) move into this space. They all want to add additional services on top of a raw IaaS offer – monitoring, management, security, deployment, auto-scaling, automation, load-balancing. The SaaS providers on her turn want to make their SaaS offers more flexible and customizable. And from yet another angle, OS software providers (like Redhat, but also Microsoft and Oracle) enter the market. The Internet Giants Google and Microsoft even built there own PaaS offerings. They will end up to meet and fight in the middle. They all go PaaS.

Filed under: PaaS, , , ,

EC2 Security Groups

From the very beginning, Amazon AWS introduced a security concept called Security Groups in its Elastic Computing platform (EC2). Every virtual instance must be linked to one or more security groups when it is launched. A security group consists of a set of rules (called permissions) that describe who and how instances can be accessed. They allow to specify port ranges, protocols, and source IP address ranges, and are thus very close to firewall rules.

But security groups are even more powerful since they also allow to grant access to other security groups (instead IP address ranges), which allows dividing infrastructures into different security zones (like DMZ vs Critical Zone) with precise security policies and perimeters.

As far as I could see, there are three major functionalities missing with Security Groups:

  • rules can only restrict incoming traffic, not outgoing
  • lack of reporting (at least some logging)
  • lack of blacklisting to drop/reject malicious IP addresses

The first one (no rules for outgoing traffic) is important since it helps to avoid scenarios where someone wants to win control over a service that itself communicates to the outside. A solution could be the use of additional firewalls like iptables on every virtual instances. The second missing feature (access logs) would help to identify attackers that use port scanners – EC2 may detect and ban some of them, but there’s no information on the granularity of detection and a total lack of transparency for the EC2 customer. The third missing feature (blacklisting) would allow to identify IP addresses that showed malicious behaviour in a given zone (security group) and ban them for all other zones (security groups). This would allow to drown DDoS (Distributed Denial of Service) attacks quickly before the attack reaches other servers.

At the end, some remarks on another feature that is often cited as missing feature: the fact, that an instance cannot change its security groups after launch. I don’t think this should be changed: in terms of security, you should restrict network access before connecting to the network to ensure that there is no vulnerability hole before everything is up and working. In any case, you can simply relaunch your instance with a new security group with new rules.

Filed under: AWS, ,

Elastic Detector Private Beta

After more than 6 months of development following another 6 months of trying to understand the most important security needs of people that use infrastructure clouds today, we released our monitoring and security tool called Elastic Detector as private beta.

Elastic Detector runs as Software as as Service (noblesse oblige ;-) ) and allows you to easily and fully automatically monitor and secure your virtual machines on Amazon EC2. Our idea is to take away the burden of configuring and deploying monitoring (and later also firewall rules and access rights) in dynamic infrastructures. By inspecting characteristics and security perimeter of an infastructure via different means, we reduce human interventions to a minimum.

We have granted access to a limited number of users during a closed beta-phase. If you are interested to participate during the private beta phase (until end of January), you can contact us under private-beta {at} secludit-dot-com.

Filed under: Internals, Solutions

Twitter Updates

Follow

Get every new post delivered to your Inbox.