fixed typos (#777)

* fixed typos

* Update container-image-vulnerability-adaptor.md
This commit is contained in:
Krishna Agarwal
2022-09-06 12:11:18 +05:30
committed by GitHub
parent 52aa5f02e2
commit f7f11abfc2

View File

@@ -6,12 +6,12 @@ source #287
### Big picture
* Kubescape team is planning to create controls which take into account image vulnerabilities, example: looking for public internet facing workloads with critical vulnerabilities. These are seriously affecting the security health of a cluster and therefore we think it is important to cover it. We think that most container registries are/will support image scanning like Harbor and therefore, the ability to get information from them is important.
* There is information in the image repository which is important for the existing controls as well. They are incomplete without it, example see this issue: Non-root containers check is broken #19 . These are not necessarily image vulnerability related. Can be information in the image manifest (like the issue before), but it can be the image BOM related.
* Kubescape team is planning to create controls which take into account image vulnerabilities, for example: looking for public internet facing workloads with critical vulnerabilities. These are seriously affecting the security health of a cluster and therefore we think it is important to cover it. We think that most container registries are/will support image scanning like Harbor and therefore, the ability to get information from them is important.
* There is information in the image repository which is important for the existing controls as well. They are incomplete without it, this example sees this issue: Non-root containers check is broken #19. These are not necessarily image vulnerability related. These can be information in the image manifest (like the issue before), but it can also be the image BOM related.
### Relation to this proposal
Multiple changes and design decisions need to be made before Kubescape will support the above outlined controls. However, a focal point in the whole picture is the ability to access vulnerability of databases of container images. We anticipate that most container image repositories will support image vulnerability scanning, like some major players already do. Since there is no single API available which all of these data sources support, it is important to create an adaption layer within Kubescape so that different datasources can serve Kubescape's goals.
Multiple changes and design decisions need to be made before Kubescape will support the above outlined controls. However, a focal point in the whole picture is the ability to access vulnerability of databases of container images. We anticipate that most container image repositories will support image vulnerability scanning, like some major players already do. Since there is no single API available which all of these data sources support, it is important to create an adaption layer within Kubescape so that different data sources can serve Kubescape's goals.
## High level design of Kubescape
@@ -22,7 +22,7 @@ Multiple changes and design decisions need to be made before Kubescape will supp
* Rules processor: Kubescape component, it enumerates and runs the controls while also preparing all the input data that the controls need for running
* Data sources: Set of different modules providing data to the Rules processor so that it can run the controls with them. Examples: Kubernetes objects, cloud vendor API objects and adding the vulnerability information in this proposal
* Cloud Image Vulnerability adaption interface: The subject of this proposal, it gives a common interface for different registry/vulnerability vendors to adapt to.
* CIV adaptors: Specific implementation of the CIV interface, example Harbor adaption
* CIV adaptors: Specific implementation of the CIV interface, for example Harbor adaption
```
-----------------------
| Controls/Rules (rego) |