kubernetes
/
minikube
mirror of https://github.com/kubernetes/minikube.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Make sure data loss gets mentioned.

pull/3734/head
Thomas Strömberg 2019-02-19 10:32:54 -08:00 committed by GitHub
parent 7ba606396a
commit 89a0c4fe2e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 39 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
docs/vmdriver-none.md
View File

@ -12,29 +12,55 @@ The `none` driver supports releases of Debian, Ubuntu, and Fedora that are less
## Can the none driver be used outside of a VM?
Not if you can avoid it.
Yes, but please avoid it if possible.
minikube was designed to run Kubernetes within a dedicated VM, and assumes that it has complete control over the machine it is executing on. With the `none` driver, minikube will overwrite the following system paths:
minikube was designed to run Kubernetes within a dedicated VM, and assumes that it has complete control over the machine it is executing on. With the `none` driver, minikube and Kubernetes run in an environment with very limited isolation, which could result in:
* Decreased security
* Decreased reliability
* Data loss
We'll cover these in detail below:
### Decreased security
* minikube starts services that may be available on the Internet. Please ensure that you have a firewall to protect your host from unexpected access. For instance:
* apiserver listens on TCP *:8443
* kubelet listens on TCP *:10250 and *:10255
* kube-scheduler listens on TCP *:10259
* kube-controller listens on TCP *:10257
* Containers may have full access to your filesystem.
* Containers may be able to execute arbitrary code on your host, by using container escape vulnerabilities such as [CVE-2019-5736](https://access.redhat.com/security/vulnerabilities/runcescape). Please keep your release of minikube up to date.
### Decreased reliability
* minikube with the none driver may be tricky to configure correctly at first, because there are many more chances for interference with other locally run services, such as dnsmasq.
* When run in `none` mode, minikube has no built-in resource limit mechanism, which means you could deploy pods which would consume all of the hosts resources.
* minikube and the Kubernetes services it starts may interfere with other running software on the system. For instance, minikube will start and stop container runtimes via systemd, such as docker, rkt, containerd, cri-o.
### Data loss
With the `none` driver, minikube will overwrite the following system paths:
* /usr/local/bin/kubeadm
* /usr/local/bin/kubectl
* /etc/kubernetes
It will also install `kubelet` as a systemd service, as well as start/stop container runtime services if installed.
These paths will be erased when running `minikube delete`:
## Security Limitations
* /data/minikube
* /etc/kubernetes/manifests
* /var/lib/minikube
With the `none` driver, minikube has limited container isolation abilities. Applications running in a container may be able to access your host filesystem. Through using a container escape vulnerability such as [CVE-2019-5736](https://access.redhat.com/security/vulnerabilities/runcescape), they may also be able to execute arbitrary code on your host.
When using the `none` driver, it is highly recommended that your host is isolated from the rest of the network using a firewall.
Additionally, minikube with the `none` driver has a very confusing permissions model, as some commands need to be run as root ("start"), and others by a regular user ("dashboard"). In a future release, we intend to disallow running `minikube`, and instead call into `sudo` when necesarry to avoid permissions issues.
## Uninstalling
The `none` driver now supports uninstallation via `minikube delete`. Please note that it will not fully remove /etc/kubernetes, since it does not track which files in /etc/kubernetes existed before the installation.
As Kubernetes has full access to both your filesystem as well as your docker images, it is possible that other unexpected data loss issues may arise.
## Known Issues
* You cannot run more than one `--vm-driver=none` instance on a single host
* Many `minikube` commands are not supported, such as: `dashboard`, `mount`, `ssh`
* minikube with the `none` driver has a confusing permissions model, as some commands need to be run as root ("start"), and others by a regular user ("dashboard")
* CoreDNS detects resolver loop, goes into CrashloopBackoff - [#3511](https://github.com/kubernetes/minikube/issues/3511)
* [Full list of issues](https://github.com/kubernetes/minikube/labels/co%2Fnone-driver)