You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: