It is my understanding that kube-scan can only scan workloads that are already running in the cluster it is deployed in.
If kube-scan was able to scan workload configurations that are uploaded to it as YAML or JSON, it would open up a new set of possible use cases around preventing vulnerable workloads from ever reaching a cluster.
For example, an admission controller could use kube-scan to look for issues with incoming workloads and reject the workload if there is an issue with a score greater than a configurable threshold.
Another case would be a CI pipeline - the CI pipeline could send manifests to kube-scan before they are deployed and fail the deployment before it even reaches the cluster if there is an issue with a score greater than a certain threshold.
Similarly, a kubectl and/or Helm plugin could send manifests to kube-scan for checking before applying them, aborting the deployment if there is an issue with a score greater than a certain threshold.
I appreciate that there are some issues that could not be detected via this mechanism, where the wider cluster configuration/other resources are used to make a decision about a workload. However I think there are enough issues where detection is just based on the pod spec that this would still be useful.
It is my understanding that kube-scan can only scan workloads that are already running in the cluster it is deployed in.
If kube-scan was able to scan workload configurations that are uploaded to it as YAML or JSON, it would open up a new set of possible use cases around preventing vulnerable workloads from ever reaching a cluster.
For example, an admission controller could use kube-scan to look for issues with incoming workloads and reject the workload if there is an issue with a score greater than a configurable threshold.
Another case would be a CI pipeline - the CI pipeline could send manifests to kube-scan before they are deployed and fail the deployment before it even reaches the cluster if there is an issue with a score greater than a certain threshold.
Similarly, a kubectl and/or Helm plugin could send manifests to kube-scan for checking before applying them, aborting the deployment if there is an issue with a score greater than a certain threshold.
I appreciate that there are some issues that could not be detected via this mechanism, where the wider cluster configuration/other resources are used to make a decision about a workload. However I think there are enough issues where detection is just based on the pod spec that this would still be useful.