What is a container?
Before containers became popular, developers had to focus their energy on application log-ic and application details such as specific software versions and configurations specific to the app. But now, developers need to just focus on application logic.
Containers offer a solution to the problem of how to get software to run reliably when moved from one computing environment to another. This could be from a developer's lap-top to a test environment, from a staging environment into production, and perhaps from a physical machine in a data centre to a virtual machine in a private or public cloud.
Containers allow the developers to build the application along with its associated depend-encies such as (shared libraries, file systems, etc.) in a separate environment in the host OS itself. Unlike VMs, many containers can be run in one guest Operating System.
There are many kinds of containers, Such as Mesos and Swarm But, Docker and Kuber-netes are the most popular ones. More info on Docker and Virtual Machines can be found here
Containers have huge number of benefits but they also have same amount of risks.
Risks in Containers
Vulnerable application code
The life cycle starts with the application code that a developer writes. This code, and the third-party dependencies that it relies on, can include flaws known as vulnerabilities, and there are thousands of published vulnerabilities that an attacker can exploit if they are pre-sent in an application.
The best way to avoid running containers with known vulnerabilities is to scan images, us-ing open source and commercial security tools. This isn’t a one-off activity, because new vulnerabilities are discovered in existing code all the time. The scanning process also needs to identify when containers are running with out-of-date packages that need to be updated for security patches. Some scanners can also identify malware that has been built into an image.
Badly configured container images
Once the code has been written, it gets built into a container image. When the containers are being configured on how it is going to be built, there are plenty of opportunities to in-troduce weaknesses that can later be used to attack the running container. These include configuring the container to run as the root user, giving it more privilege on the host than it really needs.
Build machine attacks
If an attacker can modify or influence the way a container image is built, they could insert malicious code that will subsequently get run in the production environment. When attack-ers find a foothold within the build environment, it will become a stepping stone toward breaching the entire production environment.
Supply chain attacks
Once the container image is built, it gets stored in a registry, and it gets retrieved or “pulled” from the registry at the point where it’s going to be run or deployed. If an attacker can replace an image or modify an image between build and deployment then they have the ability to run arbitrary code on your deployment.
Vulnerable hosts
Containers run on host machines, and care needs to be taken in order to ensure that those hosts are not running vulnerable code (for example, old versions of orchestration compo-nents with known vulnerabilities). It’s a good practice to minimize the amount of software installed on each host to reduce the attack surface, and hosts also need to be configured correctly according to security best practices.
Exposed secrets
Application code often needs credentials, tokens, or passwords in order to communicate with other components in a system. In a containerized deployment, proper security measures have to be taken while passing these secret values into the containerized code.
Insecure networking
Containers generally need to communicate with other containers or with the outside world. Containers have to be setup such that they maintain secure connections between compo-nents and avoid Man in the Middle attacks.
Container escape vulnerabilities
The widely used container runtimes including containerd and CRI-O are by now pretty bat-tle-hardened, but it’s still within the realm of possibility that there are bugs yet to be found that would let malicious code running inside a container escape out onto the host. One such issue, sometimes referred to as Runcescape, came to light as recently as 2019., in which the attackers got out of the container that gave them much broader access to a host and ena-bled them to interact with other containers, and to view and modify configurations.
