Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2021, 15 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Sponsored Session: Bridgecrew - End-to-end policy-as-code from IaC to Running Workloads

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.

Sponsored Session: Bridgecrew - End-to-end policy-as-code from IaC to Running Workloads

Speakers: Matt Johnson

Infrastructure as code (IaC) is a cloud-native game-changer. It's modular, reusable, and super shareable, making it easy to get up-and-running fast. Because it's so user-friendly, however, IaC is often subject to security and compliance misconfigurations that can make their way to production resources and workloads.
The key to preventing that from happening is adopting policy-as-code and scanning for misconfigurations continuously throughout the development lifecycle.

In this technical demo, we'll show how Bridgecrew enables exactly that for Kubernetes manifests, Terraform, CloudFormation, and more. You'll see Bridgecrew's complete codified cloud security suite in action—our IDE extension, pre-commit hooks, version control and CI/CD integrations, and runtime scanning.

A

Hi everyone, I'm matt from bridgecrew and I'm here to demo end-to-end policy as code right from the first line of infrastructure as code written to running workloads in kubernetes or across other cloud provider resources. So what do we mean by end-to-end policy as code put? Simply it's the idea of ensuring the same policies and the same checks can be run at any point in the developer's day-to-day life cycle. Typically, that starts with an ide, then maybe running some local tests before a commit into a merge request.

A

Some ci cd kicked off in the merge request and then once merged as part of a main pipeline and then finally, through into creating real resources with that infrastructure as code, the idea being at each of those points, we can find and fix issues as soon as possible, but while still having the defense in depth of knowing we're going to catch any, for example, existing issues that are already running in that cloud environment by also running those policies all the way through to runtime.

A

And so we start our journey into the developers. Iac workflow by looking at our open source tool. Chekov chekov is an open source uh policy scanning framework for multiple different infrastructures code frameworks. We support terraform, kubernetes, helm cloud formation and let's look at this to start with in the kind of pre-commit and local testing stage, you know uh developer using chekov as a pre-commit hook or using it to test an existing infrastructure as code repo for any existing issues with their infrastructure's code.

A

So, while chekov has a number of command line, options, dash d with a local directory will do a recursive directory for any of the supported iac types it can find um and we'll output a colorized list, as we've just seen there or even outputting json for each of the different frameworks and we'll provide hundreds of built-in policies across all of our supported frameworks.

A

Now, at the moment, we're getting the output because we're running against kubernetes goat, which is an excellent resource of purposely vulnerable kubernetes resources and bridge crew, also maintains terra goat, which is the same for uh terraform-based resources and cfn goat, which is for cloud formation. So these are all purposely vulnerable, not designed to be deployed but designed to kind of understand and explain some common vulnerabilities within infrastructure as code and, as you can see her running against terra goat, we get we get another set of output and then for each of the policies.

A

You'll find that we provide a link in checkoff to documentation and consider this, like a virtual security person on your team, providing you context, for um you know that issue. If you don't necessarily understand exactly why you're seeing an issue in chekhov, you don't fully understand why a policy is a security issue. That's what those guides are for on each of the policy sections and jumping into more kubernetes centric uh uses of chekhov. As I mentioned earlier, we support kubernetes, manifests and also help charts out of the box.

A

So as you'll see here, if we go back to the uh kubernetes, go to repo that I checked out earlier, um we can actually tell chekov to only discover certain iac frameworks, specifically if we know what we're looking for with the dash dash framework flag. So here I'll ask it to only find kubernetes and we'll see within the kubernetes go repo it's going to go and find any kubernetes manifest.

A

You see all the valid policies at the top and any policies that we fail on at the bottom, and we found quite a concerning wildcard cluster role. um There at the bottom in a aptly named pawn chart um directory, and then we can also do the same and say actually we want to just scan helm what we do with those two sets of policies. Is um they both get run against the same policies? You'll see that each policy has a ckv underscore kate's name and a number and the difference being.

A

If we find a helm chart we're basically going to template that out into a temporary templates directory and then provide a bit of logic to make sure we can tie the uh scanned resource back to the particular release name and the template name, whereas obviously the kubernetes style framework we're just going to find anything that looks like a kubernetes manifest and scan that directly.

A

So the same policies get run, but it just allows us to scan helm, charts out of the box and then it's worth noting that all of the power and all of the built-in checks within chekov we've built into a vs code plugin.

A

So, instead of having to go and run this on a cli, you can see here, we've checked out terra goat and with the vs code, checkoff plugin installed from the visual code marketplace, it's actually underlining and providing us tool tips on any issues within a given terraform block and also providing us information there in the problem section as a list. So with that, let's jump further into the developers workflow and look at post commit in a pull or merge request.

A

Now, for this we're going to use the bridge crew platform, which basically extends the power of chekov and allows, amongst other things, visualization of policies like this, as well as things that require automated scanning persistence, integration with runtime and cloud environments and one of the things we're going to show here is the ability to integrate bridge crew with your github account or gitlab, and what you're going to get is again another step along that pipeline of automation, where we are then going to take those same policies but annotate any changes in an inbound pull request that are breaking any of those existing checkoff policies.

A

So you know you see this in gitlab and github here the same rules apply. um We have a incoming pull request with some vulnerable infrastructure as code and it's being annotated directly in the pr to highlight to that team that this probably shouldn't be merged.

A

Further down the pipeline, we can look at the same repo where we were just having a look at that annotated, merge, request and we can see we have a ci cd pipeline pre-configured and within this we're just going to kick off a re-run of an existing job. Just so, we can have a look at what's going on there. This is a very simple pipeline with terraform, but could just as easily be any of our supported.

A

Iac such as kubernetes or a helm, chart deployment, and if we go and have a look at the pipeline, we'll see check of being used as our security validation step.

A

The only difference compared to our local cli run is we're now passing a bridge crew api key and that's the same, whether using it within github with the checkoff github action we provide or within gitlab, as you saw in the first example, what that apis key is basically going to do same results same output, but it means that that data is getting sent into the bridge group platform as code reviews.

A

So we can track and centralize all of our incidents and kind of see those objects moving through our ci cd pipeline from you know, maybe an issue in a pr that was scanned into being in maine and being highlighted and then even as we'll show later into runtime as well and within the platform. It allows security teams or a security advocate on that team to filter by certain guidelines such as cis kubernetes, um and you know just just get a good idea of collating issues across multiple resources and across multiple environments.

A

And then the final piece of the puzzle is runtime within the integrations page, where we integrated github or any of our other git based annotations. We have the ability to integrate with kubernetes clusters and also directly with cloud providers such as aws, google and azure.

A

So I'm running just a simple local uh docker uh kubernetes cluster on my mac here and what I can do is I can generate a manifest that will allow my kubernetes cluster to send um the state of all its current workloads to the bridge crew platform, where we will then run those against the existing set of kubernetes policies that we also run against our local yaml or against our helm charts. So we get consistency all the way through into production.

A

Let's say maybe there's been a manual change or a deployment outside of infrastructure as code which is breaking some of those policies. I'm obviously want to going to know about that as well um or you know someone's updated an existing template manually and then alongside kubernetes integration. We can also, as I say, do the same with the cloud providers and considering that a lot of kubernetes security actually comes from the configuration of.

A

Maybe a cloud provider hosted kubernetes cluster um which potentially has default, which allow access from places you don't want or embedded security uh defaults that are maybe not ideal. It is important to you know, catch those things as well and potentially codify those in something like terraformer cloud formation and you'll notice.

A

If we look through the policy section of the built-in policies for chekhov and the bridge crew platform, a lot of the policies also check kind of secure defaults of things like eks clusters, as well as just uh the kubernetes specific security themselves and then, while we're in the policy section, if you wanted to add a policy yourself to cover something specific organizational or just extend one of the checks, we support a ui and a json based policy, templating language as well, and then within checkoff.

A

The built-in checks uh are all available to browse within the check of repo itself and are all based on a simple set of python helpers built into the platform.

A

So if you wanted to extend existing checkoff checks- um and this is possible either by contributing to check of itself or by using the option within chekhov to load in your own checks from a separate git repo you'll find within kind of chekhov, for example, under check of kubernetes checks, all the built-in check-off checks and a fairly simplistic set of helpers uh in python to basically find the parts of the configuration you care about, um find the information and then work out whether you want the check to pass or fail in that scenario, so fairly easy to read through some existing examples to extend or write your own and you'll also find in the test directory.

A

Some kubernetes manifests for each of those scenarios um which might help in customizing or kind of getting to grips with the um testing language within chekov, and with that I hope you enjoy the rest of kubecon and cloud native con 2021 virtual and any questions feel free to reach out to me at metahertz on twitter or join our slack at slack.bridgecrew.io.

A

Thanks very much.