The Elastic Server team recently announced the ability to use the ES Factory to assemble and deploy images to Eucalyptus Clouds and has been working with some trial users on our test platform. Last week it was released to our production site.
2pm: Released to production
2:07pm Inbound "contact me" email from our website:
Name: "new euca guy"
Email: "new euca guy"@gmail.com
Subject: Eucalyptus Deployment Request
Message: I wanted to enable my cloud with your service.
2:30pm One of our team points this person to the page in ES where you enter your Eucalyptus Credentials to connect to a Eucalyptus cloud.
4pm Response from this new ES and Eucalyptus user
"Congrats!
My first build from ES to a private cloud worked and worked well."
Ok. So do that Opsware, Bladelogic, or Tivoli Provisioning Manager! This is one of the manifestations of virtualized infra and cloud computing that I think is still being missed; automation infrastructure is available to everyone, not just the Fortune 500.
Remember the McKinsey Cloud paper flurry of a few weeks ago? The trade press missed the point. Their headline was "McKinsey has concerns about the cloud". Actually if you look at the slides the real headline was "McKinsey doesn't believe that the largest global enterprises in the world can move their data center operations wholesale to Amazon EC2 (duh!), but other than that probably OK for everyone else!" (They actually said "clouds are very cost effective for SMEs".)
Well great - because that is most of us! Many large organizations work on a quite fragmented basis where the business units have autonomy and control. Really more a collective of SMEs than one enterprise. Let's grab them too.
Solutions like those provided by CohesiveFT and RightScale bring a level of automation infrastructure that your average IT department has never had the time or money to take advantage of. As we approach a 2.5 times an order of magnitude increase in the number of servers that we collectively assemble, deploy and manage (on our way to 250,000,000 VMs folks), loosely coupled automation infrastructure is going to absolutely change the game of enterprise IT.
Tuesday, May 19, 2009
Thursday, May 14, 2009
Securing your Elastic Server
A server by any other name is still a server. At the end of the day a virtual server is just a server, and an Elastic Server is no different: we just fill it with more goodness. And like a bare-metal server, it needs to be secured against the bad guys.
How much you'll want to secure your Elastic Server depends on your requirements, opinions and philosophies for security. Some people might be comfortable with running SSH openly, including allowing root access, other people will lock everything down so tightly you'd need direct access to break in.
The purpose of this document is to give some pointers to will help you tighten up the default Elastic Server. It's not definitive; there are many other steps you will need to take before you get the ultimate, secure server. If you want that level of security we suggest you talk with an independent security specialist, or the NSA. These are just some of the steps we've used in the past.
Users
Elastic Servers ship with 2 users - cftuser and cftdev. The cftuser password is sent to you when your build has completed. The other user, cftdev, is used by CohesiveFT internally when helping customers work out issues.
In order to secure your machine we suggest that you:
* Create a new user for login purposes
* Delete the cftdev user
* Delete the cftuser user
To accomplish these steps, log on to your Elastic Server as cftuser, then:
Before going any further, check the you can log on as your new user - there should be no problem, but if you mistyped the password (twice!) then you could lock yourself out. If all is good then make whatever additions to sudo to allow the new user access and then, when satisfied, delete the cftuser user.
A further enhancement is to change the root user password. The root password is already a random set of characters, but if it helps with the feeling of security then please change the password.
Elastic Server Manager
The Elastic Server Manager is a tool which you can use to administer your Elastic Server. The majority of its functionality is supplied via a set of web services.
There are several things you can do to secure ESM, depending upon personal preferences.
* Change passwords
* Block ports (only allow 9090 internal)
* Disable everything
* etc.
Recently we made a change to Elastic Server Manager so that the default password for all 3 of the shipped users (admin, manager, observer) is the same as the cftuser password. This gives the creator of the VM more control than before and it's more secure out-of-the-box. However we still strongly recommend that you consider modifying passwords. To do this, log on to ESM and click on the "User Management" link on the left side of the screen. From there you can add, edit and delete users.
The web services are set, by default, to be accessible (they're secured in other ways, but that's for another blog post). However you may not want other people to access them. The change is very simple (although you'll need to be logged in via ssh in order to do it):
Find the line which reads:
Change it to read:
And then restart shorewall:
(Note: the steps below are for Debian-based systems; other systems use similar package names.)
To disable and delete Elastic Server Manager and the web services, log on and type:
This will stop the Elastic Server Manager and remove it and the web services. It will also remove all rubber-bands that are used by the Elastic Server Manager and you will be left with a server where you have to manage the components by hand.
Shorewall
A full discussion of Shorewall is beyond this post, but in brief Shorewall is the firewall that is installed by default on all Elastic Servers. We open up a few ports by default to allow limited access by the default components. You'll be able to see these ports in the /etc/shorewall/rules file. In particular:
* Ports 2999 and 4433 are used by the Elastic Server Manager -- 2999 is the
default port and 4433 is the SSL version.
* 9090 -- this is the port used by the web services
* 22 -- this is the port used by SSH.
Any other ports are added by components selected at the time of manufacture. For example, if you add the MySQL database to your VM then you'll see port 3306 in the rules file.
We recommend making changes to this file only if you know and understand what you're doing.
Conclusion
There are many things that can be done to tighten up any virtual machine's security. A lot of it depends on knowledge (what do I have on my machine? what's it going to be doing? is it needed?), some on personal preferences (never allow root to SSH into a machine, never have any extra components/packages/libraries on a server). We've pointed out a few areas above that may be of some concern to some of our users. Let us know if there are any other areas that you feel should be tightened up. Who knows, maybe some of the suggestions will make it into the core Elastic Server.
How much you'll want to secure your Elastic Server depends on your requirements, opinions and philosophies for security. Some people might be comfortable with running SSH openly, including allowing root access, other people will lock everything down so tightly you'd need direct access to break in.
The purpose of this document is to give some pointers to will help you tighten up the default Elastic Server. It's not definitive; there are many other steps you will need to take before you get the ultimate, secure server. If you want that level of security we suggest you talk with an independent security specialist, or the NSA. These are just some of the steps we've used in the past.
Users
Elastic Servers ship with 2 users - cftuser and cftdev. The cftuser password is sent to you when your build has completed. The other user, cftdev, is used by CohesiveFT internally when helping customers work out issues.
In order to secure your machine we suggest that you:
* Create a new user for login purposes
* Delete the cftdev user
* Delete the cftuser user
To accomplish these steps, log on to your Elastic Server as cftuser, then:
$ sudo adduser bill
Adding user `bill' ...
Adding new group `bill' (1005) ...
Adding new user `bill' (1005) with group `bill' ...
Creating home directory `/home/bill' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
...
$ sudo visudo (edit line that includes cftuser and cftdev and add your new user account in this example 'bill')
$ sudo deluser cftdev
Removing user `cftdev`
Warning: group `cftdev` has no more members.
Done.Before going any further, check the you can log on as your new user - there should be no problem, but if you mistyped the password (twice!) then you could lock yourself out. If all is good then make whatever additions to sudo to allow the new user access and then, when satisfied, delete the cftuser user.
A further enhancement is to change the root user password. The root password is already a random set of characters, but if it helps with the feeling of security then please change the password.
Elastic Server Manager
The Elastic Server Manager is a tool which you can use to administer your Elastic Server. The majority of its functionality is supplied via a set of web services.
There are several things you can do to secure ESM, depending upon personal preferences.
* Change passwords
* Block ports (only allow 9090 internal)
* Disable everything
* etc.
Recently we made a change to Elastic Server Manager so that the default password for all 3 of the shipped users (admin, manager, observer) is the same as the cftuser password. This gives the creator of the VM more control than before and it's more secure out-of-the-box. However we still strongly recommend that you consider modifying passwords. To do this, log on to ESM and click on the "User Management" link on the left side of the screen. From there you can add, edit and delete users.
The web services are set, by default, to be accessible (they're secured in other ways, but that's for another blog post). However you may not want other people to access them. The change is very simple (although you'll need to be logged in via ssh in order to do it):
$ sudo vi /etc/shorewall/rulesFind the line which reads:
ACCEPT net $FW tcp 9090Change it to read:
ACCEPT $FW $FW tcp 9090And then restart shorewall:
$ sudo shorewall restart(Note: the steps below are for Debian-based systems; other systems use similar package names.)
To disable and delete Elastic Server Manager and the web services, log on and type:
$ sudo apt-get remove --purge axis2c cft-rubymin2This will stop the Elastic Server Manager and remove it and the web services. It will also remove all rubber-bands that are used by the Elastic Server Manager and you will be left with a server where you have to manage the components by hand.
Shorewall
A full discussion of Shorewall is beyond this post, but in brief Shorewall is the firewall that is installed by default on all Elastic Servers. We open up a few ports by default to allow limited access by the default components. You'll be able to see these ports in the /etc/shorewall/rules file. In particular:
* Ports 2999 and 4433 are used by the Elastic Server Manager -- 2999 is the
default port and 4433 is the SSL version.
* 9090 -- this is the port used by the web services
* 22 -- this is the port used by SSH.
Any other ports are added by components selected at the time of manufacture. For example, if you add the MySQL database to your VM then you'll see port 3306 in the rules file.
We recommend making changes to this file only if you know and understand what you're doing.
Conclusion
There are many things that can be done to tighten up any virtual machine's security. A lot of it depends on knowledge (what do I have on my machine? what's it going to be doing? is it needed?), some on personal preferences (never allow root to SSH into a machine, never have any extra components/packages/libraries on a server). We've pointed out a few areas above that may be of some concern to some of our users. Let us know if there are any other areas that you feel should be tightened up. Who knows, maybe some of the suggestions will make it into the core Elastic Server.
Wednesday, May 13, 2009
Eucalyptus Deployment Now Even Easier!
With our latest update to the Elastic Server Factory comes the ability for our Personal Edition users to deploy Elastic Servers to their private Eucalyptus Cloud completely from the Factory UI. No more emailing us your creds, simply download your X.509 certificate from your Eucalyptus Cloud Interface and upload it to the Factory from our Cloud Manager. That's all there is to it, start seeding your Eucalyptus Cloud in minutes with the Elastic Server Factory.
1. Login to Elastic Server and navigate to the Cloud Manager Page under the Account tab
2. Click the 'Add Amazon / Eucalyptus Credentials' button
3. Download your Eucalyptus X.509 Certificate from within your Eucalyptus Cloud Interface
4. Upload the Certificate to the Elastic Server Factory
5. Name your credentials
6. Build a server and select your cloud as the deployment option from the server configuration screen
Done.
1. Login to Elastic Server and navigate to the Cloud Manager Page under the Account tab
2. Click the 'Add Amazon / Eucalyptus Credentials' button
3. Download your Eucalyptus X.509 Certificate from within your Eucalyptus Cloud Interface
4. Upload the Certificate to the Elastic Server Factory
5. Name your credentials
6. Build a server and select your cloud as the deployment option from the server configuration screen
Done.
Subscribe to:
Posts (Atom)
