Red Hat OpenShift Security | OpenShift, 10 Jul 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: End to End Protection for Container Workloads in Red Hat OpenShift

Description

In this talk from the OpenShift partner theater at Red Hat Summit 2018, learn how Aqua for Red Hat® OpenShift Container Platform works as a layer of security that provides image assurance, runtime controls, and protection against attacks. Learn how Aqua is natively deployed in an OpenShift environment by deploying pods, services, and Daemonsets and protects container workloads against attacks and insider misuse. You’ll also learn how the solution ensures visibility and compliance for OpenShift containerized applications.

A

So today, I'm going to I'll start off by talking about the architecture that we use within our aqua. So the ocular aqua platform works on a concept of containers.

A

Here in the bottom right hand corner you can see a reference to a host, a host would be a machine and that machine could be a bare metals machine. It could be a.

A

Machine on-prem, it could be in a data center, it could be a VM and it could be a.

A

Machine in an instance in the cloud, what we do is we deploy a container and that container would be on that host and it would be enforcing controls.

A

The the enforcer is, as the name suggests, it allows you to block and enforce policies. You have an ability also to monitor the traffic on the within the container environment and that's sent to this next container. We call the Gateway the Gateway really is a misleading name. It's really a buffering mechanism to allow us to scale to very large environment, so you can have up to 1000 of these enforces reporting to one single gateway, and then all the traffic is moved on to the command center.

A

The command center is the management component of the platform, and it's where the UI lives, that we'll be saying in a few moments and then a connection to the Internet this component by the way, can be also deployed as a monitor. Sorry as a container as well, and essentially this is where our vulnerability database lives. We have a group internal taqwa.

A

We call the cyber intelligence group and they're responsible for collecting all of the information regarding various vulnerabilities and then what they do is they collect, check, cross reference and summarize the vulnerabilities and make this available to the command center and, on the left hand, side. We have different references to different integration points. You can see a reference to the various registries.

A

From our perspective, it doesn't matter if they're, public or private, you would input the credentials to the the platform and we would work without registry transparently and then a reference to other integration points, CI CD, a CI, CD tool or CI CD tools. We are not stick to any particular vendor, so you could use any vendor that you choose and we can integrate with any CI CD tool and then other integration points like log management, log analytics and sim tools.

A

The the integration points are extensive, so there's a long list of integrations like integrations with notification systems with LDAP systems, with sam'l systems and secrets, various vaulting vendors and then, on the top right hand, corner here a reference to what we call cars containers, a service.

A

We have an ability to inject our controls into an environment where you don't have access to the underlying host, so really an ability to inject our security controls into an image. And then, of course, when you OC, run or cube, CTL run or docker run the container we are built into that container, so that this this would be a solution for environments like AWS, Fargate and jewels AC on a service going to move on to the actual UI a bit.

A

So here you have the UI you can see. The image is basically broken down into their relevant repositories. If we look at any particular repository, you can see in this case two images in this particular repository, and this is enforcing a policy, the policy the policies live here. You can see a whole number of different types of policies, we're going to focus in on image assurance, and here you can see you can create as many as you want to so.

A

For example, if you wanted to create a different policy for the dev environment or the production environment, you could do that and then, when you go to the actual policy itself, you have a number of different options that you can enforce. So, for example, we would block any unknown images or what we call unregistered images, and you have a whole bunch of available options that you could add to what's being enforced in the policy, so you could, for example, blacklist see these.

A

You could disallow an image if it is configured to run as the super user. By the way we have not only support Linux containers but also windows containers. So that the reference here is to the super user as opposed to a root, you have an ability to blacklist packages, you could define which packages are required within an image. You could.

A

Use NIST standards to define the severity level or the CVE max score that you're prepared to tolerate within your environment. You could utilize the power of s cap for compliance e needs. You could blacklist open source licenses, you could whitelist images, blacklist images and even define an improved base image. Now. Not only do we scan for vulnerabilities, but we also scan for malware sensitive data and we also allow you to custom, create checks as well.

A

So this is really allowing you to define anything that you feel is missing from the available options here and enforce it.

A

So up till now really I've talked about the ability to scan I suppose from a registry now I'll talk about shifting, left and really integrating with the CI CD process. So this the example is an integration with Jenkins. You can of course, use any CI CD tool and essentially the integration would be almost exactly the same. If we look at the particular project. Actually, if we go I'm just going to go back there, we can see four projects here you we can see that two of two have succeeded.

A

One has failed if we go into this particular project, go to the build history and go to the last build first thing: you'll note is the Aqua security icon that appears in the column. On the left hand, side, of course we have a plugin. You can go to the Jenkins marketplace, download it install it, and then this icon would appear as it does here and then probably the best way to explain the integration is to see the console output here and what you can see here is sort of the the creation of the base image.

A

And then you can see a call to a container. That container is the aqua scanner and what it's doing is it's going to our command center and retrieving a policy and scanning against that policy. And then you can see the various layers being added here and then you can see a reference to calling the aqua container scanner and once again going to the command center and retrieving the policy and Roenick running against it. And you can see the failure notification down here and to understand why this failed. You can go to.

A

You can go to the the icon and essentially get the information on why this failed and and all of the details. So essentially what we do is we can provide all of the output in either JSON format or HTML format and send this to the CI CD tool and basically utilized the CI CD notification capabilities.

A

So up till now, I've really talked about scanning now I'm moving on to what we call runtime protection, we have an ability to control and learn the behavior of the container. You can see here a reference to the runtime policies. We call them profiles. You can see that there's an ability to we have an algorithm that would actually learn the behavior of the container and custom, create a policy specific for a particular container, or you can use pre-existing policies.

A

We have a whole bunch of them that live in the in this section and then you can create your own new.

A

Custom policy or, let's say you've, created something and you feel for whatever reason it's changed. You can use the profiler to relearn it or you could have no protection at all. So really you have the different options available to you at your fingertips and if we look at one of these policies, let's just take a look. The sort of controls that you have here are for one. You can set the policy to block if you're about blocking you can set it to audit.

A

Only so, essentially we would only alert this policy has been set to block. You can see that we learn all of the resources being used by by the container. In this case, it's the allowed executables. These controls would define user access. What users are allowed to access this particular container, and then you have everything else about the container, including Network activity, whether you want to define read-only directories and.

A

Here you can see the essentially the limits you could define and again this this can be completely automated using our API is unscripted memory, usage, CPU usage processes being used disk usage, and then we have a clause that allows you to prevent any drift from the original image. So if you remember initially, I talked about the scaling capabilities and hashing all of the contents of the image. This allows us to actually prevent any changes being made to the container as it's running.

A

I've got to move on to the container firewalling capability, so once again, this can be scripted and automated. We have again a very similar mechanism to learning the behavior of the actual container inside the container. We have this for networking.

A

Essentially, we would learn and then create a rule set that rule set would govern and control any inbound and outbound traffic and, of course, you can edit any of these parameters. This is done with an understanding of the container and container entities and principles.

A

So we understand concepts like within the kubernetes world and the openshift world, like a namespace, a deployment label and, of course, a container name and ID, so that if this container would go down and be redeployed on a different host with a different IP and port, of course, we can enforce the controls, regardless across the entire infrastructure.

A

Lastly, like to talk about secrets management, so what we have is we've created an invite and a proxy incapability between third party vaulting vendors and the container. What we do is we would take a secret and replace it with our string, and that string then becomes a pointer to the encrypted value within the vaulting solution, and what we do is we would retrieve it at run time from the vaulting vendor and inject it into the container at run time, and what this has allows us to do is to control all access to the secret.

A

We have a system of user access controls and then all of the aspects of administering and managing the secrets become very easy. So we have capabilities that allow you to edit, for example, or change a password on the fly without having to restart the container so once again, not impacting business continuity.

A

With that really I finished, thank you very much. You.