Biblio

Containers technology radically changed the ways for packaging applications and deploying them as services in cloud environments. According to the recent report on security predictions of 2020 by Trend Micro, the vulnerabilities in container components deployed with cloud architecture have been one of the top security concerns for development and operations teams in enterprises. Docker is one of the leading container technologies that automate the deployment of applications into containers. Docker Hub is a public repository by Docker for storing and sharing the Docker images. These Docker images are pulled from the Docker Hub repository and the security of images being used from the repositories in any cloud environment could be at risk. Vulnerabilities in Docker images could have a detrimental effect on enterprise applications. In this paper, the focus is on securing the Docker images using vulnerability centric approach (VCA) to detect the vulnerabilities. A set of use cases compliant with the NIST SP 800-190 Application Container Security Guide is developed for audit compliance of Docker container images with the OWASP Container Security Verification Standards (CSVS). In this paper, firs vulnerabilities of Docker container images are identified and assessed using the VCA. Then, a set of use cases to identify presence of the vulnerabilities is developed to facilitate the security audit of the container images. Finally, it is illustrated how the proposed use cases can be mapped with the requirements of the OWASP Container Security Verification Standards. The use cases can serve as a security auditing tool during the development, deployment, and maintenance of cloud microservices applications.

Containerization technology becomes one of alternatives in virtualization. Docker requires docker daemon to build, distribute and run the container and this makes the docker vulnerable to an attack surface called Docker daemon Attack Surface - an attack against docker daemon taking over the access (root). Using rootless mode is one way to prevent the attack. Therefore, this research demonstrates the attack prevention by making and running the docker container in the rootless mode. The success of the attack can be proven when the user is able to access the file /etc/shadow that is supposed to be only accessible for the rooted users. Findings of this research demonstrated that the file is inaccessible when the docker is run using the rootless mode. CPU usage is measured when the attack is being simulated using the docker run through root privileges and rootless mode, to identify whether the use of rootless mode in the docker adds the load of CPU usage and to what extent its increased. Results showed that the CPU use was 39% when using the docker with the rootless mode. Meanwhile, using the docker with the right of the root access was only 0%. The increase of 39% is commensurate with the benefit that can prevent the docker daemon attack surface.

Container technology has been used for running multiple isolated operating system distros on a host or deploying large scale microservice-based applications. In most cases, containers share the same kernel with the host and other containers on the same host, and the application in the container can make system calls of the host kernel like a normal process on the host. Seccomp is a security mechanism for the Linux kernel, through which we can prohibit certain system calls from being executed by the program. Docker began to support the seccomp mechanism from version 1.10 and disables around 44 system calls out of 300+ by default. However, for a particular container, there are still many system calls that are unnecessary for running it allowed to be executed, and the abuse of system calls by a compromised container can trigger the security vulnerabilities of a host kernel. Unfortunately, Docker does not provide a way to get the necessary system calls for a particular container. In this paper, we propose RSDS, a method combining dynamic analysis and static analysis to get the necessary system calls for a particular container. Our experiments show that our solution can reduce system calls by 69.27%-85.89% compared to the default configuration on an x86-64 PC with Ubuntu 16.04 host OS and does not affect the functionalities of these containers.

Cloud-based infrastructures have grown in popularity over the last decade leveraging virtualisation, server, storage, compute power and network components to develop flexible applications. The requirements for instantaneous deployment and reduced costs have led the shift from virtual machine deployment to containerisation, increasing the overall flexibility of applications and increasing performances. However, containers require a fully fleshed operating system to execute, increasing the attack surface of an application. Unikernels, on the other hand, provide a lightweight memory footprint, ease of application packaging and reduced start-up times. Moreover, Unikernels reduce the attack surface due to the self-contained environment only enabling low-level features. In this work, we provide an exhaustive description of the unikernel ecosystem; we demonstrate unikernel vulnerabilities and further discuss the security implications of Unikernel-enabled environments through different use-cases.

A rapid rise in cyber-attacks on Cyber Physical Systems (CPS) has been observed in the last decade. It becomes even more concerning that several of these attacks were on critical infrastructures that indeed succeeded and resulted into significant physical and financial damages. Experimental testbeds capable of providing flexible, scalable and interoperable platform for executing various cybersecurity experiments is highly in need by all stakeholders. A container-based SCADA testbed is presented in this work as a potential platform for executing cybersecurity experiments. Through this testbed, a network traffic containing ARP spoofing is generated that represents a Man in the middle (MITM) attack. While doing so, scanning of different systems within the network is performed which represents a reconnaissance attack. The network traffic generated by both ARP spoofing and network scanning are captured and further used for preparing a dataset. The dataset is utilized for training a network classification model through a machine learning algorithm. Performance of the trained model is evaluated through a series of tests where promising results are obtained.

Today, a modern data center hosts a wide variety of applications comprising batch, interactive, machine learning, and streaming applications. In this paper, we factor out the commonalities in a large majority of these applications, into a generic dataflow layer called Common Runtime for Applications (CRA). In parallel, another trend, with containerization technologies (e.g., Docker), has taken a serious hold on cloud-scale data centers, with direct implications on building next generation of data center applications. Container orchestrators (e.g., Kubernetes) have made deployment a lot easy, and they solve many infrastructure level problems, e.g., service discovery, auto-restart, and replication. For best in class performance, there is a need to marry the next generation applications with containerization technologies. To that end, CRA leverages and builds upon the containerization and resource orchestration capabilities of Kubernetes/Docker, and makes it easy to build a wide range of cloud-edge applications on top. To the best of our knowledge, we are the first to present a cloud native runtime for building data center applications. We show the efficiency of CRA through various micro-benchmarking experiments.

Cloud Native, the emerging computing infrastructure has become a new trend for cloud computing, especially after the development of containerization technology such as docker and LXD, and the orchestration system for them like Kubernetes and Swarm. With the growing popularity of Cloud Native, the following problems have been raised: (i) most Cloud Native applications were designed for making full use of the cloud platform, but their file storage has not been completely optimized for adapting it. (ii) the traditional file system is designed as a utility for storing and retrieving files, usually built into the kernel of the operating systems. But when placing it to a large-scale condition, like a network storage server shared by thousands of computing instances, and stores millions of files, it will be slow and even unstable. (iii) most storage solutions use metadata for faster tracking of files, but the metadata itself will take up a lot of space, and the capacity of it is usually limited. If the file system store metadata directly into hard disk without caching, the tracking of massive small files will be a lot slower. (iv) The traditional object storage solution can't provide enough features to make itself more practical on the cloud such as caching and auto replication. This paper proposes a new storage engine based on the well-known Haystack storage engine, optimized in terms of service discovery and Automated fault tolerance, make it more suitable for Cloud Native infrastructure, deployment and applications. We use the object storage model to solve the large and high-frequency file storage needs, offering a simple and unified set of APIs for application to access. We also take advantage of Kubernetes' sophisticated and automated toolchains to make cloud storage easier to deploy, more flexible to scale, and more stable to run.

While the IT industry is embracing the cloud-native technologies, migrating from monolithic architecture to service-oriented architecture is not a trivial process. It involves a lot of dissection and abstraction. The layer of abstraction designed for simplifying the development quickly becomes the barrier of visibility and the source of misconfigurations. The complexity may give microservices a larger attack surface compared to monolithic applications. This talk presents a microservices threat modeling that uncovers the attack vectors hidden in each abstraction layer. Scenarios of security breaches in microservices platforms are discussed, followed by the countermeasures to close these attack vectors. Finally, a decision-making process for architecting secure microservices is presented.

Fog and Edge computing provide a large pool of resources at the edge of the network that may be used for distributed computing. Fog infrastructure heterogeneity also results in complex configuration of distributed applications on computing nodes. Linux containers are a mainstream technique allowing to run packaged applications and micro services. However, running applications on remote hosts owned by third parties is challenging because of untrusted operating systems and hardware maintained by third parties. To meet such challenges, we may leverage trusted execution mechanisms. In this work, we propose a model for distributed computing on Fog infrastructures using Linux containers secured by Intel's Software Guard Extensions (SGX) technology. We implement our model on a Docker and OpenSGX platform. The result is a secure and flexible approach for distributed computing on Fog infrastructures.

The Agave Platform first appeared in 2011 as a pilot project for the iPlant Collaborative [11]. In its first two years, Foundation saw over 40% growth per month, supporting 1000+ clients, 600+ applications, 4 HPC systems at 3 centers across the US. It also gained users outside of plant biology. To better serve the needs of the general open science community, we rewrote Foundation as a scalable, cloud native application and named it the Agave Platform. In this paper we present the Agave Platform, a Science-as-a-Service (ScaaS) platform for reproducible science. We provide a brief history and technical overview of the project, and highlight three case studies leveraging the platform to create synergistic value for their users.

While traditional HPC has and continues to satisfy most workflows, a new generation of researchers has emerged looking for sophisticated, scalable, on-demand, and self-service control of compute infrastructure in a cloud-like environment. Many also seek safe harbors to operate on or store sensitive and/or controlled-access data in a high capacity environment. To cater to these modern users, the Minnesota Supercomputing Institute designed and deployed Stratus, a locally-hosted cloud environment powered by the OpenStack platform, and backed by Ceph storage. The subscription-based service complements existing HPC systems by satisfying the following unmet needs of our users: a) on-demand availability of compute resources; b) long-running jobs (i.e., 30 days); c) container-based computing with Docker; and d) adequate security controls to comply with controlled-access data requirements. This document provides an in-depth look at the design of Stratus with respect to security and compliance with the NIH's controlled-access data policy. Emphasis is placed on lessons learned while integrating OpenStack and Ceph features into a so-called "walled garden", and how those technologies influenced the security design. Many features of Stratus, including tiered secure storage with the introduction of a controlled-access data "cache", fault-tolerant live-migrations, and fully integrated two-factor authentication, depend on recent OpenStack and Ceph features.