TNS
VOXPOP
How has the recent turmoil within the OpenAI offices changed your plans to use GPT in a business process or product in 2024?
Increased uncertainty means we are more likely to evaluate alternative AI chatbots and LLMs.
0%
No change in plans, though we will keep an eye on the situation.
0%
With Sam Altman back in charge, we are more likely to go all-in with GPT and LLMs.
0%
What recent turmoil?
0%
Cloud Native Ecosystem / Kubernetes / Security

CNCF’s Special Interest Group for Security

Dec 1st, 2020 3:00am by
Featued image for: CNCF’s Special Interest Group for Security

Honeycomb is sponsoring The New Stack’s coverage of Kubecon+CloudNativeCon North America 2020.

Ever wonder about the state of security of cloud native computing projects? You should. As anyone who’d ever tried to secure Kubernetes knows it’s not easy. Security is an eternal struggle to defend systems and reduce risk, but with cloud native computing’s fast-changing and complex interrelationships, there are no simple, cookie-cutter answers. Trying to make sense of it all is where the Cloud Native Computing Foundation’s (CNCF) Special Interest Group (SIG) Security comes in.

At the 2020 North American KubeCon, Brandon Lum, an IBM senior software engineer and Emily Fox, the U.S. National Security Agency (NSA) DevOps Security Lead, explained what the CNCF SIG does, what its goals are, and where it’s going. Wait, what’s that you say? Isn’t the NSA all about breaking code and security? Actually, that’s only half its job, the other half is locking down and securing systems.

The SIG’s eventual goal is to give operators, administrators, and developers an ecosystem of tools they need to create cloud native applications. These tools will also give them a clear understanding of risks and the ability to validate their security policy decisions. To do this will require:

  1. System security architecture that understands and accommodates the ever-growing heterogeneity of systems and provides a framework to protect resources and data while servicing their users
  2. Common vocabulary and open source libraries that make it easy for developers to create and deploy apps that meet system security requirements
  3. Common libraries and protocols that enable people to reason about the security of the system, such as auditing and explainability features.

This is not easy. This is anything but easy. And, Fox and Lum know this.

To accomplish these goals, Fox said they need more developers. Fox added, “We don’t require that you’re a security expert, we want you to listen in and learn.” Of course, if you already are a security pro, they’d love to hear from you.

So, what can you do to help with the SIG? Lots of things. Fox continued, “We encourage you to read through the repo. Familiarize yourself with who we are, what we’re working on, and how we run things.”

That done. They’d love for you to “join and review our PR (pull request) comments and or even make a PR to close out an open issue,” said Fox. “We’ve got some easy ones in there. We have labels for tickets that need help, and sometimes just a quick review is all that’s needed. We’ve got presentations and proposals and suggestions, and even security assessments that can all be excellent ways to contribute and grow the community. It just starts by submitting an issue.”

In particular, the pair spoke about security assessments of existing projects. After all, it’s hard to build security tools until you know what’s what in the programs you’re already running.

Lum said. “one of our core activities is security assessments. “Security assessments are something we do regularly and to date, we have completed five security assessments for CNCF projects.” These include SPIFFE, Spire, in-toto, and OPA (Open Policy Agent).

So what is a security assessment? Lum explained, “the term security assessment can often be overloaded, and so we want to make it clear that a security assessment is not a security audit.”

What a security assessment really is, for the SIG, continued Lum is a way “to assess the security posture of a project. This includes looking at the goals of the project and evaluating the amount of thought that has been given to its security aspects. So this ranges from the overall architecture and design patterns of the project, and also the evaluation of security processes. For example, how does the project handle security issues and respond to security incidents.”

And, of course, the assessment includes the types of attacks an attacker might make. For example, if a project uses a plugin or XML database it should address what happens if a database or component gets compromised.

What comes out of the security assessment is a document. This helps provide recommendations to the project’s technical oversight committee. Once the assessment’s results have been addressed in the code. Lum “recommends that the project go through a security audit as a critical security component in the CNCF ecosystem.”

Another worthwhile result from a security assessment is since it provides an overview of the project and its security concerns, end users can use it as a guide to using the programs securely. Ideally, Lum concluded, a “security assessment document has the details of the design and the architecture of the project. So, it ends up being a nice encapsulation of most of the details you will need to know about projects, starting from the ground up.”

You might think this is hard work. You’d be right. But, it’s good work, that’s well worth the going. If you’d like to help. The SIG is open and its people are ready to help you help the CNCF community.

Feature image by Florian Pircher via Pixabay.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: The New Stack.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.