Cloud native architecture for enterprises

Adoption of Cloud Native Architecture by enterprises is a key technology trend, according to Gartner, and Oracle SaaS customers are no exception to this trend. Cloud native architecture brings several benefits to the table, such as rapid scalability, time-to-market, and cost reduction, compared to traditional monolithic applications and hosting infrastructures. Here is a quick look at some potential Cloud Native use cases for Oracle’s customers.

Cloud native extensions and integrations to SaaS applications are among these use cases. Please check content I presented in Oracle CloudWorld 2022 for a closer look at Cloud Native Architecture. Before proceeding further, let’s glance at the 4 attributes of Cloud Native architecture in the graphic below.  

As shown, containers are at the heart of cloud native architecture. Containers offer important benefits such as extensibility, portability, and predictability in runtime. The focus of rest of the blog is about securing containers on OCI.

Securing containers is much easier with an understanding of the attack surface for cloud native applications. There are 3 groups of activities that constitute an attack surface, in my view, as shown in graphic below. Securing code and repositories, securing registries are the focus of this blog. Securing the runtime is a larger topic. Please refer to my blog on OCI security for SaaS extensions, for more information.

A discussion securing containers makes references to DevSecOps inevitable. DevSecOps is a set of practices to introduce security much earlier into the Software Development Life Cycle. It’s conjoined with DevOps and DevOps CI and CD pipelines provide the opportunities to insert security check points to apply DevSecOps practices. The graphic below shows the opportunities for mitigation of the attack surface that we saw earlier, along the phases of a DevOps cycle, using DevSecOps. OCI DevOps is a service fit for this purpose.

With this foundational understanding, let’s dive into the best practices to secure container.

Securing code

Before an application is built into a container, it is prudent to ensure that the code is secure. This will cut down the number of CD cycles triggered by security vulnerabilities. Here are important and complementing techniques to secure code, aside from obvious steps such as securing a code repository such as git.

Threat modeling

This is an exercise, carried out even before the application is completely built, but after the architecture is clear, where the external threats are modeled based on architecture, then simulated and mitigation approaches are identified.

Static Analysis Security Testing (SAST)

This is a screening of code for deviation from secure coding best practices, often performed by tools, both open sourced and licensed by vendors. SonarCube is an example for SAST tool. This practice minimizes the number of issues discovered in rest of the SDLC and it’s economic to mitigate issues at this stage than further down.

Software Composition Analysis (SCA)

This practice helps you identify the bill of materials (BOM), especially the opensource libraries and other libraries. Knowing the BOM for an application helps easily identify threats during development and to assess threats on an ongoing basis. There are tools to aid such an analysis.

Dynamic Application Security Testing (DAST)

Once the code is built and ready for execution, DAST comes into play. This is a black box approach to penetration testing on the application in runtime. OWASP ZAP proxy is an example for such a tool.

OCI Application Dependency Management (ADM)

OCI ADM can be integrated with OCI DevOps to scan applications that use maven to build. It uses the Common Vulnerability Scoring System (CVSS) to assess the overall impact and Common Vulnerabilities and Exposures (CVE) database to identify vulnerabilities and exposures. ADM produces vulnerability audits by scanning OCI DevOps repositories and creates Vulnerability audit reports. The finds of the audit can be monitored on OCI CloudGuard as well. Refer to ADM documentation for more information.

Securing containers

Once the code is ready for being packaged into a container image, here some additional best practices that come into play.

General best practices

• Pick base images for docker build from trusted sources.
• Include USER instruction in docker builds. Otherwise, the application will run as root.
• Do not store credentials in the clear such as passwords or private keys in an image.
• Once these practices are applied build a trusted base image, upon which microservices can build their own images.

Minimize image size

A lot can be achieved in securing a container by just minimizing the size of a container image. The smaller image means a smaller attack surface! A smaller image also reduces container load times. Here are some ways to reduce the image size.

• Pick “slim” base images from trusted sources.
• No debuggers, compilers, shells, or network utilities (last 2 are very important!).
• Use tools such as docker-slim to minify images.

Secure the images and registry on OCI

Once microservices are packaged and built into an image, it is time for additional best practices around container images.  

• Scan images regularly and sign them for downstream consumption. Signing establishes trust in chain of custody.
• Collect metrics from the scans and identify patterns of CVEs detected, such as which images fail and why.
• Use image labeling rigorously. For example, labeling can be used to mark images as safe or suitable for production.
• Secure the registry and enforce role-based access. For example, a deployer need not access to create an image. A developer need not have access to create a production-ready image.

OCI Container image scanning service

This service integrates with OCI container registry scan images and produce a report with CVEs detected during the scan. The service is free for paying customers and must be enabled for each container registry.

• Checks for CVEs in NIST database
• All images pushed into the repository are scanned
• Any new CVE added also triggers a new scan of all images.

Refer to documentation for more information.

Securing container hosts

Here are some best practices to follow to secure hosts of containers.

• Use immutable infrastructure through automation with tools such as terraform. This reduces human errors caused by manual provisioning and configuration drift through changes to host configuration.
• Use NIST and CIS hardening benchmarks
• Avoid mounting host file system inside containers.
• Fortify network where hosts are provisioned.

OCI vulnerability scanning service can scan hosts in a compartment and identify CVEs. It scans for:

• open ports, OS packages & OS configurations
• Center for Internet Security (CIS) benchmarks
• Section 5 benchmarks for Distribution Independent Linux
• 3rd party libraries such as log4j and spring4shell

Conclusion

In this post, we highlighted Cloud native architecture’s potential for enterprise applications and learned about the attack surface of this architecture.  The techniques to minimize the attack surface for code, container and hosts followed, and, along the way, the relevant OCI services and their features were referenced. I hope the post provides a sufficient high-level understanding to apply the best practices to your cloud native projects.