An Enterprise Guide for Securing Container Workloads in OpenShift
Cloud-native methodologies to develop applications are different from the traditional application development approach. So, the security approach must be different, too.
May 28, 2020
Containers are the key component for enterprises in the journey towards digital innovation in which service delivery is faster than it was before. Containers increased enterprise business value by bringing agility and portability in the software development life cycle (SDLC). SDLC is empowered with a feature that enables a single container image can be utilized in development, test, and production without any change.
As per the recent Cloud Native Computing Foundation (CNCF) survey, 84% of survey respondents said that containers are active in production. It was 23% in 2016. But security concerns are looming over the further adoption of containers and containers orchestrations platforms. The same is reflected in the CNCF survey, where the security of containers is identified as one of the topmost roadblocks for container adoption.
Enterprises are using containers with the help of leading managed containers platforms (RedHat, VMware, Ranchers, etc.) to gain better control of containerized workloads. Enterprises are also using containers on bare metal servers.
The focus of this article is to evaluate how Red Hat’s OpenShift container platform is leveraged by enterprises for the secure containerized environment at various service delivery layers.
OpenShift has its own container platform that is based on Kubernetes for helping enterprises to power their container workloads in hybrid and multi-cloud models. This platform ensures the automated operations and management from a centrally managed cloud-based portal. The central portal is used to monitor containers, networking, and upgrades and enforce policies on servers.
Enterprises can achieve scalability, portability, and persistent storage across the containers with OpenShift container platforms. Additionally, it enables an increase in productivity for developing applications with integrated CI/CD pipelines, self-service provisioning, and multi-language support.
But due to recent security concerns on containers, OpenShift had a workaround that enables secure hosting and operations of containers at various states of application delivery. The concern of container security has an impact across all these layers of the OpenShift platform and is associated with CI/CD pipelines, multitenancy management, continuous monitoring, and real-time risk detection.
Let’s discuss these layers of container security that are associated with OpenShift container platforms.
Platform and OS Multitenancy: For the security of the containerized application, it is recommended to host containers as processes that are nuclear in nature and synced with the host kernel. This feature enables containers to run on a shared platform for deploying multiple applications and managing them. Containers can be secure by securing the host kernel and keeping isolated from other containers. Further, it enables multitenancy within the host. OpenShift uses Red Hat Linux to achieve security. A multitenancy can be achieved by using security features in Red Hat Linux OS like namespaces, Security-Enhanced Linux (SELinux), Cgroups, capabilities, and secure computing mode (seccomp). Such multitenancy capabilities make OpenShift lightweight, easy-to-scale, and flexible.
Trusted Container Content: Container images containers package applications from different sources. In today's environment, most of them are open-source packages (Apache, JBoss, etc.) that are community contributed. OpenShift has scanning and health index features to check the integrity of content in containers. Also, it can apply patches to those applications in runtime.
Securing container access with registries: Registries are a key component to ensure the security of applications in a container-based environment. OpenShift is included with the private registry that enables two capabilities that secure containers: First, it provides role-based access control to track pull-push requests for container images. And second, track the contents of container images based on metadata like known vulnerabilities. With these features, you can flag malicious access to containers images and flag containers that are vulnerable to attacks.
Maintaining security during the build process: OpenShift supports Source-to-image (S2I) open-source framework to secure the build management process. Also, the build and CI process is enabled with automated security testing. OpenShift also supports Jenkins for managing builds, testing, and validations.
Control on Deployments: OpenShift security is ensured at another layer of the platform; before and after deployments of container images in production. Also, OpenShift has Security Context Constraints (SCCs) that has been integrated into Kubernetes as Pod Security Policy. SCCs control the running of privilege containers and avail SELinux context to containers.
Control on container orchestration: OpenShift supports Kubernetes and Red Hat CloudForms. Both collectively work as orchestration, automation, scheduling of tasks, and track the health of clusters. Orchestration admins get the information from pods through the API. That makes API as a crucial element to check security at the end level. To have secure orchestration, API access control mechanisms like authentication and authorization gets priority.
Networking isolation: It is important for containers to keep isolated from each other to ensure the security of applications. OpenShift supports the Namespaces and further enhances the functionality with Software Defined Networking (SDN) to gain control of communication among pods. Additionally, namespaces also need isolation at a granular level. Further isolation is achieved with an OVS-multitenant plug-in that completely isolated traffic between pods.
Storage layer: At this layer, security is taken care of by providing subsequent access control capabilities to shared, block, and persistent volumes (PVs). Additionally, the capabilities of SELinux is integrated to secure the root of the mounted volume for non-privileged pods.
API management/endpoint security and single sign-on (SSO): Managing application and API authentication & authorization is the key to secure applications. For the modern environment, SSO is enabled to have secure access to applications deployed with microservices architecture. OpenShift has support for Red Hat SSO (RH-SSO) to deal with this. It is integrated into LDAP-based directory services, including Microsoft Active Directory and Red Hat Enterprise Linux Identity Management. Also, it supports integration with social media accounts like Facebook, Twitter, and LinkedIn for getting access to pods. Further, API management is handled by Red Hat’s 3Scale platform that gives a variety of options for authentication and authorization. It can also restrict access to endpoints, methods, and services and apply access policies.
Roles and access management are federated clusters: Federation of the cluster is important to have high availability of applications in a different zone or data center in enterprises. And, this is the trend that amalgamates private data centers with different public cloud services. It is important to have orchestration tools that provide security during data transmission among those clusters. OpenShift has native support for Kubernetes that takes care of authentication/authorization and extends federation with Federated Secrets, Federated Namespaces, and Ingress objects.
Cloud-Native Security for OpenShift
Cloud-native applications enable agility in service delivery with applications that are distributed, microservices-based, and containerized. It provides an architecture that delivers a great amount of efficiency, scalability, and cost-effectiveness to businesses. Overall, methodologies to develop applications are different from the traditional approach. So, a security approach must be different. With cloud-native security expected features for securing cloud services includes below implications:
Most of the cloud-native applications are microservices-based. This adds complexity in threat detection. Securing such applications at run time with speed at which applications are being developed.
DevOps should be strictly replaced with DevSecOps that incorporates security at every stage of DevOps pipelines. It allows complete automation of security and provides continuous security for applications in deployment chains.
The focus of security is increased towards containerized server environments that are mostly distributed among clusters. So, the secure host and networking become a priority in terms of security.
Security tools should be integrated at the functional level to ensure the better health of applications deployed in a microservices architecture.
OpenShift security operations are empowered with the above cloud-native approach that has become a norm for almost all the providers. OpenShift is equipped with features that manage and protect risk in runtime, enables visibility of application, ensures, and tracks the health of containers.
Conclusion
Openshift is evolved to support modern application development with increased support for containers as well as Kubernetes. There were many security pitfalls around the containerization of applications, but as the fixes and practices are identified in OpenShift. In this article, we have seen how security is ensured at 10 layers of the OpenShift environment. And, how a cloud-native approach is integrated into the OpenShift platform.
About the Author
You May Also Like
2024 InformationWeek US IT Salary Report
Aug 15, 20242022 State of ITOps and SecOps
Jun 21, 2022