AWS Cloud9: First Look from an Ops Perspective

I just spent a couple of hours playing around with AWS’ new Cloud9 product, a fully browser based IDE with a lot of integration into AWS services.

I’m really impressed with the product overall. I have not ever had the chance to use Cloud9 prior to AWS purchasing it, but I can definitely understand the merits and interest by a lot of developers in a completely cloud-based IDE.

Here are some of my thoughts and findings that are more relevant from an infrastructure operations perspective. I know developers will be eager to get their hands on this product in the enterprise!

Gigantic error message indicating a user with both AdministratorAccess and Cloud9Administrator permissions cannot access the environment.

• EDIT (Dec 3): pointed out by Fabian Jakobs that any AWS Admin can add themselves to any environment using the AWS CLI/API. Docs here.
  Original Content: You must be invited to a Cloud9 environment in order to access it. As far as I can tell, there is no way around this. What this means is: even as an AWS administrator, if you haven’t been invited to a Cloud9 environment, you cannot access it. I don’t see any where to control access to Cloud9 environments specifically with IAM — it seems to be an internal permissions management system that is managed within the Cloud9 service. Note that an Administrator can view information about the environment, just not actually launch the IDE.

Environment Membership and Invitation Screen

• There is no support for AWS roles or federated/SAML based development environment sharing. If your org is using a SAML based authentication service to provide AWS access, developers will not be able to access others’ Cloud9 environments. Cloud9 environments can only be shared between other IAM users.
• Each new environment will either create a new EC2 instance, or allow you to connect to an existing server (EC2 or otherwise) via SSH. Make sure you protect these instances the same way you would any other EC2 instance in your account.

There are 2 ways to create a new environment. Here are a few nuances of each.

Create a New Instance for Environment (EC2)

• AWS will automatically provision an EC2 instance for you with a specific Cloud9 optimized AMI, including all of the dependencies required for Cloud9 to work correctly. You will see this instance in your list of EC2 instances, but are not given the SSH key to access it.
• When choosing a VPC and subnet for this new Cloud9 environment, it needs to be within a public subnet. In order for the Cloud9 service to communicate with your instance over SSH, it needs to talk to the instance over the internet. There is no private option for running Cloud9 currently.
• By default, it will assign a single, new, security group to this instance. Cloud9 will create this group to allow SSH (TCP port 22) access from 0.0.0.0/0. Obviously, this isn’t the best rule, especially since the instance needs to be publicly accessible. After playing around for a while, I am having success modifying this security group to only allow SSH access from any of the EC2 public IP ranges for the region where you’re setting up Cloud9. Use the ip-ranges.json file published by AWS here.
• A benefit of using this option — you can choose to have the environment (EC2 instance) hibernate (shutdown) when not in use after a specified amount of time.
• When a user launches an IDE created under this type of environment, they get their user’s IAM credentials automatically available to them in the IDE, so they can use the AWS CLI and SDKs without having to configure any additional credentials within the environment.

Connect and run in a remote server (SSH)

• With this option, you are specifying a public endpoint which is accessible over SSH which Cloud9 can set itself up onto. You get a few options as far as configuring the location on the server to create the Cloud9 environment, where the Node.JS binary is, which user to run as, etc.
• AWS will provide you a public SSH key during this set up process. You need to add this public key into the authorized_keys file on the server you are using, in the user’s profile you have specified during the set up process.
• The same security group and public address requirements as the EC2 option above apply here as well. Your instance needs to already be created to use this option, and needs a security group assigned which allows access to SSH (port 22) from either 0.0.0.0/0 or from the EC2 public IP ranges for the specific region.
• There is an option under this environment mode for specifying a jump-server — this could be a good alternative for locking down an environment, but still requires a public endpoint for the public jump server. I have not tried this out yet to understand the nuances of how it works.
• You’ll need to make sure you have the required dependencies installed on the EC2 instance prior to the Cloud9 installation completely successfully. The main dependencies required are Python and Node.JS. More details can be found here (step #9).

Cloud9 Installer Progress Screen with Errors

• Since this option is presumably on a machine without any associated Cloud9 environments, Cloud9 will SSH into this instance and configure Cloud9 for you. During this time, you’ll be able to monitor progress of the installation within the Cloud9 console — seeing exactly what’s happening during installation. As I was first going through the installation and missing dependencies, I was getting error messages and able to easily see them.
• When a user launches an IDE created under this type of environment, they will be using the IDE with whatever IAM permissions are configured in the local environment for the user which was chosen during environment configuration. For example, if doing this on an EC2 instance, you can assign a role to the EC2 instance and the Cloud9 IDE for any user in this environment will have access to the resources granted by the IAM role.

Some #AWSWishList items for Cloud9

• Now that AWSVPC mode exists within ECS, let me use a docker task with an attached ENI as the backend resource for an environment. I actually thought this would be possible to do today, but ran into a few limitations that make this not easy to do currently.

1. Using the “standard” (non-Fargate) ECS tasks with awsvpc network mode, you cannot assign public IP addresses to these, so you are unable to point Cloud9 to the container.
2. Using ECS with Fargate, public IP addresses are possible to attach to a running task, but there is no persistent EBS storage in a task, so environments would be completely ephemeral. I think this is ok in some use cases, but I know this would be an issue for some to have to keep configuring environments each time they are launched and for a process to be put into place to automate that could be painful (though not impossible).

• Provide a smaller IP range specifically for Cloud9, or some other way to better filter incoming requests from Cloud9 so security groups don’t need to be opened up to the world, or to a gigantic range of EC2 addresses.
• Offer some kind of private network connectivity between Cloud9 and the instances in my account, so things don’t need to be publicly accessible. This seems like a good use case for the new PrivateLink offering announced at re:invent.

Again, I really like what AWS has done with this and I think it’s a really cool product that definitely has a wide range of use cases. The Lambda debugging is amazing. Coming from an enterprise, I know there will be questions about operations and security, and wanted to call some of that out. Let me know if I missed anything as far as something that can be done to work around the above.

Thanks for reading!