Security

Learn how to mitigate container security issues

As companies continue migrating to the cloud, they’re increasingly embracing cloud-native technologies, including containers. Containers provide organizations a way to run multiple applications on the same device without worrying about compatibility with the rest of the computing environment. Containers also isolate applications from the rest of the system, adding a layer of security. Moreover, containers can be a great segmentation tool to protect data — a major benefit given the number of employees working outside the traditional perimeter today.

However, despite their benefits, containers introduce a number of security issues. Enterprises need to be careful when implementing containers, namely by fixing known vulnerabilities and addressing container escape vulnerabilities to prevent bad actors from accessing other containers.

In Container Security: Fundamental Technology Concepts that Protect Containerized Applications, author Liz Rice, chief open source officer at Isovalent, explains how DevOps, security and operations teams can ensure containers and images remain secure, as well as how to approach protecting them.

In this excerpt from Chapter 1, Rice lays the groundwork for tackling container security issues and offers a threat model from which all decisions around securing containers should start.

In the last few years, the use of containers has exploded. The concepts around containers existed for several years before Docker, but most observers agree that it was Docker’s easy-to-use command-line tools that started to popularize containers among the developer community from its launch in 2013.

Containers bring many advantages: as described in Docker’s original tagline, they allow you to “build once, run anywhere.” They do this by bundling together an application and all its dependencies and isolating the application from the rest of the machine it’s running on. The containerized application has everything it needs, and itis easy to package up as a container image that will run the same on my laptop and yours, or in a server in a data center.

A knock-on effect of this isolation is that you can run multiple different containers side by side without them interfering with each other. Before containers, you could easily end up with a dependency nightmare where two applications required different versions of the same packages. The easiest solution to this problem was simply to run the applications on separate machines. With containers, the dependencies are isolated from each other so it becomes straightforward to run multiple apps on the same server. People quickly realized that they could take advantage of containerization to run multiple applications on the same host (whether it’s a virtual machine or a bare-metal server) without having to worry about dependencies.

The next logical step was to spread containerized applications across a cluster of servers. Orchestrators such as Kubernetes automate this process so that you no longer have to manually install an app on a particular machine; you tell the orchestrator what containers you want to run, and it finds a suitable location for each one.

From a security perspective, many things are the same in a containerized environment as they are in a traditional deployment. There are attackers out in the world who want to steal data, or modify the way a system behaves, or use other people’s compute resources to mine their own cryptocurrencies. This doesn’t change when you move to containers. However, containers do change a lot about the way that applications run, and there are a different set of risks as a result.


Risks, Threats, and Mitigations

A risk is a potential problem, and the effects of that problem if it were to occur.

A threat is a path to that risk occurring.

A mitigation is a countermeasure against a threat — something you can do to prevent the threat or at least reduce the likelihood of its success.

For example, there is a risk that someone could steal your car keys from your house and thus drive off in your car. The threats would be the different ways they might steal the keys: breaking a window to reach in and pick them up; putting a fishing rod through your letter box; knocking on your door and distracting you while an accomplice slips in quickly to grab the keys. A mitigation for all these threats might be to keep your car keys out of sight.

Risks vary greatly from one organization to another. For a bank holding money on behalf of customers, the biggest risk is almost certainly that money being stolen. An ecommerce organization will worry about the risks of fraudulent transactions. An individual running a personal blog site might fear someone breaking in to impersonate them and post inappropriate comments. Because privacy regulations differ between nations, the risk of leaking customers’ personal data varies with geography—in many countries the risk is “only” reputational, while in Europe the General Data Protection Regulation (GDPR) allows for fines of up to 4% of a company’s total revenue.

Because the risks vary greatly, the relative importance of different threats will also vary, as will the appropriate set of mitigations. A risk management framework is a process for thinking about risks in a systematic way, enumerating the possible threats, prioritizing their importance, and defining an approach to mitigation.

Threat modeling is a process of identifying and enumerating the potential threats to a system. By systematically looking at the system’s components and the possible modes of attack, a threat model can help you identify where your system is most vulnerable to attack.

There is no single comprehensive threat model, as it depends on your risks, your particular environment, your organization, and the applications you’re running, but it is possible to list some potential threats that are common to most, if not all, container deployments.

Container Threat Model

One way to start thinking about the threat model is to consider the actors involved. These might include:

  • External attackers attempting to access a deployment from outside
  • Internal attackers who have managed to access some part of the deployment
  • Malicious internal actors such as developers and administrators who have some level of privilege to access the deployment
  • Inadvertent internal actors who may accidentally cause problems
  • Application processes that, while not sentient beings intending to compromise your system, might have programmatic access to the system

Each actor has a certain set of permissions that you need to consider:

  • What access do they have through credentials? For example, do they have access to user accounts on the host machines your deployment is running on?
  • What permissions do they have on the system? In Kubernetes, this could refer to the role-based access control settings for each user, as well as anonymous users.
  • What network access do they have? For example, which parts of the system are included within a Virtual Private Cloud (VPC)?

There are several possible routes to attacking a containerized deployment, and one way to map them is to think of the potential attack vectors at each stage of a container’s life cycle. These are summarized in Figure 1-1.

container security deployment diagram
Figure 1-1. Container attack vectors

Source link

Tags

About the author

GG

Add Comment

Click here to post a comment

Your email address will not be published. Required fields are marked *

Gadget Greed