The unique design of Red Hat’s Linux-based Container technology, OpenShift, addresses many of the security concerns that have previously troubled financial services companies, enabling them to more fully explore the functionality of the technology. Containers allow users to easily package an application into a single ‘image’ that can be promoted from development to production without change. By providing consistency across environments and multiple deployment targets (such as physical servers, virtual machines and private or public clouds) teams can more easily develop and manage applications that deliver business value.
This is particularly appealing to companies in the financial services industry where customers are demanding faster access to applications and the ability to conduct more of their financial business virtually. Security remains the number one priority for both financial institutions and their customers, though, and our container solution addresses some of the key elements of essential security such as improving security of the container platform itself, and the images that are consumed by this platform.
In the past, application development was plagued by what we refer to as verticalised applications, where there was application specific code at all levels of the stack, from the data tier at the metal right up to the UI itself. Red Hat OpenShift delivers an application as a currency that can be distributed anywhere where containers can be hosted.
When users start up applications, they reach down into the operating system and require specific versions of the platform and the database. With our technology this is all abstracted into the container. Red Hat OpenShift restricts many of the vulnerabilities that might have been exploited on Docker or Kubernetes, introducing ‘military level’ security features and sandboxing every aspect of the containers in a highly configurable way. This makes the container technology itself more complex to implement which benefits the end users by simplifying the application, and once they are up and running they can be immutable aside from data. This is facilitated by the operating system that underpins the czontainer orchestration and provides added security.
Red Hat Enterprise Linux is comprised of a number of objects and processes to which rules can be applied through the use of a technology called SELinux (Security-Enhanced Linux), which provides control over denying or allowing capability, which then helps protect the host system on which the containers run.
We also have a process called MCS (multi-category security) that allows for sub-rules to be set up that are specific within a process, allowing sub-labeling of these processes to control and deny access from container to container.
In addition, we use a Linux kernel feature that enables resource control for the container, limiting its access to resources on the operating system. This is important because without controls the container could consume all the resources of the host on which it is running (the classic ‘noisy neighbour’ scenario).
A crucial element of Red Hat OpenShift security features is the use of the underlying Linux ‘Namespaces’, which control exactly what the container can do by using the PID namespaces and network namespaces within the operating system (namespaces are a feature of the Linux kernel that isolates and virtualises system resources for a collection of processes).
RHEL ATOMIC HOST
One of the most interesting aspects of our container security strategy is the use of Red Hat Enterprise Linux Atomic Host, which is essentially a stripped-down version of the operating system designed to run Containers. Combined with OpenShift and the Kubernetes project to which Red Hat contributes – which has a very strict enforcement policy for how an application is deployed in terms of replicas (the number of copies to run) and where the containers are deployed – this creates a highly efficient and more secure container orchestration system.
Another useful feature is the ability to use OpenSCAP to scan container images for security issues. OpenSCAP is a open-source standardised compliance checking solution that checks system configuration settings and examines systems for signs of compromise by using rules based on standards, specifications and exploit profiles.
Most financial services institutions have a public facing side to their business and they are realising that containers are easier to secure and control and the infrastructure on which they run is much tighter. This offers the prospect of improved application security and data. The concept of moving to a containerised system presents a significant opportunity for many financial services institutions running hundreds or even thousands of different machines and applications because they can get a single view of every application. Rather than running each application on a separate virtual machine, they can run them on containers on appropriately hardened hosts, providing massive multi-tenancy and much better efficiency of host usage as well.
Deploying and running containers more securely is a lot like securing any running process. You need to think about security throughout the layers of the solution stack before you deploy and run your container as well as throughout the application and container life cycle. Of course, a Container platform also needs to provide an experience that works for developers and operations teams. Red Hat OpenShift is about hosting applications properly, making it easier to write and manage them. This can reduce costs because operations teams are no longer firefighting – they have a single point of control and security access.
The technology addresses most of the day to day issues faced by developers that kept them away from *developing*. In the past, the majority of the code written was boilerplate, setting up security features, high availability, service discovery, etc. Red Hat OpenShift abstracts these concepts away from the application, enabling developers to focus on functionality, which in turn moves the configuration for the application away from the application codebase, allowing the operations teams the abstracted level of control they never had with verticalised applications.
Please use the comments section below to share your thoughts and let us know how we can work together to make your adoption of Containers more secure and simplified.