Linux and Cloud Native Security: Canonical Ubuntu
Rob Gibbon, product manager for managed applications at Canonical
Canonical’s Ubuntu remains one of the most widely-used Linux distributions, especially for cloud-based operations. But how does it manage the security of containers, Kubernetes and other cloud native operations? We asked Rob Gibbon, product manager for managed applications at Canonical, to discuss Ubuntu and cloud native security.
What’s the biggest security issue cloud native developers face?
Kubernetes can be complex, and Kubernetes security even more so. [The latest release] Kubernetes 1.22 adopts seccomp mandatory access controls as a powerful tool to help reduce the attack surface area. As Cloud Native Computing Foundation– certified Kubernetes distributions, MicroK8s and Charmed Kubernetes give our users the option to try out this new capability.
Additionally, cloud native developers are facing a crisis in content provenance. Lots of valuable resources are available to developers, however, knowing which to use or not to use represents an unprecedented security challenge for cloud developers.
Whether it’s for OCI (Open Container Initiative) images on Docker Hub and elsewhere, Python packages on PyPI, node packages on npm, etc. It’s important to continually consider what content can developers rely on and for how long? Is it of good quality? Does it contain security issues or worse, malicious malware code?
If you could give one piece of advice to businesses wanting to deploy containers as securely as possible, what would that be?
Adopting a layered security model is key, and not relying on just a single protection measure. However, without a comprehensive monitoring solution, you may be unaware that your service has been compromised, and to what extent, until long after the fact.
The best practice an enterprise can enforce to deploy containers as securely as possible is to rely on fully automated pipelines with restricted and trusted inputs. Don’t rely on manual actions; automate updates. You should systematically approve anything allowed to enter your pipelines, and you should know who is behind it too.
I am looking forward to a world where creating a Dockerfile is seen as a low-level solution for very specialized use cases, like the assembly level programming for containers.
Preferably one selected, trusted and recognized vendor will be able to provide quick commercial support. With that in mind, you should apply the zero trust security principle. And limit dependencies to their strict minimum, implement cryptographic validation of third-party content, and add vulnerability and malware scanning as part of your secure CI/CD pipelines.
As a shortcut, I would advise enterprises to think and pick a secure and stable base image carefully. Among all the available base images backed by commercial support, I would look at two additional criteria to make my decision:
- Does it come with a large software ecosystem, or will you need to pull from untrusted sources regularly?
- Is it developer-friendly, or does it add toil to your developers? Hard-to-use software will often lead to your developers not using it properly and creating even worse unnoticed security breaches.
What is Canonical doing for cloud/container security?
For container security, Canonical launched a program to provide hardened application container images with up to 10-year guaranteed security updates. This great timeline is unique and shows our security expertise from years of OS security maintenance and supporting highly demanding companies in complex sectors. Our recent juju.is survey has shown that cloud native developers’ first concern when selecting a container image is stability. With up to 10 years of commercial maintenance on some pinned long-term support [LTS] versions, you should be covered!
Another kind of container to consider in edge computing and IoT use cases is Snaps on Ubuntu Core. I invite you to look it up and learn more about this exciting project. It’s a first of a kind and has the potential to change the IoT security landscape.
What’s the future of cloud native development look like?
This question needs two answers, one in terms of how to package software in a container, and the other about the architecture of cloud native applications.
The practice of building containers is going to discover the magic of cloud native buildpacks. Borrowing from the best platform-as-a-service offerings of the previous generation, cloud native buildpacks give you a way to effortlessly create hardened, optimized, safe containers for your code.
I am looking forward to a world where creating a Dockerfile is seen as a low-level solution for very specialized use cases, like the assembly level programming for containers, as opposed to the mainstream way it is today. Curated, minimal runtimes supported by trusted vendors will provide the security and stability still missing today for production deployments. In terms of architecture, the short- and middle-term future of cloud native development is going to be about composability and consolidation.
Kubernetes is the de facto cloud native container orchestration, but leaves a lot of important aspects of running complex applications to its users, like handling certificates or selecting and setting up ingresses. There is a wide and continuously growing variety of components to use to fill these gaps, with no clear winner yet, and the ecosystem will seek to mature, consolidate and stabilize.
In the long run, we are going to see higher-level abstractions like function as a service achieving wider adoption as mature solutions reduce the cost of development and operations for teams. What we will also see, at the same time, is a resurgence of somewhat less-distributed architectures: not quite the monoliths of “old” (roughly pre-2015), but less distributed than now, as means of reducing the inherent complexity in sprawls of interconnected microservices and the operational hardships that come with it. It will still fit snugly in containers, but your average “state of the art” cloud native app will have fewer moving parts. All in all, what end users want is really a comprehensive, easy-to-use, reliable platform as a service with good support for components of different sizes, from single functions to “moduliths,” and good compatibility with applications shipped before containers were a thing.
As the saying goes, “everybody is reinventing Heroku”: the culmination of the “Kubernetes generation” is going to be a set of mature, turnkey PaaSes composed of best-of-breed solutions.
What’s the first thing an administrator should do to a server operating system to harden it?
Canonical now offers Ubuntu Pro, a premium version of Ubuntu that comes with additional support and service capabilities, including automated CIS Benchmark hardening, Kernel Livepatch and extended security maintenance. Enabling Ubuntu Pro is fast and easy.
Also, hardening is a site, system, and workload-specific process that ties to the organization’s needs and the cybersecurity framework followed. There are industry as well as workload-specific hardening profiles that can assist the administrators in that task. Examples of widely accepted hardening profiles are the DISA Secure Technical Implementation Guide and the CIS Benchmark.
How can small to medium-sized businesses gain the levels of security found in the enterprise?
Canonical offers Ubuntu at no cost, with up to five years of free security updates. And that applies to everyone, regardless of their scale. But for developers and Ubuntu members, Canonical offers extended support for up to 50 Ubuntu systems for free, and that includes Kernel Livepatch.
Navigating the cybersecurity space may seem like a luxury or too intimidating for small to medium-sized organizations; there are many cybersecurity frameworks to choose from, and benefits may not be immediately visible before a breach is experienced. Customer private data, customer databases, as well as business credibility, are things that organizations value, though not always taking the necessary precautions to safeguard them.
Frameworks, such as the NIST cybersecurity framework, CIS controls, PCI-DSS, SOC2, ISO27000 to list a few, are available to guide an organization’s cybersecurity plan implementation, while paradigms like zero-trust security set the right mentality and end goals.
Ultimately, most frameworks define cybersecurity controls and best practices to enable businesses to reduce operational and business risks. At the same time, taking the first steps on that path and implementing basic security controls such as continuous vulnerability patching, enabling malware defenses and secure configuration will take an organization a long way toward reducing the risk of security incidents or breaches.
What’s the best thing container developers can do to ensure they’re building off a solid and secure foundation?
Canonical offers a freely available collection of Ubuntu-based LTS container images for open source applications. Starting from this portfolio is an excellent way for developers to ensure trusted provenance of their containers while benefiting from the familiarity and range of the Ubuntu software ecosystem. Commercial tracks are available to enterprises with up to 10-year security updates and access to Canonical experts.
And of course, follow security best practices and ensure all bundled software and dependencies come with provenance and are up to date. Getting the latest and greatest software dependencies helps to create prototypes quickly, but when going into productization, the software must be free of known vulnerabilities and must be kept up to date to prevent a breach.
Furthermore, ensure that software updates come at a pace that matches the development pace and take advantage of the container technology capabilities. That is, make sure that containers are refreshed with the latest security patches often, reducing the window of opportunity caused by new vulnerabilities, and that the hard-to-move software parts such as the kernel, are updated using technologies like kernel live patching that reduce unplanned downtime.
From your perspective, what’s the answer to supply chain insecurity?
The Zero Trust Security paradigm can offer some support here. There is no such thing as a secure system, nor trusted software. Supply chain vulnerabilities exist. The CTO’s goal should therefore be to minimize the damage inflicted when the inevitable eventually happens.
With Kernel Livepatch, Snapd, Common Criteria, FIPS-140, and CIS Benchmark profiles for Ubuntu, as well as our next-generation device OS Ubuntu Core, Canonical provides tooling to support comprehensive zero trust computing implementations.
Beyond the headlines, the supply chain problem is a complex one and varies depending on one’s role. In software, there are several parallels with the hardware supply chains, but the cost of a malicious modification is significantly lower.
At the same time, we should not ignore the fact that most organizations have a much more basic problem. Organizations are not generally proactive and consistent in vulnerability patching. Security maintenance is part of operations and procurement, and more important for working with vendors that are transparent and provide products with security maintenance throughout the product life cycle.
Should businesses be striving for full-blown automation, or should they keep a layer of human intervention involved in the DevOps process?
Canonical believes in the model-driven operations paradigm. We are building Juju, our operator framework, and the Charmed Operator collection to dramatically simplify the level of human intervention necessary in DevOps, DataOps, and SecOps workflows. Dealing with low-level plumbing, firefighting and mundanity is just not fun; hyper-automation through model-driven operations frees teams to spend more time in flow state working on the productive things that they enjoy.
