There is a good chance that your next "local development environment" won't be local, it will be cloud-based and all you will need locally will be a browser and an internet connection. You might already be using a Cloud IDE for certain projects. This exciting evolution of the local dev environment has a lot of advantages but also brings some new risks. This article will help you stay safe as you embrace the cloud for your coding needs.
What Is A Cloud IDE Or CDE?
Simply put, a cloud IDE is an integrated development platform, IDE based in the cloud.
An IDE is a collection of tools that developers use to edit, compile, debug and build their code. While IDEs offer a terminal, allowing developers to access CLI-based tools, most also offer a graphical user interface, or GUI, to better manage complex tasks and preview output. Traditionally IDEs are run on a developer's local desktop.
Cloud IDEs move the development experience of the IDE to the cloud, presenting the same CLI and GUI interfaces through the web browser. Instead of using the local machine's CPU to power your editor and execute code, the bulk of the computing work is done on the remote service. Cloud IDEs are highly customizable and are defined through software configuration, making them easy to replicate.
A Brief History Of Cloud IDEs
Over the last decade or so, we have watched as software has continued to eat the world. As companies have moved from on-premise hardware servers to cloud-based environments like AWS and Google Cloud Platform, we have witnessed a transformation to everything becoming code. Infrastructure as Code, IaC, arose to help go from the time-consuming, manual configuration of our multiple environments, to effortlessly deploying precise copies of production environments to anyone who needs one, often within seconds. One of the last manually configured environments that most devs still use to interact with their CI/CD pipeline is their local development environment.
Traditionally, each developer has been responsible for their own setup. While scripts and standards exist for projects and teams, all developers carefully configured their machines to meet project-required settings. Unfortunately, one outcome from coding and testing in one environment and running that code in another environment is the dreaded phenomenon of "it worked on my machine".
While container solutions like Docker and Kubernetes are a step in the right direction, letting developers spin up containers locally that matched production and testing perfectly, it was no magic bullet. Local dev machines needed to be beefy enough to run things like Docker Desktop and apps like Chrome and Slack at the same time. Often enough configuration differences that can't be worked around still result in code that "works here, but not there."
Not too long ago, a few companies reached the same conclusion; the local development model needed to evolve and be brought into the cloud, the same as the rest of the environments throughout the software development lifecycle, SLDC. Thus, Cloud Based Development Environments, or Cloud IDEs, or sometimes just CDEs were born.
While the idea of giving up your local environment might seem impossible or impractical at first, the real world offers proof it is not just achievable, but solutions are hardened to the point entire organizations rely on it. For example, in 2021 GitHub shook the development space when they announced that GitHub’s Engineering Team had entirely moved to Codespaces. This means that Codespaces and similar platforms are very much battle tested and ready for prime time.
Cloud IDEs are not the future or bleeding edge, they are the now for a lot of future-looking teams.
What Are The Advantages Of A Cloud-based IDE?
Aside from solving the major issue of configuration clash, the cause of "it worked on my machine," there are a number of other advantages to Cloud IDEs.
Making Coding More Accessible
Since all the computing is done on the server side, any computer capable of accessing the internet will do. This is especially important for folks just starting out on their development journey or who might not be able to afford the latest MacBook M2 machines with a ton of memory. Most plans have a free tier available, making these tools very accessible.
Speaking of new devs, one of the hardest obstacles to overcome when starting out is getting your local set up 'just right'. Any developer using tools like npm can attest that getting the right version working can be difficult due to operating system differences. Cloud IDEs eliminate this concern as you can spin up cloned environments that are preconfigured to have the exact versions of all your tools ready to go.
Keeping Your Project Needs Separated
Related to tools like npm, most devs find themselves working on multiple projects requiring slightly different versions of the same tools. Keeping track of what version is needed for what project can get tricky very fast. Since Cloud IDEs are just cloneable instances, you can spin up multiple environments for multiple projects, each with their own correct tool versions and with no overhead of manually switching between them yourself.
Onboarding Time And Effort
Onboarding time can be reduced a great deal as well in team or open source collaboration settings. Rather than the first week of work focusing on setup, calibration, and granting access to repos and services, devs can get access to their new environments in minutes with all needed config in place. I think this is one of the largest drivers that will make Clode IDEs commonplace moving forward.
The list goes on, but for all of these advantages, there are a few concerns that arise from accessing your dev environments, with all their permissions and connections, from a browser window. Let's take a look at some of those concerns and how you can keep safe as you migrate to the cloud for dev.
Cloud IDEs Security Concerns
Working in the cloud means there are more chances for access from unintended parties. There are certain things to keep in mind that might seem obvious when thinking about your work laptop, but which might get overlooked when dealing with a Cloud IDE. Here are some to consider.
Who Can Physically Access Your Browser?
One of the biggest advantages of a Cloud IDE is that you can access it from anywhere. If you are on vacation without your work machine and need to fight a fire in production, no problem. Just log in from any computer, such as your spouse's machine or the hotel lobby, and get the work done. While convenient, you can likely spot some red flags here. Working from non-secure machines can lead to unexpected people accessing your work environment.
Dangers can come from unexpected, though not malicious sources too. For example, you probably would not let your small children access your work machine; who knows what they might accidentally deploy or delete, all without any bad intent. We are generally very cautious with our physical work machines, we should apply the same caution here.
Before you stop working in your Cloud IDE, it is a good idea to ask yourself "who else might use this computer?" If the answer is anyone other than you, make sure you log out and confirm you can't access that environment again without reauthenticating.
Who Can Control Your Browser?
Working remotely has become the norm in the last few years. With the rise of remote work, we saw a massive increase in phishing, ransomware, and malware attacks. There are two types of attacks anyone working in a Cloud IDE should be keenly aware of: remote access attacks and browser hijacking.
Remote Access Attacks
In a remote access attack, users will grant access to the Remote Desktop Protocol, RDP, of their systems. This attack is commonly achieved through phishing. Once the access has been granted the remote attacker can do whatever they want on your device, including taking control of your open browser with your CDE.
This attack can be prevented by never granting remote access to your system, except for specific trusted entities, such as your internal IT. When in doubt, verify with the internal trusted source it is a legitimate request, no security expert will ever get mad if you double-check. As with any phishing attempts, stay vigilant and never click on any suspicious links.
You can protect your Cloud IDE instances by enabling multifactor authentication, MFA, wherever possible. Even if a bad actor remotely gets ahold of your desktop, if they can't get an authentication code or a one-time password, OTP, for your CDE, they won't get very far in their attack on your application.
Browser Hijacking
Browser hijacking attacks began as malware designed to redirect your browser to suspicious sites to drive advertising schemes. They have evolved, especially in the era of Zoom bombing, to steal any and all user data present in the browser and spy on the users over time. Once a browser is hijacked, every keystroke can be logged and sent off to be used by the attackers. Every session ID can be shared and anything you see on your screen can be seen by the attacker, including any plaintext secrets.
Preventing browser hijacking, in part means only installing extensions from trusted sources. Most browser extensions are open source, so you can verify the code is only doing what you want. Never click on any suspicious links from Zoom meetings, or show up in other communications for that matter. Most modern browsers are trying to fight this as well, so keep your browsers updated to get the latest security patches.
Who Can Create New Cloud IDE Instances?
While most Cloud IDE providers have generous free tiers, you will need to pay to get more hours monthly, more CPUs and memory, and create more environments. If you are working by yourself on a personal account, then there is not too much worry here, as you will be the only person authorized to make changes. But if working in an organizational or team setting, you will want to ensure that only authorized folks can start adding instances and features that end up on the monthly bill.
All providers offering organizational or team accounts will have some way to restrict who can create instances your org will pay for. In Codespaces, it is found under Your Organization -> Settings -> Billing:
Codespaces gives 4 levels of granularity to these settings:
- Disabled - Your organization will not be charged for Codespace usage, the individual member will.
- Selected members - Your organization will pay for these specific members.
- All members - Anyone in the org can create Codespaces under your organizational billing
- All members and outside collaborators - Danger Zone! Anyone working with your org can create their own Codespaces and your org will pay for it.
Be sure to review these settings carefully as you roll out Cloud IDEs in your company or teams.
Some Security Upsides Of Working In A Cloud IDE
While we have laid out some potential dangers you should be on the lookout for, we also think there are some really big upsides for security with Cloud IDEs. Being aware of and taking advantage of these features can mean more secure code and better overall development practices. Here are just a few examples,
Secrets Management in Cloud IDEs
One of the main reasons people hardcode secrets is purely convenience. While developers generally know everyone should use untracked .env files and/or set up tools like Hashicorp Vault, those take time and effort to configure and use vs copy/paste.
Cloud IDEs provide pre-configured secret managers that can be set at the project or organization level. For Codespaces, using them will look very familiar, you simply invoke them as you would any other environmental variable, for example: $AWS_EXAMPLE_KEY. The ease of use and setup is a very good path to help people stop committing their secrets and prevent secrets sprawl.
Repository Access From Your CDE
Working on a local machine means you will need access to all your repos, as you can work on any project any time the need arises. But this means anyone who can use your machine can also look through all your repos for exploits.
With Cloud IDEs, you have the option to only grant access to specific repositories needed for just that project. Even if a bad actor gets ahold of one cloud dev environment, they will be limited to just those areas and will not easily be able to move laterally.
Centralized Security Logs
Understanding exactly what happened in an event is an important part of the research process toward preventing similar incidents. While solutions do exist to give your security teams and IT insight into your local activities, most of the time gathering log info from local setups is a manual process. Cloud IDEs make the process of finding specific logs that much easier.
Security Best Practices for Cloud IDE and DevOps
While moving to a cloud-based development environment, it is a good time to reflect on general cloud security best practices. If it is a good practice for your production environment, it is likely a good practice for your Cloud IDE. Let's review a few of these topics at a high level.
Zero-trust Identity and Access Management
In a nutshell: People and services should have access only to things they explicitly need to be able to work, and at the least privileged level possible. Thinking through who and what services can access be accessed via your Cloud IDE is a good way to prevent unexpected access. Get rid of any third-party application authorizations as soon as they are not needed.
Use your provider's built-in tools to verify only expected services and people can gain access, just as you would for your other DevOps services and tools. Speaking of which, if you are using AWS, check out our series on AWS IAM.
Monitoring
We already mentioned security logging in this article. But are you monitoring those logs or just reviewing them after an event has happened? Having the best dashboards and early warning systems is useless if no one is paying attention to them. Build security monitoring into your workflows to look for any unexpected patterns. Most of the time it will only take a few minutes, but catching some malicious activity early can save you countless hours in the long run.
Keep Your Environments Private
While you want everyone to access your application's URL, you likely don't want them getting access to the staging server, S3 buckets, or other parts of your infrastructure. Granting access only to authorized requests is a great way to keep your private URLs private. Your Cloud IDE is no different. Make sure any URLs created through your work are secure and private. Keep an eye on available port settings as well.
There certainly are times when you want to share your work with the world, such as when working on open source code or teaching others. Sharing can be good, but only if done so conscientiously.
Review Platform Security Settings
Every cloud service provider wants you to succeed with their product and they work to make a safe experience. However, as a user, it can be easy to overlook certain security settings or best practices if you just rely on the preloaded defaults.
It is always a good idea to review the security setting and available documentation when adopting any cloud technology. Given how quickly Cloud IDEs are emerging and evolving, familiarizing yourself with the available options and any updates, is crucial to having the safest development experience.
Cloud IDEs Are Here, Let's All Work Safely
Whether you are new to the concept of cloud-based development environments or have already started using a Cloud IDE, we hope you learned something from this article. While Cloud IDEs offer a lot of advantages, it is good to be aware of a few security concerns this approach brings. Many of the same proven security practices from local development environments and DevOps pipelines can apply to this way of working.
Part of any good security practice includes keeping your secrets secret, and acting quickly if you find them exposed. Using built-in secrets managers can help you never commit a secret again; adding ggshield pre-commit hooks to your workflow, no matter where your 'local' environment is, can help you stop secrets leakage in the first place.
