Cloud computing with OpenShift
Open Advantage
OpenShift and other PaaS products can help take some of the work out of deploying and managing systems.
Cloud computing security is one of my favorite subjects. Disclosure: It's actually my day job now at Red Hat, dealing with products like OpenShift (PaaS), OpenStack (IaaS), CloudForms (Orchestration), and so on. Please note for the purposes of this article, I'm largely going to ignore public clouds like AWS and OpenShift Online and focus instead on the on-premises side of cloud. Why? Well, back in the day, administrators used to deploy physical servers and thought that was great. Then, virtualization came along, and admins realized that deploying physical servers was a chore and that virtualization was the way to go.
Now, folks are moving into infrastructure as a service (IaaS) and deploying OpenStack internally, and being able to create a Heat template to deploy new systems in minutes is even easier! IaaS, however, is not the end-all. Platform as a service (PaaS) lets you largely ignore the operating system and network layers; ideally, you can specify something like "this application requires a web server, say, Ruby and Ruby on Rails for application, and some back-end data storage, so I'll go with MongoDB and memcached," and be done.
Often, application authors don't care, or want to care, about the underlying operating system or tuning things like the database server (e.g., one user might have a dedicated one, and another might be using a shared instance). PaaS lets application authors avoid these details, leaving them up to the PaaS layer.
OpenShift
I will admit, I'm biased when it comes to PaaS: My preference is OpenShift. For one thing, it's what Red Hat ships, but it's also one of the few PaaS offerings that is open source and available for download (unlike Heroku or Google App Engine). It also supports a wide variety of programming languages and services. In fact, OpenShift has an open cartridge specification; if your underlying platform (RHEL, CentOS, Debian, whatever) supports it, you can quickly wrap it in a cartridge for OpenShift and use it.
Do you need Fortran support? Cobol? Some obscure application to convert PDF files into haiku? OpenShift can do that [1]. This approach obviates a lot of potential problems; moving existing applications into PaaS can be a problem if the programming language is not supported or if a component requires something the PaaS does not provide. Moving things out of an existing PaaS is also a worry: If you pick a PaaS vendor that does not provide an open source version of the PaaS, then you'll have a pile of specialized code and services that will take some time and effort to convert into something you can use on a different platform [2].
With OpenShift, you can simply buy it from Red Hat or grab the free version (OpenShift Origin [3]) and deploy your own instance. Remember, one leg of the security triad is availability, and if you're locked into a platform, that's a potential risk that can really hurt.
SELinux vs. LXC
One of the biggest security decisions OpenShift faced was how to segment users. Many PaaS systems take one of two approaches: either they create separate virtual services or instances using something like LXC, or they offer only a limited and "safe" subset of capabilities (e.g., no local storage, no shell access). The first approach of using virtual servers is problematic for performance; if you have 10 users, that means 10 running copies of the Linux kernel and all the userspace stuff needed to support them.
The second approach, of course, can be very frustrating for developers and users; you need to architect your application around the limitations of the PaaS. OpenShift opted for a third option: using SELinux to secure the system so that users can't attack each other, and using cgroups to prevent abuse of resources. The advantage of using SELinux is that you have one running kernel, and you can even use shared memory segments. So, if you have 10 identical copies of Apache HTTPD running, it doesn't consume a huge amount of memory, and the same is true for other services, like MySQL, Ruby on Rails, and so on.
OpenShift also assigns each account its own local network space, so if you run a copy of MySQL, for example, only applications within that gear (which is a collection of cartridges and software that runs within the same user account on the same server) within your account can access it. Other accounts and gears cannot. This approach in turn allows OpenShift to give users their own copies of MySQL or Apache. OpenShift does not need to rely on a service supporting multiple users securely. So, for example, when an authentication bypass was found in MySQL, although OpenShift was affected, there was no way to exploit it directly. An attacker would first need to compromise the web application, for example, and then attempt to compromise MySQL [4].
Running Untrusted Code
In general, everyone likes to pretend that the software they're running is safe and "secure" if they keep it up to date. The reality is that software has publicly known flaws that haven't been fixed yet and almost certainly has privately known flaws that have not been fixed yet either.
One way to deal with this situation is to run the software within some sort of container, such as chroot, or an entire virtual private server. The challenge lies in the overhead of doing so and the cost of setup, especially when you're defining allowed communications channels. Almost all modern software needs an input of data and an output of results to be useful, and, in most cases, like a Bash command line, admins tend to string programs together to do really useful things.
A framework like WordPress or Drupal is great, but you probably also want to generate nicely formatted documents, so a PDF converter is a good idea. Additionally, you want to email those documents out to people, and you want to talk to some third-party payment system so that customers can pay you. With OpenShift, you have two main options: You can place the various pieces that need to talk to each other within the same OpenShift gear, or, if you want to separate things further, you can have multiple gears and allow the software to talk to each other over the network. The good news is that many things now include a REST API, so talking to components over the network is becoming standard and allows components to be isolated more easily.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Gnome OS Transitioning Toward a General-Purpose Distro
If you're looking for the perfectly vanilla take on the Gnome desktop, Gnome OS might be for you.
-
Fedora 41 Released with New Features
If you're a Fedora fan or just looking for a Linux distribution to help you migrate from Windows, Fedora 41 might be just the ticket.
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.
-
System76 Unveils an Ampere-Powered Thelio Desktop
If you're looking for a new desktop system for developing autonomous driving and software-defined vehicle solutions. System76 has you covered.
-
VirtualBox 7.1.4 Includes Initial Support for Linux kernel 6.12
The latest version of VirtualBox has arrived and it not only adds initial support for kernel 6.12 but another feature that will make using the virtual machine tool much easier.
-
New Slimbook EVO with Raw AMD Ryzen Power
If you're looking for serious power in a 14" ultrabook that is powered by Linux, Slimbook has just the thing for you.
-
The Gnome Foundation Struggling to Stay Afloat
The foundation behind the Gnome desktop environment is having to go through some serious belt-tightening due to continued financial problems.
-
Thousands of Linux Servers Infected with Stealth Malware Since 2021
Perfctl is capable of remaining undetected, which makes it dangerous and hard to mitigate.
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.