On Stranger Tides: API and Container Security Part I

This is part 1 of a multi-part series I'm publishing on how breaches occur in service oriented architectures (SOAs), application programming interfaces (APIs), and containers and how to build resiliency against them. In this first part, I'll explain what SOAs and containers are and then in part 2, we'll demystify APIs, API breaches and how to secure against them, and in the final part, we'll discuss container breaches and how to secure them.

Rise of Microservices

In the beginning there were monoliths. These were applications designed as a self-contained, single-tiered software application where the UI and data access layers were combined into a single program. 

Monoliths carry out tasks completely on their own from end-to-end made up of two components or layers: the user interface, which is the entry point of the application for the user, often called the UI or the graphical user interface (GUI) and the data layer, which is a wrapper to the data store (or database) -- sanitizing the data before its persisted to the data store.

Monoliths are designed for traditional server-side systems; an entire system based on a single application and are designed with performance and speed in mind. Monoliths typically run faster because they don’t communicate with different parts of itself over APIs and are perfectly suited for small, single function apps.

For example, a monolith might be an application that performs different functions, from authentication to reads and writes to a database, posts, may contain a permission structure and workflow approval, and runs on the same server using the same file system.

Monoliths are often described as being akin to having too many chefs in the kitchen with their hands in a single pot, each trying to add their own ingredients that may conflict with or ruin the whole or parts of the dish that other chefs may be working on.

It's important to note that Monoliths aren’t dead. Whether or not a developer chooses to write their application as a monolith or broken into microservices depends on the application,

On the contrary, microservices are designed with modularity, supporting the reuse of application parts and facilitating maintenance of different parts of the application by enabling repair or replacement of parts without requiring a wholesale rebuild or replacement of the entirety of the app. 

The rise of microservices ushered in a new concept of a service-oriented architecture (SOA), where the server architecture is compromised of multiple applications that all represent individual features of the same application. For example, the authentication, database, posts, permission structures, and workflow approvals are all separate applications that communicate with each other over APIs from their own container, such as Docker, and each may run on a different OS.