Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2022 [End User Sessions], 1 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: The Cloud Native Chasm - Emily Fox, Security Engineer, Apple

Description

Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Keynote: The Cloud Native Chasm - Emily Fox, Security Engineer, Apple

They jumped, they leapt, they soared - and graduated. Cloud native projects each have their own path for crossing the chasm. Some projects front load - they spend a lot of time going over every detail, building governance and technical strategy while others run and jump, catching their breath on the other side to regain composure, build endurance, and continue moving forward. But for some projects, they’re still on the precipice, staring wistfully at the other edge, yearning to get there. There is no road to drive down, and no bridge to cross. In this talk, we’ll explore what it means to build that bridge, add side rails, and enable other projects continue improving that bridge, bringing everyone forward together.

A

Hello: everyone. Yes, my name is emily fox, I'm a security engineer at apple and today I'm going to talk to you all about the cloud native chasm. So we've heard a lot already about security in cloud native communities and guess what I'm a security engineer. That's what I'm going to talk about. So, let's get started. It's a jungle out there whenever we try to go somewhere new, like starting a cloud native project, for instance, there's not always a path before us.

A

We need someone to lead the way. What we need is a guide. It could be a mentor. It could be one of our colleagues, another project, perhaps even ourselves, these guides they navigate the path, but our guides ourselves we're probably stumbling through the cloud native landscape, because it's super complex and massive and we're terrified because we don't know what it is exactly that we're doing.

A

But we are so excited at this idea that we have what our cloud native project can actually bring to the community and what kind of impact it can have. But the path is going to be rough. Like I said, it's a jungle out there, but we've got vulnerabilities jumping out at us from our code bases and our dependencies. We have whole tribes of adopters that are demanding features and changes of our projects and half of our exploration crew. You know what they're probably tied up behind a desk somewhere trying to fix a bug.

A

That's blocking our next release, then there's the maintainers.

A

These people work really hard, and you know what they're dragging everyone forward with them: they're fighting off somebody trying to take over their github account and they're still trying to graduate before kubecon cloud nativecon, north america, you see not everyone and not every project is going to cross the chasm the same way. There is a lot of work that needs to be done and it's going to be project specific, the bigger your project's impact or our project's impact.

A

The bigger the impact on the ecosystem is going to be because, no matter what the larger the vulnerabilities we inherit or create will affect the world, because no one and no project is without its flaws. It could be that we missed something. The jungle was in the way we got swept up in all the excitement, but now it's before us, it's staring us in the face waiting, silent demanding for a decision.

A

So what is this mountain of work that I'm talking about? What is this inevitable decision? That's before us in 2018, at oscon, josh brushers said it best. It's no secret! If you read the news, everything is on fire and even security people don't add security in on day one. This is shocking, right, security person saying we don't add it on day one.

A

But when you, when we think about it, we first need to focus on what is our project. What is it going to do and how is it going to do it? Only then can we consider the security mechanisms that are going to be appropriate for it for its particular environment and how we're going to deploy it from there?

A

We can consider the kind of bridge that we're going to build. Is it going to have guardrails? Are we going to do secure defaults, those kinds of things in the past 20 years technology has made a huge shift, and so has security, distribution, ephemerality immutability.

A

These are all natural extensions that are building on top of the fundamentals of our core security principles from decades past confidentiality, integrity and availability. But it's how we apply these principles and controls and security ecosystems like cloud native, and it's going to vary from project to project, to project deployment over time, just like with software development. We cannot set these things and just forget them. What was critical 20 years ago for security is quite literally a thing of the past, our risk tolerances, our implementation, our technology usage, these all change.

A

This means we are required to iterate refine, refresh and re-evaluate our past decisions.

A

The worst mindset that we can have, as we move forward in this space, is that we've always done it this way, and that is why everything is on fire. Daniel measler said periodically step back. Ask yourself what success looks like and ask yourself if you're, taking a direct enough path to get there, that bridge that we started to build. Is it still the right one? We need to think about who our potential adopters are. What are our intentions with the project? What kind of attacks are we going to be facing?

A

Threats are not the same decade after decade or even year after year, we're in a new era of security, where the pace of vulnerability, exploitation and weaponization is on the rise. Throughout this conference, you'll hear there's a hyper focus on security, especially on supply chain security.

A

Sometimes, though, when industry focuses on a particular area, it can lead to misconceptions: it can lead to cargo cults, buzzwording and pile on publicity, for whatever that project is, it can create whole new classes of issues from overloading leverage points with gateways and excessive security, tooling that we actually don't need.

A

It may not actually solve the root problem either it could just be treating a symptom and from there it can start creating whole new classes of security problems that we never knew existed, and then I'm going to be back here on this stage in 20 years, giving the same talk.

A

We need to perform independent due diligence against our own environments, our projects and our deployments. Only then are we going to know where we're going and how we're going to get there. It's important that we try to that. We need to think about things and understand what we're trying to achieve the security controls, because a bridge to nowhere is useless. Security controls are not going to apply everywhere, adding them in, for the sake of checking a box will just leave you with frustrated engineers and a broken project.

A

Security mechanisms, controls processes. These things need to be specific to your environment, your application, your data, your users, and how it's going to be used. We need to think about not only how these projects can be abused by an adversary, but also how it can be misused by your adopters.

A

Every project has at least one function or operation that will make or break your project's ability to protect data tag it and track it. Tracking these areas of your project allows you to identify those security features and checkpoints where they exist, so that, when you're introducing changes into your project, you know what that impact is going to look like and building a secure. High impact project is a lot of work. It requires help. That does not mean if I show up to your working group meetings. Emily fox is a security engineer.

A

She gets all the security issues. Don't do that it's not going to work, but you in your capacity as a project, maintainer or contributor. You have the same rhetoric and engineering mindset. That's required to design a secure solution. You can apply that same principle that analysis to whatever your security problem is. Are you thinking about doing multi-tenancy, for instance, have others accomplish this in this space? What security mechanisms did they use? Have they had any issues with it? Do they actually have true tenant isolation without traversal or lateral movement within that environment?

A

Use cases that have been designed for that particular multi-tenant instance: are they similar to ours or are they different? We will never actually know what our adopters are doing as maintainers developers and contributors to projects. We have our own perceptions of how our product our project, should work and and the expected interactions from someone or some service, but regardless at some point, it's going to be used in a way that we didn't intend for it can be malicious.

A

It can be opportune, it can be unintended, it could be that we will be exposed to changing uses and new use cases of the project that we have never considered before. These same events could reveal an inherent weakness or where our security assumptions are no longer entirely valid. It could be a headache or a dumpster fire. We need to plan for this. We need to think about every function, every process and every trigger. As a toddler.

A

We need to ensure that we're putting in gates guards checking in with them guidance and establishing structure, to make sure that our project is moving forward safely and all of us are responsible for these things. Our goal is to reduce the impact when every design flaw and missing input validation is found, because inevitably they will be. What seemed like a non-impactful design decision several years ago is probably going to introduce a problem for us that we realize wasn't a side effect until now and could make an existing problem even worse.

A

It could cause a denial of service by pulling in a newly weaponized dependency that exfiltrates and then deletes your adopters. Data security through obscurity is often a com common fallback in these situations, but it doesn't work for everyone, building your projects and moving an idea to a commodity. It requires public discussion and clearly documented decisions and justifications.

A

Well-Defined road maps with clear outcomes show potential adopters and contributors the care and consideration that you have poured into your project and provide an avenue for future health and ways of engagement. So you or us as maintainers, aren't doing all of the work all the time multiple times over precedence and provenance are what's key here.

A

It could be that we chose to include an embedded web server within our product, but not all of our adopters are going to need it, so we purposely require it to be explicitly enabled. This is a secure by default design decision that prevents your customers from arbitrarily serving or receiving http calls.

A

The cncf has a variety of projects: working groups, technical advisory groups, materials. All of these things are available to adopters projects. Contributors we've heard about some of them here today and the cloud native security community, specifically cloud native eight security controls, catalog security reviews and joint assessments and self-assessments are just starting points for you to join in and learn more about how to secure your project, participate in a review volunteer within the tag, security or kubernetes sig security.

A

These are all excellent ways that you can be introduced to the security concepts to help reframe your thinking create more secure structure and build that bridge to cross the chasm. Thank you for your time.