Myths and truths about security in Red Hat OpenShift
Many of our customers are planning to start using Red Hat OpenShift, our preferred container orchestration platform. Its advantages can be summed up in that it allows a progressive modernization of existing applications and the deployment of many others that, for what to deny, with a design based on micro-services are imposed on many new IT architectures. Just thinking about never having to “prepare” a machine again (installing operating system, configuring network, security, installing libraries and dependent software) every time we want to deploy an environment justifies giving this technology a try.
Kubernetes
is to containers what OpenStack went to Cloud environments. An open source solution, which allows us to share a portion of the infrastructure available in our data centers: servers, networks, storage in resource pools on which to deploy, automatically various workloads. Through a self-provisioning portal, our developers will be able to not only deploy the environments they need to make their applications work perfectly, but also automatically and continuously verify that those applications are working properly. If a developer’s “commit” at the last minute of the day causes a bug, you can go back to the previous day’s version without anyone having to intervene.
If we add to this the ability to make gradual deployments, where a small percentage of users enjoy a new version of our application while the rest continue to use the latest stable version; high availability that works without any additional configuration, resource allocation (developers, memory, CPU, disk space, IP address assignment) per project, or the ability to measure in real time what part of our infrastructure we are using, at what level of efficiency and with what results, few system managers will say no to such a wonder. Not forgetting the ability to automatically scale applications by adding or removing containers as needed.
Luckily or unfortunately, noor all is in the hands of the system managers. What about security? What do CISOs think? Let’s to go over some “myths.”
OpenShift is tremendously safe by design. In our opinion, its basic technology (containers) is as secure as the Linux Kernel is at all times. That is, container processes are separated by linux kernel “namespaces”, the resources they use by “cgroups” and their security, and their context by SELinux. It’s powerful, yes, but we’re still sharing a kernel among many containers in each one. and the kernel needs to be patched, also for security reasons. The inclusion of RHCOS (Red Hat Core OS) has allowed us to make great progress in recent times in terms of the security of the operating system on which this Kubernetes distribution runs. However, since the RHCOS nodes are intended to operate with little change, it is important that any security-related improvements to those nodes are done with extreme care. it’s not going to be that we get the opposite effect.
The images we download are always verified and your code audited by Red Hat. Well, actually access to container images (downloaded or own) are managed in a similar way to RPMs. There are public or private repositories that we connect to, with their keys and their signatures. Vulnerabilities keep coming out every day so we need to have some kind of solution that monitors the contents of the container images available in our repositories, especially images downloaded and installed in our environment.
OpenShift supports JFrog Artifactory, Black Duck Hub, and Docker Trusted Registry. Red Hat CloudForms SmartState can also be used to mark vulnerable images in such a way that OpenShift prevents those images from being used. They are also useful for applications that perform static application security (SAST) testing and dynamic application security (DAST) testing, such as HP Fortify and IBM AppScan.
OpenShift has a robust and secure authentication system. Each OpenShift cluster actually uses user, group, and role accounts.
To manage each user’s access to OpenShift components and be able to verify each user’s identity, the cluster will connect to different identification providers (OpenID, LDAP, Active Directory, Github, etc.). Each of which will have its own configuration, advantages and disadvantages.
Isolation of networks and communications between OpenShift projects is sufficient. It is robust, because it is based on the network components of Kubernetes, but there are operators and plug-ins that can help us isolate the different networks or give dedicated accesses to certain network cards using technologies like SR-IOV. Plugins such as Multus-CNI that allow this and other functions, complementing the features of the Cluster Network Operator (CNO), the CNI’s “Container Network Interfaces” and CoreDNS .
Interested in knowing more about OpenShift? You may be interested in our three-day intensive Red Hat OpenShift 4.X course. We also offer official IBM training if you want to deploy IBM Power Systems servers.
