Only $35.99/year

Terms in this set (201)

Containerization has become a major trend in software development as an alternative or companion to virtualization. It involves encapsulating or packaging up software code and all its dependencies so that it can run uniformly and consistently on any infrastructure. Containerization allows developers to create and deploy applications faster and more securely. With traditional methods, code is developed in a specific computing environment which, when transferred to a new location, often results in bugs and errors. For example, when a developer transfers code from a desktop computer to a virtual machine (VM) or from a Linux to a Windows operating system. Containerization eliminates this problem by bundling the application code together with the related configuration files, libraries, and dependencies required for it to run. This single package of software or "container" is abstracted away from the host operating system, and hence, it stands alone and becomes portable—able to run across any platform or cloud, free of issues. Containers are often referred to as "lightweight," meaning they share the machine's operating system kernel and do not require the overhead of associating an operating system within each application. Containers are inherently smaller in capacity than a VM and require less start-up time, allowing far more containers to run on the same compute capacity as a single VM. This drives higher server efficiencies and, in turn, reduces server and licensing costs. Put simply, containerization allows applications to be "written once and run anywhere." Containerized applications inherently have a level of security since they can run as isolated processes and can operate independently of other containers. Truly isolated, this could prevent any malicious code from affecting other containers or invading the host system. However, application layers within a container are often shared across containers. In terms of resource efficiency, this is a plus, but it also opens the door to interference and security breaches across containers. The same could be said of the shared Operating System since multiple containers can be associated with the same host Operating System. Security threats to the common Operating System can impact all of the associated containers, and conversely, a container breach can potentially invade the host Operating System. But, what about the container image itself? How can the applications and open source components packaged within a container improve security? Container technology providers, such as Docker, continue to actively address container security challenges. Containerization has taken a "secure-by-default" approach, believing that security should be inherent in the platform and not a separately deployed and configured solution. To this end, the container engine supports all of the default isolation properties inherent in the underlying operating system. Security permissions can be defined to automatically block unwanted components from entering containers or to limit communications with unnecessary resources. For example, Linux Namespaces helps to provide an isolated view of the system to each container; this includes networking, mount points, process IDs, user IDs, inter-process communication, and hostname settings. Namespaces can be used to limit access to any of those resources through processes within each container. Typically, subsystems which do not have Namespace support are not accessible from within a container. Administrators can easily create and manage these "isolation constraints" on each containerized application through a simple user interface.
Containers enable microservices, which increases data traffic and network and access control complexity. Containers rely on a base image, and knowing whether the image comes from a secure or insecure source can be challenging. Images can also contain vulnerabilities that can spread to all containers that use the vulnerable image. Containers have short life spans, so monitoring them, especially during runtime, can be extremely difficult. Another security risk arises from a lack of visibility into an ever-changing container environment. Containers, unlike VMs, are not necessarily isolated from one another. A single compromised container can lead to other containers being compromised. Containerized environments have many more components than traditional VMs, including the Kubernetes orchestrator that poses its own set of security challenges. Can you tell which deployments or clusters are affected by a high-severity vulnerability? Are any exposed to the Internet? What's the blast radius if a given vulnerability is exploited? Is the container running in production or a dev/test environment? Container configuration is yet another area that poses security risks. Are containers running with heightened privileges when they should not? Are images launching unnecessary services that increase the attack surface? Are secrets stored in images? As one of the biggest security drivers, compliance can be a particular challenge given the fast-moving nature of container environments. Many of the traditional components that helped demonstrate compliance, such as firewall rules, take a very different form in a container environment.