Welcome. To cloud on air live webinars, from Google cloud we're. Hosting webinars every Tuesday my. Name is Micah Trotsky I'm a product manager in security and today we'll be talking about container security, you, can ask questions any time on the platform and we've Googlers on standby to answer them so. Let's get started so. We'll, cover a couple different objects today first we'll start with kind of container security 101 why. Why are containers different to secure of any VMs are then, we'll talk about the secure software supply chain and deep, dive into two of our newest products Google, container at the Street vulnerability, scanning and binary, authorization, lastly. We'll see what else you should be doing in the space beyond software, supply chain how else can you protect your containers running a production. So. Starting off with container security 101 a lot. Of what's needed to protect containers, are constructs, that were already familiar, with there, were some similar things we have with VMs we still want firewalls, access, management audit, logging, ids/ips, and, more the, concepts, that you need for securing your containers aren't dramatically, different but, the mindset of constantly rebuilding and redeploying containers, is what's changed so. What specifically is different, let's let's get that out of the way first in terms of protecting in terms of how security is implemented for containers, first. Is the surface of attack a container, bundles binaries and libraries as part of the container image so, you don't need as much in a host image if, you're using containers as intended that, host OS doesn't have as much bloat which reduces the surface, of attack, next. Resource, isolation this, is built into containers, allowing you to easily allocate, resources like. Storage volumes to certain processes, using namespaces, in. Terms, of permissioning, containers, have normal access controls like you'd expect for, controlling access to shared resources and restricting, apps privileges, that, being said containers, by construction, are more powerful and have a wider range of syscall that they can perform in the kernel and lastly. Of lifetime containers, are meant to be immutable and a frequently redeploy so, they're fairly short-lived in fact. 95%. Of containers left less than a week this, should make it harder for an attacker to persist in your environment but, it also means that if something does go bad by the time that you realize it the, effective container might not be there anymore and you want people to do forensics. So. What kinds of threats are there to containers where we see you, know in the wild how do we categorize these threats first. Is a set of threats to container peripherals, like credential. Compromise in provincial escalation, this is about how to get the Cabrera's API to do something that you might not want it to do next. Is what ends up running in your infrastructure you might be pulling images from public repositories. Or have dependencies, unsupported, open-source code if. There's a new zero day vulnerability, discovered, tomorrow how, do you figure out if you're affected and how do you quickly patch yourself and then, there are things that we hear people get really scared about things like dos attacks and flooding your event pipeline or even, container escapes. And. This is how we're thinking about container security at Google if, you think about that what kinds of controls you can put in place for each of these types of threats we end up with three main pillars how you develop applications, how you make sure your images are good to build an deploy and how, you protect your containers while they're running so. The first one there infrastructure, security is about ensuring that your developers have the tools they need to securely build containerized, services this, includes Identity and Access Management logging. Secret, management networking, other, such tools the. Software supply chain is about ensuring that you know exactly what's being deployed in your environment and that, it belongs there this, is about securing the host image the, container image and the application code itself, lastly. Runtime, security is about ensuring that your Security Response Team can, detect and respond to security threats to containers running, in your environment so today, we're gonna focus on that middle piece here the salt the security software supply chain. So. Even, if how you secure containers is actually very somewhat of a mess except for some of the differences that we pointed out running. Containerized microservices leads to a different security model, you, have a fundamentally.
Different Mindset, to adopt which all argue actually leads to better security longer term first. Off containers are meant to be short-lived and frequently redeployed rather. Than pushing a single line of code change rebuild. And redeploy the whole image if, you, have other processes, that can take place possibly like patching your OS for example you can be constantly, doing these you don't have to have any Sunday - am mainland's windows. Containers. Are also meant to be immutable this, is really just the previous point so, you're not changing single, lines of code you're changing whole containers, what. That means is that you have a single choke point for everything that gets deployed into your an infrastructure, if you're deploying frequently, you can actually really quickly see and control what's being run in your infrastructure, a. Common. Concern about containers they don't provide a strong way, to contain workloads or rather, VMs, have a strong boundary, like a hypervisor that's well understood as. A result users are hesitant about running multi-tenant, environments that is deploying to containers for different workloads on the same VM, because, they're worried about you know one workload affecting another this. Is a fair concern but no. Longer really true with containers we now have technologies, like G visor that are specifically built for meeting at this risk so. The primary counter-argument. For containers is actually now one of its greatest strengths and lastly. Containers, and orchestration, platforms like kubernetes have security features built in a lot, of security changes when they're not already enabled our simple config changes you don't need to go, build something a new tool yourself in order to move in something, so. Altogether that means that yes that your mental model is different but, you actually have much stronger security properties. So. As, we talk about the secure software supply chain today we're really focusing on the first two pieces let's. Look at those a bit more deeply, the fact that we have short-lived frequently, redeployed containers and that. They're meant to be immutable together, this this dictates a lot of what goes on your software supply chain. How. Is this actually different well historically, a monolithic application running on a VM to make a change your developers we need to SSH into that machine or push code changes, without, necessarily predicting the impact that would have on the rest of your environment what you see on the left there there. Are manual adjustments, including for maintenance operations like like restarts, with. Containers you can have a pipeline you can push code to images which then go through your design requirements, for build test scan, etc, until deployment. Micro. Services are redeployed as individual, container images rather, than changing specific lines of code it's, easier to debug and it's easier to change and. So. From from your code you might create a base image that goes through your pipeline we're. Gonna focus on today our two items that you can integrate into your pipeline between developing, your code and, pushing into production the. First is container registry vulnerability. Scanning you, might want to store certain image metadata as part of your image repository including. Notably whether your images have known vulnerabilities, and the, second one is binary authorization, you, might want to enforce that your images meet certain requirements before, you deploy them to your production environment, so. Let's dig into this first, up container, registry vulnerability. Scanning. Thank. You Maya hello everyone I'm, going to talk about container, registry vulnerability. Scanning. Essentially. What container vegetable an ability scanning does is it. Scans your, images, in Google container, registry for, known vulnerabilities. By, checking the, corresponding security, databases, the. Value in this is that enables, you to identify. So. You can address them and in that way protect your application, and protect your customers and your infrastructure. Currently. The product supports, Debian.
Ubuntu On, a bun two and out point based images, but, we're actively working on and support for additional distributions. Like, CentOS. And Red Hat, what. It does is once. Vulnerabilities. Are found a, alerts. Are generated, using our pops up integration, and they're also surfaced in our UI or. CLI, and also we are api's. Images. Are scanned as soon as you push them into GCR, and. Also. Africa after that initial scan we continuously, analyze, them and as new vulnerabilities, are discovered, we, surface. That information, for you so. You. Know when once you find Apple durability using. You CI out using modern ability scanner how should you react what you well. As I mentioned the information, is made easily. Available for you we are the UI the CLI, and the API you. Can also use something like the GCP, mobile, application, to set up push notifications, so you are alerted when new vulnerabilities. Are found. Also. With pub/sub this, gives you a lot of power in terms of plugging, the findings, and plugging the vulnerability, information into other parts of your workflow and you can, use some a cloud functions, to essentially. Enable, a communication. Between these, different systems an example. Could be using. The pops or notification, information, we are closed functions to then generate an issue or. An. Item to track in your repo so at someone is assigned to a vulnerability, and it can be further analyzed, and and addressed. In. Terms of you, know how to mitigate. Vulnerabilities. How to prevent them in the first place there, are three general categories, the. First category is, basically, updating your packages so, this is easier, said than done, but it's very important for you to regularly, update the, components, that you used to build your images, as. Part of your docker, build, images and your general build process something, as simple as you know apt-get update and apt-get upgrade goes a long way during that all components, are updated, and you're not exposed to previous, vulnerabilities. Category. Number two is removing, packages, essentially. If you use a stock. Base, image from, Ubuntu. Or Debian those. Coming with a large set of packages and many times your application, wouldn't one need all of those to run so, it's important for you to analyze and understand what packages do I really need and then to remove the ones that are not necessary, and then.
The Third category is using a new distribution, for. Example alpine. And Debian slim and are much lighter and much smaller and by. Using one of those if. You're able to run your application on those the, attack surface is significantly, reduced and your. Software. Supply chain can be secure much more effectively by using one of those. So. In terms of continued stable and ability scanning, to, use it it we're. Currently in alpha so you need to join the container, container, analysis. At Google Group this. Is going to change soon once we go to beta but. Basically, what you'll do is you you, need to enable the API and after. You do that you'll start to. See information like basically your images in VCR will be scanned you see a status change to scanning and once, the process is completed you'll be able to look at over the results, and find. The number of all and vulnerabilities. In a given image like in the image in the in the slide. In. Terms of some, basically. Key definitions, for vulnerability. Scanning and note. Is a detailed description of a vulnerability, so, for example you know the severity of it this every score, an. Occurrence is information. As to where it happened where it was found, so for example what package it applies to and a, vulnerability, result, is the summary of the different, vulnerabilities that, were found in a corresponding image, basically. The the summary result that you see in the middle of the screen there in the slide. So. Now I'm gonna give you a quick, demo of the vulnerability. Scanning UI and walk you through it. And. Here. So. Here. We're starting from the, console and then. What. I'll do here is i'll search for container, registry. Once. I go there I'll be able to see all of the different images that I've pushed, so. As you can see here I have different, categories of images are, going to a python-based, images, and in. There you see I've pushed three images, the, bottom one used Debian, as the base and as.
You Can see in the summary there five vulnerabilities. With fixes were found and a total 509. Well and abilities were found in. The, summary, page you can see the scan results at the top which, gives you the counts for the total the ones that have fixes available that. Counts for different severity and then, you can scroll down the list and in each row you can find the severity. The score whether, a fix is available, or not the package that it applies to and also a link to documentation, where you can learn more about the vulnerability, something. Also you can do is you can scroll through the different pages to find, all of the information and you can also sort by. Column, so for example in this case I sorted for the vulnerabilities, that have fixes available. And. Then when. You click in a specific vulnerability. You'll be able to see details about it so for example you see when I was created, when, it was updated details. How the occurrence, the note and importantly. You'll also see links to documentation. For. The specific, vulnerabilities, so you'll learn you know what remediation, steps you can take now, going. Back the second image that I pushed you start Debian slim base so, as you can see this one has fewer vulnerabilities. 51 in total and none, of them with fixes and as. I showed you before when, I go through the, list of items I can see the overall counts, rows, for each vulnerability. And clicking. On each of them gives me more details in terms of you, know what. What I should do by going to the vulnerability, documentation, page and then. The last image that I pushed pushed, was, based. On Alpine and as. I mentioned Alpine is a much smaller distribution, much lighter so in this case no. No, no, no owner abilities were found so. What. You can see here is as you go through it when you push images, they, are analyzed, the, information, is made available for, you and, very. Importantly, you are given. Information on, actions. That you could take by going into the beetle details, page on potentially. How you can address that vulnerability. Something. All that I want to cover is, a graph. As krafayis, is. An. Open, artifact, metadata API that, we've worked on with the community, what, it does is it enables you to have a consistent, way to store information about, the artifacts, and the general, items in your build process so, you can reason about it essentially. You can know what artifacts you have whether, or not they have vulnerabilities you can store that information and, then, you, can also know what's running in production what's in different environments and based, on that information make informed decisions to protect your supply chain. As. I mentioned this is something that is, open. So, you, can add new meta data types and providers, as your supply chain evolves. And grows it's. An open standard that. We've worked on with contributors, like Jay Frog Red Hat IBM, Black Dog twistlock. Aqua. Security core OS among others it. Gives you full visibility into, the, artifacts are going to your supply chain and, their, state and different metadata and you. Can set up an instance to run on-premises but then also, our, container, analysis, API for invulnerability. Scanner is an implementation, of the graffities, open api. And. You can learn more about it by going to Cal see how Hightower's, tutorial, and github you, can learn how to set up your own instance and how to to to, run it and. Now a Sanders, want to talk about binary authorization. Hello. My, name is saundra i'm here, to talk about binary, authorization. So. As Maya. Mentioned earlier that containers. Give you a way to apply consistent, changes and avoid, on-demand. Direct, manipulation, of, running. Production jobs, so. In the container model, developers. No longer directly patch, updates, ray start running, jobs instead. Organizations. Can have a consistent way, to apply changes to, any production. Workload, be, it modifications. Or new deployment, a lot. Of organizations, have implemented. Streamlined. Tests. As. Part of their CI CD pipelines, to apply, security, as well as. The. Integrity tests. To, make sure that the changes, made in production, needs, their. Requirement. However. This. Approach. Still. Does not change the fact that deployment. Controls, is identity. Based ie. Restricting. Who can deploy not. Restricting, what can be deployed. So. In. This setup organization. Is still vulnerable to. Deployment. Of untrusted, code a developer, could still, potentially build a container. Outside, of the secured build environment, and deploy it on production.
Environment, As long as the developer, has permission, to deploy this. Untrusted. Code would, still go through and affect running production jobs and. That's. Where binary authorization, County Bar, Association is, a deploy time policy enforcement, that. Uses. Signature. Verification to. Allow you to define what, can be deployed in addition, to, restricting. Who can deploy code, it. Integrates. With the gke, enforcement. With. The chicory deployment, API and it, supports both signature. Verification as, well as image, whitelisting, to support various. Use, cases such. As making. Sure that images, are butte, by trusted, c SED pipeline, before, getting deployed in production environment. Or only. Deploy images that pass a certain security, or quality test or. Only. Deploy. Explicitly. Authorized. Third-party. Images. Let's. Take a look how it works Biron, authorization works by. Integrating. With, certain. CI CD stages, and record. A. Signature. Or what we call attestation, as the, image passed through with a particular CCD stage successfully. So, in this example, the. Puter would issue an attestation, signifying. That the, image was Bute successfully. By the trusted puter similarly. Test would sign or a test. Image. If. The image passes, necessary, tests as well. As vulnerable T scanning if the image has passed. Necessary. One a vulnerability scanning, checks, the. Scanner would issue a another, attach station by. The time the image comes, to, deployment. There, are set. Of evidences. That's, already accumulated, for, the image that, customers, can use to defend policies, and codify, what, requirement. Must the image meet before it can enter the production environment. In. This model e, also. Raised developer. Can. Try to deploy, something that, does not have the, necessary attestations. But, this would fail and an. Annotation will be added in the auto log for this deployment. Attempt. So, the security team can review this. Incident later on. We. Understand, that organizations. Don't just run in-house boots off wears a lot, of so exciting, runner abilities, are found in, third-party, software. Environment. Sorry the binary, authorization, supports, this by, giving. Organization. Security, teams a tool to, define white, list of what. Third party imagers are allowed in, their production, environment, so, that they can have centralized, control, over, the software, as. Well as different. Versions. Of the software deployed. On the on. Day or, Asians infrastructure, so, in this example the security team would define whitelist, only. Allowing, a particular. Version of an energy access as a team and secure, so, when developer deploys, this. Allowed. Version, of nginx. The, deployment, goes through because in it is allowed by the whitelist, but. If a developer. Either, malicious, or accidentally. Deploy something that is outdated. Not. Allowed. By the security team the deployment, will fail again an annotation, will be added in the auto log for future review. Our. Authorization, is. Integrated. In.
Kubernetes. Engine and is, now in beta to, turn on you first enable, the, pioneer authorization, API and. Then. When you create or update your kubernetes, engine, clusters, you, you would turn the final authorization option. On. Then. You, will go ahead and define our deployment, rules in binarization. Policy. Either, at the, project, level which would apply to all clusters, in the project, or you, can also define granular. Cluster. Level policy, override that, would define, policy, for a particular cluster. We. Also support, image white listing either. Using. Repository. A particularly. Path of a. Pattern. Of the, image, name a path, or a particular. Set, of image, digests. As. I mentioned any. Violation. Of the deployment policy, failed, attempts, would, be recorded in, the auto. Log and can, be reviewed. Later on in, stackdriver. Now. I will, show you binary, authorization, in action, by giving you a quick, demo. In. This demo we'll. Show you two use cases one. Is. Important. Deployment of sign images, second. Is only. Deploy whitelisted, third-party. So, let's start by showing, you how signature, verification work, we. Have a pipeline here, that's. Beaut human claudi's in this pipeline there are two attesting, or signing, stages. Signing. Everything that's filled successfully, or standing. Something, that is beautiful tact or production, ready. Code. For. The to signing stages we need to corresponding, at testers created, in binary authorization, so we have the buta, and a tag a tester, each. Of the a tester, has. Its, own private. Signing, key the public key is listed here but customer, will be the one managing the. Private signing key that, only the trusted stages, in the butte pipeline I'll have access to that can produce this, signature. Or attestation. So. Now. Let's switch to the container, to. The project where the image will be deployed, and. Create. Clusters, with, minor authorization enabled so we'll have two clusters will have a dev cluster, where. We'll deploy. Anything. As long as disputed, by my trusted pipeline. I'll, also have a production, cluster. Where. I only want to deploy. Code that a butte from a production. Tagged, code. So. Let's go ahead and defined that in, binary authorization, policy.
Policies. Are defined in terms of testers. So the Tewa tester that i created i would, require the buta tester ie anything. Field security for. The project as a default rule for. My production cluster I will, require both the buta tester as well. As the, tag a tester, aka. Having, the tagged attestation. Signifying. That it's beautiful. Tag source code. Now, that I have that define, let's. Go to our, beauty. I plan and start, a beaut. As. You. Can see that. The, beaut, run. Through the. Attesting. The beauty attestation stage but skips the tag attestation, stage because, the code is not tagged so the pipeline. Will. Not add the. Tag, attestation to it. So. Let's go into the console and take a look at what a pass stations are created for the newly created image. So. We did a query. And. Here the. Image has one viewed, attestation. And. Let's deploy this image throughout the up cluster. Take. A look at the workflow, status yep, it was, deployed successful, because. Their, cluster inherits. The, default, project. Rule, that only requires, viewed attestation, now. Let's try to deploy the image on the product, tester. On. The pod cluster, which. Requires both the beauty attestation, as well as the, attack at his station as expected. The deployment fail because, the, image does not have the tagged. Attestation. Sensor was not beautiful tag, code. So. Let's go in and mark, the, code for. This image as production ready. And. Reviewed. The image as. You. See the. Pipeline. Skips ahead and add. They, tagged a test station to the image now that it's able to find a tag on the source code and. Now. Let's try to deploy, the image to prod again. All, right as expected. A succeeds. Because both, attestations. Are present. Now. Let's look take a look at how to run third-party images on my. Infrastructure. Or. Use nginx, as an example so. My security team has deemed a particular version of a ninja X as trustworthy. And want, to make sure that everybody, only deployed, this version of nginx, on my entire infrastructure. But. Let's, try to deploy it um before. We modify, our deployment, rule as, you. Can say as, you can see the deployment fail because, the. Images. Are not viewed by me so it doesn't have the necessary attestations. Well. What we have to do is to go into minor Association, and add the, image to. To. The whitelist. The. Voiceless essentially. Says that in addition to any images, that has a write attestation, high write signatures, also. Trust these explicit. List of images that may not have so right at sa ssin in. This case third, party images. Now, that we've added it let's try to deploy it again. Deployment. Was successful um. Well. What happens if I try to deploy a different, version of nginx, that's different from what.
My Security team are whitelisted, in. The deployment, policy. The. Deployment fails because, it's a different digest. Here. Is a link to binarization, website. For you to learn, more. In. Addition to the integrated. Deployment. Policy. A policy enforcement. Provided, by an authorization, to create, his engine, what, about kubernetes. Deployment, that you have on pram or elsewhere. We. Believe that deployed. Hand controls, is one. Of the key security. Best. Practice, for containers, that, is why we provided, a open source reference implementation. Kritis, that, will provide similar. Enforcement. Flow for. Kubernetes deployment. Everywhere. Kurtis. Integrates, with Gracias, metadata API that, Hawaiian just mentioned earlier, and. Provides enforcement. Based. On metadata, that we recorded, in the graphics API, it. Performs. The enforcement, using, creative admissions, controller, it. Is open source built. With the community, it, provides. Two parts it provides, the enforcement. Deployment. Time enforcement. Similar to binarization. It also provides, a signer that. Connects. Metadata. To. Attestations. So, in this example the. Critici--, 'nor would. Examine. Build. Or vulnerability. Findings, published. In any gracias. Api and. Apply. Custom logics, to determine, if, the findings are acceptable. To your organization, if, it is it would issue an attestation that. Can be, used to, perform. Deploy. Time enforcement. Later armed. Binarization. Is now in beta we, just announced beta launch yesterday, so. Welcome. To come and try. And join our discussion group let, us know how, you like it as I, mentioned, binarization, provides, policy, enforcement for gke i deploy time both. In terms of signature, verification as, well, as english whitelisting we, provide project and cluster level policies. Via. Gracias, and kritis, it integrates. With GTR vulnerability, scanning and cloud build. We. Also supports break last deployment which I did not mention in my presentation, that is when if. You have a production emergency. You are able to make, deployment. That, push. Through deployments, that do, not meet final authorization policy. We. Are specifying. A break glass flag and this, incidents will be recorded, and can review this later this gives you the, flexibility, to, accommodate. Any, operational. Anomalies, in your deployment flow. We. Also have partner support from popular. Security tools such as twist lock as well, as popular CI CD - such as cloud base and Jenkins, so, integration, with your existing say ICD pipeline should be very easy in. Addition to all that we, also provide a open source reference implementation.
That You can use for. Your, community's. Deployment, outside of chikki. Thank. You so what's next Maya. Thanks. Andrea so you should definitely check out container registry vulnerability, scanning and binary, authorization, there's, lots of other things you can do to protect your containers as well, there's. A lot of guidance you can follow so we've tried to break this down by how mature your deployment is first. You have to set up a cluster you're gonna want some basic some, some basic functionality, to, provide user management and never segmentation, these, include how you're gonna access, cube, CTL how, you provide an access to your users using auerbach how you restrict inter intra cluster traffic, with a network policy how. You architect your app and segment, your cluster using namespaces, and how you bootstrap trust for your cluster CA, now. That you're up and running you're gonna want to maintain some basic security hygiene, is about ensuring, that containers, you're, using and a nurse shall really leverage their security benefits this includes keeping communities and your OS packages. Images etc updated. And patched using. A minimal OS for a smaller service of attack like container optimized OS or costs on, kubernetes. Engine using. Minimum iam rules for least privileged private. IP addresses to limit network connectivity of your cluster, monitoring. Access with audit logging and ensuring, that only the binaries that you deploy you build are deployed that's buying authorization, once. That's done prevent, known attacks these are common misconfigurations, in kubernetes or known, vulnerabilities, that could affect your cluster these. Include disabling. The Carini's dashboard because it has privileged access disabling. The default, service account token protecting, node metadata as am, a current broader access than needed in scanning. R images for known vulnerabilities, for example using container registry vulnerability. Scanning and lastly. Limiting, the impact of a potential compromise this. Is more traditional hardening. And fine tuning of your environment include setting, up odd security policy to limit what's deployed in your environment protecting. Your secrets, send, boxing certain highly risky workloads, limiting. The identity that pods used to authenticate other services, and using, a service mesh to enforce strong a network protection between your services so there's, a lot here we'll put a link up at the end where you can find out more about you know hardening advice for kubernetes but, you know don't don't despair there's, there's a lot going on in the container security, space and a lot you can do to help protect your containers. And so, those are the two items we really covered today right binary authorization, and container, registry vulnerability, scanning or just one, piece of a broader container, security story. So. In addition to that what we discovered today you, know why would you consider Crimmins, engine over, running communities yourself from from a purely security point of view well. First of all kun a's engine provides some, common security best practices by default right, there are more things being built in and turned on by default which, is just kind of benefit from which. You don't have to manage yourself it's always gonna be a little hard enough to do for your specific application. Next, a lot of these new defaults and security patches automatically. And easily end up in your in your deployment because criminais, patches, you to the latest master version automatically, and you, can also enable node auto upgrade to get the latest version running on your notes we.
Talked About containers enabling a simpler. Patch management system for your environment that's. Not really helpful if you don't also patching kubernetes so use something like node auto upgrade to me that you and easier on yourself. In LA, say it works with the rest of GCP you can use I am audit, logging be pcs and other products that you're already familiar with as, part of your company's deployment in binary authorization, Canadian. Registry of all in the scanning they all work together as part of a broader picture you can use on GCP. So. If you want to learn more there's a couple links here our general container security overview and then the deep dives on the two of the two products that we talked about today, and. Please. Stay tuned for a live Q&A we'll be back in less than a minute thanks. Welcome. Back everyone and now, let's go over some of your questions first. Question that we got was how. Do I use graffities. With, Chris. I'll. Take that one so, krafayis, provides, a open source metadata, format. An API, for. Users. To, conveniently. Store. And. Retrieve. Metadata, associated. With containers credits. Provides the enforcement, piece of that story so, can you can imagine that you use Gracias to store metadata such as vulnerability. Findings or verifiable. Butte record that describes. How your containers are Bute and, then. Use kritis, to. Define how you want to enforce, deployment, using, those information. Stored in Gracias as we. Mentioned earlier that there. Are you can have a locally. Hosted graphics, instance, or you, can have a gracias. Implementation. As hosted by GC P which is the, GC. Container. Analysis, API, kritis. Or by normalization works, with both, implementations. With. Kritis we, provide a open. Source designer that. You can define, what, is acceptable. In a water ability finding or in, a verifiable. Boot Record that you, would. Generate. Attestation, only if an image has, the. Recommended. Viewed. Our record. As well as one, ability levels. Which. Can be saying enforced, a deploy time so in short graphics, provides a metadata piece that, you can. Insert. And retrieve, an examining, metadata Chris provides the deploy time enforcement. Piece and they do work together, awesome. Awesome our, next question is why. Use a central, metadata repository and, why not put this data with the container using labels. Um. The sorcerer for that is is because, containers. Are immutable and. Labels. Are considered, part, of a container image, so, when a label change the. Identifier. Of a container would also change which is the digest, to digest, container is content-addressable. So. This doesn't really work well we, want to attach. Mutable. Metadata such as image. Findings. Vulnerability. Findings or test results, that, are generated. After a, container is beaut that. Is why we choose to keep the metadata outside, of the image, it, will also make a decouple it from image, the repository. And easier. To integrate. With different, systems, that you may have in your RC, ICD workflow. Our. Next question for you one does, Warner ability scanning cover Sentosa OS currently. It, doesn't cover it but it's something that we're actively working on and we, will really support for, both centaurs. And Red, Hat soon we'll share more details in the near future but it's one of the top requests that we received and we're actively working on and support for those two distributions. Next. Question for Santa how. Should, I manage, the keys for my attestation authorities. Yep. So, you. Would. Manage the keys yourself. We. Currently don't have a key management solution, integrated, with minor associations so if. You have a tester. That is doing the signing, that. A tester, would, have access to the private signing key and as. A public key will be uploaded. Into binary, authorization, policy, so that you can use the public key to verify the, signature, as the. Image, get. Deployed. But. For now you'll be the one managing the, private, key private signing, hits yourself. Next. One what. Partners can use with vulnerability scanning so. Currently. They're. Not directly exposed in the GC are you either I showed you but there's, work ongoing in the cloud security command, center that and. There are integrations. Happening, from different partners including, twistlock, for example and basically. In the CSEC you'll be able to access the, vulnerability. Findings from different providers one, provider is DCR vulnerability, scanning the, other providers, are for example the ones that I mentioned before and you'll be able to see a full list of they and you'll be able to organize these data in one, location and it's, also aggregated.
Across Projects, so it's a it's a great tool and I highly recommend you guys look into it. Bullets, discovered, by GC are all ability scanning applied, to any of my running environments, it's a really good question great questions on there and that's a question that we fir consistently, as, part of our conversations, with customers and it's, something that we're also actively, working on we understand, that there's a lot of value in finding a modern abilities, but then the, the, key impact is knowing, are these vulnerabilities, in, any, of my running environments, and that's, why we're actively working on the plumbing history, to vulnerability. Scanning and we, also have more details on that some but it's something that we're actively working. Alright. Thank you stay, tuned for the next session see, ecat buting, startup light. Nighter. With GCP, thank you thank. You. You.
2018-09-01