Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API to scan workload configurations before they are deployed #32

Open
mkjpryor-stfc opened this issue Sep 10, 2020 · 0 comments
Open

API to scan workload configurations before they are deployed #32

mkjpryor-stfc opened this issue Sep 10, 2020 · 0 comments

Comments

@mkjpryor-stfc
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant