Community-driven DevSecOps

Combining the operator pattern and devsecops
with open source community processes

Hardened open source operators

The Open Operator Collection community brings ‘many eyes’ to devsecops. Shared, open source operators represent best practice both for operations and for security, greatly increasing quality and reducing the cost of high-security, compliant operations for all end users of the operator collection.

What is DevSecOps?

DevSecOps means integrating the expertise of security specialists into the DevOps process.

The shift to agile development, continuous integration and continuous deployment drove the rise of devops, combining development and production operations expertise into agile teams. Devops meant that development teams also had to understand the production consequences of their work, taking responsibility for performance, upgrades, and reliability.

Devsecops extends this principle to recognise the importance of security. Since devops means faster deployments, there are fewer opportunities to review security before code is deployed to production. Instead of trying to address security after the fact, Devsecops brings the security expertise into the devops team and makes security the responsibility of the combined group.

Security becomes a shared responsibility, tightly integrated into the devops process. Security design, security reviews, and security responses all take place in the arena of continuous integration, testing and deployment. Automation of security monitoring and analysis is crucial, since there will be fewer opportunities for lengthy analysis of static systems in production given the fast pace of change inherent to continuous deployment.

Containerized operations require devsecops

A central shared repository of operators creates the opportunity for security reviews at a community level, bringing specialist perspectives which would not be available to every project in every organisation.

The benefits of an open source approach are well understood; expertise is pooled, costs are reduced, security fixes are provided faster. These same benefits apply to operators which are of course software packages, even though their purpose is to drive operations.

Reuse drives quality

A key benefit of the operator pattern is the ability to reuse operations logic. Reuse of code drives quality. When ops code is reused in more scenarios, it reflects more experience and insights. In the ideal case, an operator is used across many organisations and many clouds so that the cost of implementation is shared across multiple parties, reducing the cost to each individual user.

The Open Operator Collection is a community-driven approach to operator design and development. The collection is a portfolio of consistent operators, developed by vendors, open source leaders, and expert contributors. The goal is to bring diverse experience to reusable operations code for software components that are very widely shared.

Shared apps, shared operators, shared security

A central shared repository of operators creates the opportunity for security reviews at a community level, bringing specialist perspectives which would not be available to every project in every organisation.

The benefits of an open source approach are well understood; expertise is pooled, costs are reduced, security fixes are provided faster. These same benefits apply to operators which are of course software packages, even though their purpose is to drive operations.

Open source operators get more reviews

When an operator is developed as proprietary code inside an organisation, the only code reviews of that operator will be done in the team responsible. Open source operators have many more opportunities for inspection and analysis, which increase the likelihood of identifying problems and generating solutions.

The Open Operator Manifesto, which shapes the work of the Open Operator Collection Community, requires source code for all operators to be available for such review.

Specialist expertise is shared

Security in particular is a subtle and challenging discipline. For every system in production there are many attack vectors that require different experience to analyse and address. This experience is both rare and expensive.

A good software architecture applies defense-in-depth to mitigate the consequences of a security lapse in one part of the system, but it remains the case that a single mistake can undo all of the good work of many in providing an adversary with an entrypoint to integrated systems. Unlike performance or reliability in software, simply addressing the top priority issue does not fundamentally secure a system when there are many lower-priority problems; it is necessary to close all the gaps, and quickly, to be confident in the integrity of a production system.

A community can draw upon specialist perspectives to harden the entire stack for the benefit of all its members and users. From kernel configuration to MAC-based security policies, from cryptography and key management to network security, an open source operator is more likely to reflect the state of the art than any single-vendor effort.

Importantly, open source provides a level playing field for large and small organisations alike, both of which bring benefits to the community.

Rapid distribution of security fixes

Security issues are not fixed when a patch is available, they are fixed when the patch is in production.

A critical characteristic of software delivery frameworks is the speed with which fixes move from being available to being in production. Many popular distribution mechanisms for software have a poor track record of delivering fixes to production. Security research firm Snyk found systematic security problems in Helm charts for example.

The Juju operator lifecycle manager provides an efficient update distribution system. Progressive releases minimise the risk of a widespread update-related problem and increase user confidence in automated updates. As a result, many users choose to apply updates automatically, enhancing the security posture of the entire ecosystem.

CVEs for operators

It is important for institutions to audit and report on their systems security standing. The global security community relies on CVEs as a framework for tracking systematic issues in shared applications.

The Open Operator Collection extends this to operator code. Security vulnerabilities in operators are treated with the same process of disclosure and fix distribution as vendor applications and solutions.

In addition, because operators drive workload updates and upgrades, it becomes possible in principle to have operators provide the audit function, enabling a consistent view of CVE coverage in a complex containerised estate.

Compliance

Ensuring compliance is essential for large organisations, but difficult in a fast-moving devops world. Regulated entities face a growing list of hard requirements - FIPS, HIPAA, CIS. These specify precise requirements for machine and container behaviour, and carry significant penalties if not met.

Every organisation also has to meet internal standards for infrastructure and apps. When an application is being deployed widely off custom ops code, it is extremely difficult to ensure that every deployment meets expectations. Checklists and manuals depend on fallible human judgment.

Operators greatly improve compliance consistency, audit and remediation.

Since an operator contains all the logic of service instantiation, upgrade, integration and configuration, it can enforce compliance consistency. The Juju OLM allows placement of operators on specific machines, or all machines in the model, to enforce compliance with infrastructure standards such as CIS or FIPS.

Juju’s unique ability to compose operators efficiently means that investments in compliance for a particular operator are returned in every single application graph where that operator is used. Rather than develop overly complex operators for entire scenarios, composition gets the benefits of focus, simplicity and reuse at the level of individual software components.

Audit is improved because the Juju OLM supports actions on operators; reporting on specific compliance is thus codified in operator actions and can be invoked wherever a particular workload is deployed.

Remediation takes place through the standard process of operator updates; since operators are distributed through a reliable global distribution infrastructure, improvements flow quickly to production systems with appropriate enterprise control.