Replies: 1 comment 2 replies
-
|
Hi @mzc-lunar 🙌 Yes that sounds very much feasible and like a pefect addition :) One thing which is somewhat weakening is that deployments are just one way in kubernetes on how to run pods, there are also other workload types like StatefulSets, DaemonSets and Jobs & CronJobs (https://kubernetes.io/docs/concepts/workloads/controllers/), not to even mention the ones managed by operators and custom resources, so having a Deployment AutoDiscovery can unfortunatly only cover parts of whats possible in kubernetes. We have previously played with something like a "namespace" auto-discovery to then trigger tools like kubeaudit on the entire namespace to find missconfigurations. This would then create a scheduled kube-audit scan in every namespace when its created. This would make our life a bit easier in the securecodebox as then the tool like kubeaudit or trivy-k8s would basically take in everything it can audit / lint on the namespace level and we would not have to create individual controllers for each kind of workload in kubernetes. But unfortunatly this would mean that it would not auto trigger the scan when the deployment is updated but would have to wait until the scheduled scan is triggered again. If you want to try out adding a deployment controller you could maybe try if it is possible to make this generic enought to be a workload controller? So that it can cover all the native kubernetes workload. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I realise I'm simplifying things significantly by saying "on a deployment level". I think what I meant was workload, as we'd like to cover everything - not just deployments 🙂 Your namespace auto-discovery sounds more akin to scheduled scans, rather than auto-discovery, if I understand you correctly. This could also be something we would be interested in at some point for sure. However, as a first step I think the workload controller is more what we really have on the wish list. I will probably spend some time next week to look into how big of a time commitment it would be to make a contribution like that. It's good to hear that you think it could be a good idea 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Awesome 👏 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm looking into setting up scanning in our k8s cluster using SecureCodeBox. Initially, the idea is to do scanning using trivy and have it automatically scan "everything" in the cluster periodically. At first glance, the current AutoDiscovery feature with trivy looked super promising, however after looking a bit more into it, I noticed that currently only the
trivy imagescan is available.I’ve been taking a very cursory look into the auto-discovery operator and as far as I can tell there isn’t anything blocking my team from extending SCB to also support trivy’s
k8scommand. For us, we would like to do Trivy scans “at a deployment level” to get a reports that can contain multiple images. This would allow us to make trivy reports corresponding to github repositories, which is what we’re aiming for. But I imagine others would be interested in getting a trivy report on a namespace or cluster level, which would also be enabled by implementingtrivy k8sas an AutoDiscovery mode.So, a couple of questions:
Depending on your answer and the size of the task we could be interested in pursuing making this contribution, but I didn’t want to dive into it before getting the maintainers' take on it 🙂
Beta Was this translation helpful? Give feedback.
All reactions