Finally! AWS Lands A Second European Region

by Sebastian Stadil on Oct 23, 2014 2:00:00 PM

Earlier today, Amazon announced the launch of “eu-central-1”, its latest Amazon Web Services (AWS) region, physically located in Germany, near Frankfurt. Here are three main reasons why this move matters:

First, data residency; of course. Of all European countries, Germany has the most stringent privacy laws. With a presence in Germany, AWS will be able to extend its customer base across regulated businesses in Germany.

Read More

Topics: Announcements, Opinion, Cloud News, AWS, Amazon

Reaching for the Stars: JPL Selects Scalr for Cloud Management

by Sebastian Stadil on Oct 21, 2014 1:28:39 PM

We are excited to announce today that NASA’s Jet Propulsion Laboratory has contracted with Scalr to use our Cloud Management Platform to manage its AWS public cloud and OpenStack-based Nebula One private cloud. 

Jet Propulsion Labs, for those of you not in the know, is a federally funded research and development center and NASA field center. JPL is currently working on the proposed Europa Clipper Mission, eponymously named after Jupiter’s moon which it will survey. This is the stuff of boyhood dreams, and the fact that we’ll get to help JPL over the course of this potential fifteen year mission is really exciting.

Particularly, we are looking forward to helping JPL manage its hybrid cloud environment, including helping the organization meet security and regulatory requirements. As a federally funded laboratory, JPL is subject to a variety of federal regulations including FISMA, ITAR and NIST guidelines – all regulatory standards Scalr can actively help JPL achieve and manage – across both highly popular consumer facing websites and confidential, internal workloads.

JPL specifically chose Scalr to manage its hybrid cloud infrastructure as it allows the organization to centralize management in a single platform, which lets JPL IT focus its efforts on the commonalities across projects. This in turn allows JPL to reduce duplicative work, saving engineers and scientists time as they access the Scalr console at the platform tier. To provide this elastic infrastructure, JPL will be able to create an abstraction layer on top of OpenStack-based Nebula One and AWS to act as a platform for application deployment and provide the ability to control who has access to which applications and data, and where they are deployed.

JPL is going to see the promise of a hybrid cloud strategy in action facilitated by self-service development provisioning. And, Scalr global orchestration will allow JPL IT to set, manage and transparently enforce policy-based compliance across their private and public clouds.

We are looking forward to applying our experience on the Europa mission to JPL’s other many long-term, phase-based projects with highly variable infrastructure and application needs.  

Read More

Topics: Announcements, OpenStack, Cloud Management, enterprise cloud, cloud adoption

Security Announcement: Scalr Discontinues Support for SSLv3

by Thomas Orozco on Oct 15, 2014 1:44:24 PM

On October 14th, a team of security researchers from Google announced a new attack on SSLv3: POODLE (CVE­ 2014-­3566), which compromises the secrecy of communications secured using SSLv3, one of the technologies that enable clients and servers to establish an encrypted connection over the internet (e.g. an HTTPS session).

What you need to know

Due to numerous faults in the specification, SSLv3 has been deprecated for a while, but it remained in use across the internet for compatibility with very old clients. Note that this does not mean clients are actively using SSLv3 to talk to e.g. Scalr (TLS, SSL’s successor is used in overwhelming majority of connections). All it means is that SSLv3 is available if they choose to (which they seldom do).

However, in order to ensure the security of our customers, POODLE marks the end of the road for SSLv3 at Scalr, as we are disabling support for it across our servers. This means that clients will now be required to use TLS to talk to Scalr.

What you need to do

As a user, it is unlikely that you’ll be affected. Your clients will continue using TLS to talk to Scalr like they did before we removed support for SSLv3 (like it should). If you do get in trouble, you’ll need to update your clients to something more recent  (for example, TLS has been available in OpenSSL for upwards of 15 years).

Note that if you are using Scalr to deploy HTTPS web servers, you will likely want to make the same change to preserve the security of your users.
Read More

Topics: Announcements, Technical, Security, Google

Application Cloud Readiness Checklist

by Thomas Orozco on Sep 30, 2014 8:00:00 AM

“Is this app ready to be deployed to cloud?”

If your organization is planning a migration to cloud (and today, who isn’t?), this is a question you’re going to ask a lot. But how do you tell? Look no further: here’s a checklist of what you’ll need to validate before you can label an app “cloud-ready!"

 

1. Is the deployment of your app automated?

Read More

Topics: DNS, Tips, Cloud Native, DevOps, Lifecycle Management

Upgrade Bash and Address CVE-2014-6271 ("Shellshock") now with Scalr

by Thomas Orozco on Sep 24, 2014 4:58:00 PM

Earlier today, it was discovered that bash (the “Bourne-again shell”) was susceptible to remote code execution.

The vulnerability (CVE-2014-6271) is triggered when bash is called with specially-crafted environment variable values (which, unlike environment variable names, aren’t usually validated!).

To check whether a given system is affected, you can run the following command:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test" 

Just How Bad Is This?

Very bad. Passing user-provided information through environment variables is in fact pretty common (it’s done in CGI scripts with HTTP_* variables for user-provided headers, in SSHD with SSH_ORIGINAL_COMMAND, etc.).

What’s more, on RHEL, bash is the default shell, which means that all your calls to system (e.g. any Python that uses os.system, etc.) go through bash (and are therefore vulnerable). So even if you are not directly using bash, you might still be (indirectly) vulnerable.

If you are using Debian or Ubuntu, your attack surface is slightly more limited, because the default shell is dash, not bash. That is not to say this is a minor vulnerability, though — you should nonetheless upgrade immediately.

Upgrade Bash Now

To upgrade your systems, you can use the following script (use One-Off Script Execution). It’ll detect the package manager you’re using, update bash, and run a test (it’ll exit with 0 if the update was successful, 1 if you’re still vulnerable).

Check your Scripting Logs to ensure that the vulnerability is gone.

 

Ensure the vulnerability doesn’t come back to haunt you!

You can use Global Orchestration (a new Scalr 5.0 feature) to ensure that the aforementioned script runs on all your instances (preferably upon HostInit), so that bash is updated at startup on all your systems.

Update: Bash still vulnerable

The fix released by the bash maintainer earlier today did not entirely address the issue, and you should need run another update (consider updating the is_vulnerable function with the code linked here, which will let you know whether you are still vulnerable).

Does This Vulnerability Affect Scalr?

This vulnerability doesn’t affect Scalr directly, but it does affect the servers you are managing through Scalr.

 
Read More

Topics: Technical, Security, Tips

Welcome to the Scalr blog!

We build a Cloud Management tool that helps businesses efficiently design and manage infrastructure across multiple clouds.

Here, we post about our experience working with the Cloud, and building Scalr. On average, we do that twice a week.

Sometimes, we'll also cover Cloud-related news.

Subscribe to Email Updates