Hygiene is universal: Five “hygienic” security practices that matter for cloud-native applications

By now, you’ve likely heard about Linux containers – if not from your IT or developer teams, then from the many analysts, journalists and other influencers watching the enterprise technology world. Linux containers allow applications to be packaged with only their core dependencies, simplifying development and maintenance and streamlining the overall application lifecycle.

Collectively, containerised applications are often referred to as “cloud-native,” meaning that they are built for next-generation infrastructure, like cloud-based architectures, instead of traditional monolithic stacks. Given the fact that cloud-native applications seem to turn the traditional application paradigm on its head with different and faster development times as well as new infrastructure requirements, it would be easy to think that these new applications have new requirements for cybersecurity.

That would be largely wrong.

Of course, there are some specific technical controls that need to be applied, as with any new technology, but despite the new, shiny wrapper, cloud-native applications are just another workload – they need to be managed, maintained and, most importantly, secured like any other application existing within your datacenter. This means that many of the basic security hygiene requirements of traditional applications still apply: in fact, they are arguably even more important as you roll out applications at scale. Here are five practices that are of utmost importance when it comes to securing cloud-native applications.

Trusted images only
Traditional security practices start with controlling the software deployed on your systems – this means only using software for which you know the origin and provenance. Whether it’s an employee downloading suspiciously free tools from an FTP site or including unknown packages in your production application, software content governance helps to limit the vulnerabilities and exploits faced by your organisation.

This same principle impacts cloud-native applications. While container images are prolific across the Internet, an untrusted image presents a risk similar to that of opening a random email attachment or plugging in a found USB device. IT teams should only be leveraging container images from trusted sources, preferably ones that can verify the contents of a container; going off-course provides a clear opening to an otherwise well-controlled software stack.

Patching = Rebuilding
Patching isn’t new – it’s a common activity (or painpoint) for IT teams today and is vital in keeping a datacenter secure. When working with cloud-native applications, however, you need to take a new approach to patching. Containers aren’t patched — instead, they are “rebuilt,” where the old container is taken down and a new container with the exact same characteristics, minus the patched-out vulnerability, takes its place.

This might seem onerous, but given the ease with which containers can be created and deployed, it simply becomes part of the standard workflow. Additionally, patching a running container can compromise the build process of your IT team – a container patch could have unforeseen ramifications and, given the scale at which most cloud-native applications operate, these issues could have wide-ranging, negative connotations for your operations. Finally, rebuilding instead of patching-in-place improves security as it keeps access to production systems more tightly-controlled.

Encrypt everything
IT departments are well-versed in encrypting passwords and confidential customer data to protect against misuse or theft and the use of containers certainly does not change that requirement. In fact, the dynamic nature of container deployment and use within a multi-tenant cloud increase the need for encryption of data at rest and in-flight.

Container login credentials, application passwords and configuration data are used by orchestration software regularly and must be stored in an encrypted manner. Think of this as storing encrypted passwords on a non-container system; no administrator would leave their passwords in the clear.

The dynamic nature of container deployment can make network encryption more difficult, but that doesn’t mean administrators are without a solution. Several solutions exist that allow for a default encrypted mesh to be established to protect container-to-container communication to protect data in-flight.

One role, one container
Roles are critical for applications, both traditional and cloud-native, and clearly-defined roles can ultimately help make your operations more secure. In a traditional software stack, a database application filled with sensitive customer data should not, for example, be interacting with an external networking application. This provides a potential breach window and could ultimately expose critical data to malicious actors.

These types of roles and structured interactions are also critical for cloud-native applications. Containers serving a database function should have much more limited scope and interactions than containerised applications that are in a networking or messaging function, and all of these applications should be monitored constantly to ensure that they are performing their intended function without any odd behaviors. Fortunately, container orchestration software with embedded software defined networking (SDN) can make it much easier to isolate the points of interaction (i.e. network exposure) among containers.

Lock and key
The final principle of security hygiene to consider for cloud-native applications is that of access control. In an IT organisation, typically only specific developer or operations teams are able to work with certain applications, both at the build stage and for deployment. This keeps teams focused on their own activities and helps limit the spread of potential human errors across a stack.

Cloud-native applications benefit just as much, if not more so, from access controls. Most containerised applications are cluster-based, meaning that there are likely to be many applications residing on a single node. Ensuring that developer teams have access only to the appropriate applications helps to limit data leakage and it makes it easier to track the origin of potential issues.

Effective IT security measures should not be abandoned just because something new and shiny comes along. In the case of cloud-native applications, practicing basic security hygiene, from patching to access control, can help not only keep your organisation’s systems and network secure, but it will also enable you get the most out of an exciting new technology while limiting some of the inevitable adoption pains. You may even find that some container deployment best practices (e.g. never patch in place) can improve your security posture.

Send your email to