Octant leaks the cluster's admin.conf and a malicious pod/exposid worker node can gain cluster administrator privileges #3370
Description
Summary
When Octant deployed in the Kubernetes cluster as a pod, it leaks the cluster's admin.conf and a malicious pod/exposed worker node can gain cluster administrator privileges
What steps did you take and what happened:
1.Deploy Octant as a Pod:
Because Octant does not provide any official guide for deploying the Octant as a pod in a Kubernetes cluster, I deploy the Octnat as a Pod following the guide of antrea.io(https://antrea.io/docs/v1.9.0/docs/octant-plugin-installation/)
kubectl create secret generic octant-kubeconfig --from-file=admin.conf=/home/younaman/.kube/conf -n kube-system
kubectl apply -f https://github.com/antrea-io/antrea/blob/main/build/yamls/antrea-octant.yml
2.Access Octant Web Service from a pod/worker node:
Octant automatically loads admin.conf when it starts up, and accesses the UI with the kubernetes-admin context.
A malicious pod can easily obtain the "data" of the secret named "octant-kubeconfig" from the "Config and Storage/Secret/" in dashboard UI, which is my cluster's admin.conf, and do whatever he/she likes to the whole cluster.
What did you expect to happen:
It looks like the Octant intended to be run as a desktop/client application, and the Octant has no access control to deploy inside a cluster at all. As far as I am concerned, the Octant should enable the authentication feature(i.e., ask for token or kubeconfig when a user access the dashboard UI), and do not use the cluster's admin.conf to access the cluster automatically when accessing the dashboard UI
Anything else you would like to add:
As mitigation, I try to mitigate the risk following these steps:
1.Do not use the "admin.conf" to deploy and install the Octant:
This will prevent Octant from finding /kube/admin.conf from KUBECONFIG on startup, and the Octant can not create context automatically. As a result, the Octant will force the user to upload the admin.conf they have when they first access the
web service. And create context according to the file upload by user.
To be more specifically, it triggers the func (l *LoadingManager) UploadKubeConfig(), which create a temporary file named kubeconfigxxxxxxxx under the /tmp/octant directory. And the
Octant create context according to this temporary file.
For example:
kubectl create secret generic octant-kubeconfig --from-file=/home/younaman/.kube/conf -n kube-system.
kubectl apply -f https://github.com/antrea-io/antrea/blob/main/build/yamls/antrea-octant.yml
2.Restart the Octant pod after each access to the dashboard UI. Thus, the Octant can not find /kube/admin.conf on start up, and will force the user to upload his/her own admin.conf and create a
new /tmp/octant/kubeconfigxxxxxxxx temporary file.
Please notice that this so-called "mitigation method requires a lot of manual steps. To solve this problem fundamentally, the Octnat may need to add authentication/ access control restrictions when accessing the dashboard UI.
Environment:
- Octant version (use
octant version):
Version: 0.24.0
Git commit: 5a86489
Built: 2021-09-09T01:54:00Z - Kubernetes version (use
kubectl version):
Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.2", GitCommit:"f66044f4361b9f1f96f0053dd46cb7dce5e990a8", GitTreeState:"clean", BuildDate:"2022-06-15T14:22:29Z", GoVersion:"go1.18.3", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.4
Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.2", GitCommit:"f66044f4361b9f1f96f0053dd46cb7dce5e990a8", GitTreeState:"clean", BuildDate:"2022-06-15T14:15:38Z", GoVersion:"go1.18.3", Compiler:"gc", Platform:"linux/amd64"} - OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc):
A three-node Kubernetes cluster, each node is Ubuntu 20.04 TLS.
By the way, I have reported this vulnerability by mailing the [email protected], but there is no response last three weeks. So I report this issue through github.
Activity