Closed abhisek closed 3 years ago
KIND is a great project to look at for this due to
KIND will take care of the manifest driven cluster deployment. In this project, we just provide different KIND manifests for setting up different clusters with issues.
Hello @abhisek
Thank you so much for the detailed writeup of the roadmap. Yes indeed I had similar thoughts. Given the current situation, it's pretty difficult to set up the cluster environment same for all the cloud providers and locally, etc. So that's the one of the main reasons for not giving the cluster setup and assuming the user already has working Kubernetes cluster access. I have already thought of using KIND, Minikube and also even vagrant based 3 node clusters to provide as part of the Kubernetes Goat. But it ends up taking time to fix those issues rather than learning.
That's the reason I had to create Katacoda playground as well. So thinking in that direction, KIND would be easier to adopt and use for Kubernetes Goat.
Indeed I would love to go in the direction where we can showcase entire end to end Kubernetes vulnerabilities including older versions of CVE's, for example CVE-2018-1002105
only exists in specific version and specific service. I am still working on understanding better usage of KIND to create this environment as it has some limitations while setting the environment which are intentionally vulnerable.
But, I am really happy to see great feedback and inputs. Would love to see PR's and if you have any other inputs for KIND configuration working setup as well. In the meantime I will go ahead and create ROADMAP.md
with all the details and things which are in my mind and your valuable feedback :)
Thank you so much!
Thank you so much once again for the detailed info. Closing this and tracking the roadmap at https://github.com/madhuakula/kubernetes-goat/blob/master/roadmap.md
Moving this to done. As the KIND setup is already available for the Kubernetes Goat.
Kubernetes Goat can be a great project to setup different type of vulnerable Kubernetes environment based on a configuration manifest. Currently, it demonstrates common attack surface against a default cluster, by introducing vulnerable config + apps.
While this is great to get started for security assessment of workloads hosted in a cluster, to be able to test a cluster itself, especially those that are self-managed or a very old cluster provided in the cloud and subsequently upgraded.
We need to be able to, as a roadmap:
api-server
insecure port exposure, poor credentials in tokens file, kubelet read-only port issue etc.Most of this will require ability to setup a cluster from scratch with custom config (or patches as they call it for KIND).