Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Security Landscape for Containerized Apps

DZone 's Guide to

Security Landscape for Containerized Apps

Keep it safe, keep everything contained.

· Security Zone ·
Free Resource

multicolored-shipping-containers-stacked-on-top-of-one-another

Securing your containerized applications

The security landscape is changing fast with new architectures and platforms emerging every day. This article attempts to explore some of the aspects of end-to-end security while building containerized applications. 

You may also like: Three Keys to Speed and Security in the DevOps Era.

Security First Approach

With more and more organizations moving to the cloud, security is gaining paramount importance and a security-first approach has to be embedded into the DNA of organizations; security should be treated as a first-class citizen, rather than being an afterthought.

This will involve embedding security in each and every aspect of software engineering, right from the design phase and later on into development, testing phases. We have often seen that if Security is not considered in the design/architecture phase, the cost of securing the system later on increases significantly, often leading to resistance from various stakeholders. Security should be integrated with the Devops culture as well to maximize benefits and minimize overhead.

Modern security landscape

Modern security landscape

Where

Let us take a look at different resources where we need to apply security while building an application. We are looking at a containerized application environment.

On a general note, from a resource perspective, we can categorize the resources as shown below:

  1. Host Machine — Virtual machines or compute instances.

  2. Container — Containers that run various workloads.

  3. Application/Services — Includes homegrown or commercial applications, microservices, or web interfaces.

  4. Network — Network layer that enables communication between resources.

Threats and Detection

The various security threats (not limited to) at each resource layer are shown in the above diagram, with techniques to detect each of them.

Most of the detection involves some kind of scanning and testing. There could be multiple levels of scanning, for example, when we say source code scanning, it might include scanning the actual source code as well as the third-party libraries included, if any.

Similarly, testing techniques might include dynamic testing of web interfaces and endpoints to ensure relevant attacks could not be carried out on these.

Unauthorized access is a very common means of gaining unrestricted entry into a system and causing havoc. This will be applicable at various levels, including host machines, applications, etc.

Sniffing and Man in the Middle attacks are common techniques of network attacks and could result in compromising the data sent across a network.

Security and Automation

With more and more organizations adopting Agile and DevOps methodologies, with shorter release cycles and higher deployment frequencies, we need to ensure that security is not compromised, and at the same time, make sure security does not become a bottleneck.

This is where automation comes into play!

Security threat detection and remediation could be automated using a wide array of tools that help in detecting, finding threats and subsequent corrective action. Automated action could be corrective or preventive. For instance, preventive actions might include one of the below:

  1. Stopping or shutting down resources that are not secure.

  2. Blocking insecure access and paths.

  3. Breaking continuous integration builds which fail the security test.

The threats and detection techniques shown above only scratch the surface. However, the idea is to provide an overview of what is involved and what does it take to integrate Security into the application lifecycle.


Related Articles

Topics:
security ,devops ,containers

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}