***Fix for [CVE-2018-1002103](https://github.com/kubernetes/minikube/issues/3208): Dashboard vulnerable to DNS rebinding attack**[#3210](https://github.com/kubernetes/minikube/pull/3210)
* Initial support for Kubernetes 1.12+ [#3180](https://github.com/kubernetes/minikube/pull/3180)
* Use "kubectl proxy" instead of a NodePort to expose the dashboard [#3210](https://github.com/kubernetes/minikube/pull/3210)
* Enhance the Ingress Addon [#3099](https://github.com/kubernetes/minikube/pull/3099)
* Upgrade cni and cni-plugins to release version [#3152](https://github.com/kubernetes/minikube/pull/3152)
* ensure that /dev has settled before operating [#3195](https://github.com/kubernetes/minikube/pull/3195)
...
...
@@ -12,6 +12,7 @@
* Install crictl from binary instead of from source [#3160](https://github.com/kubernetes/minikube/pull/3160)
* Switch the source of libmachine to machine-drivers. [#3185](https://github.com/kubernetes/minikube/pull/3185)
* Add psmisc package, for pstree command [#3161](https://github.com/kubernetes/minikube/pull/3161)
* Significant improvements to kvm2 networking [#3148](https://github.com/kubernetes/minikube/pull/3148)
Huge thank you for this release towards our contributors:
- Anders F Björklund
...
...
@@ -20,6 +21,7 @@ Huge thank you for this release towards our contributors:
Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day.
# Newsflash
- 2018-10-05: minikube v0.30.0 released, addressing **[CVE-2018-1002103](https://github.com/kubernetes/minikube/issues/3208): Dashboard vulnerable to DNS rebinding attack**
## Installation
### macOS
```shell
...
...
@@ -124,7 +128,8 @@ We also released a Debian package and Windows installer on our [releases page](h
## Quickstart
Here's a brief demo of Minikube usage.
If you want to change the VM driver add the appropriate `--vm-driver=xxx` flag to `minikube start`. Minikube supports
- If you want to change the container runtime, network details, consult notes from your container runtime provider.
- If you want to change the VM driver add the appropriate `--vm-driver=xxx` flag to `minikube start`. Minikube supports
* none (**Linux-only**) - this driver can be used to run the Kubernetes cluster components on the host instead of in a VM. This can be useful for CI workloads which do not support nested virtualization.
* none (**Linux + docker daemon as container runtime only**) - this driver can be used to run the Kubernetes cluster components on the host instead of in a VM. This can be useful for CI workloads which do not support nested virtualization.
Edit the minikube `Makefile`, updating the version number values at the top:
## Bump the version in the Makefile and Update Docs to reflect this
*`VERSION_MINOR` (and `VERSION_MAJOR`, `VERSION_BUILD` as necessary)
*`ISO_VERSION` (only update this if there is a new ISO release)
See [this PR](https://github.com/kubernetes/minikube/pull/165) for an example.
## Run Local Integration Test
##Send an initial commit with the Makefile change:
With the updated Makefile, run the integration tests and ensure that all tests pass:
Send a PR for the Makefile change and wait until it is merged. Once the commit is merged, continue.
```shell
env TEST_ARGS="-minikube-start-args=--vm-driver=kvm2" make integration
```
## Build the Release
## Ad-Hoc testing of other platforms
Run this command:
If there are supported platforms which do not have functioning Jenkins workers (Windows), you may use the following to build a sanity check:
```shell
BUILD_IN_DOCKER=y make cross checksum
```
## Add the version to the releases.json file
## Send out Makefile PR
Add an entry **to the top** of deploy/minikube/releases.json with the **version** and **checksums**.
Send a PR.
This file controls the auto update notifications in minikube.
Only add entries to this file that should be released to all users (no pre-release, alpha or beta releases).
The file must be uploaded to GCS before notifications will go out. That step comes at the end.
This will update users of HEAD to the new ISO.
The schema for this file can be found in deploy/minikube/schema.json.
Please pay attention to test failures, as this is our integration test across platforms. If there are known acceptable failures, please add a PR comment linking to the appropriate issue.
An automated test to verify the schema runs in Travis before each submit.
## Update Release Notes
## Upload to GCS:
Run the following script to update the release notes:
Merge the output into CHANGELOG.md. See [PR#3175](https://github.com/kubernetes/minikube/pull/3175) as an example. Then get the PR submitted.
## Tag the Release
Run a command like this to tag it locally: `git tag -a v0.2.0 -m "0.2.0 Release"`.
Run a command like this to tag it locally: `git tag -a v<version> -m "<version> Release"`.
And run a command like this to push the tag: `git push upstream v<version>`.
## Build the Release
This step uses the git tag to publish new binaries to GCS and create a github release:
And run a command like this to push the tag: `git push upstream v0.2.0`.
* navigate to the minikube "Release" jenkins job
* Ensure that you are logged in (top right)
*`VERSION_MAJOR`, `VERSION_MINOR`, and `VERSION_BUILD` should reflect the values in your Makefile
* For `ISO_SHA256`, run: `gsutil cat gs://minikube/iso/minikube-v<version>.iso.sha256
* Click *Build*
## Create a Release in Github
## Update releases.json
Create a new release based on your tag, like [this one](https://github.com/kubernetes/minikube/releases/tag/v0.2.0).
minikube-bot will send out a PR to update the release checksums at the top of `deploy/minikube/releases.json`. Make sure it is submitted, or hack one together yourself.
Upload the files, and calculated checksums.
This file is used for auto-update notifications, but is not active until releases.json is copied to GCS.
## Upload the releases.json file to GCS
## Upload releases.json to GCS
This step makes the new release trigger update notifications in old versions of Minikube.
@@ -116,11 +107,11 @@ The repository is tracked in this repo under a submodule `installers/linux/arch_
To actually update the package, you should bump the version and update the sha512 checksum. You should also run `makepkg --printsrcinfo > .SRCINFO` to update the srcinfo file. You can edit this manually if you don't have `makepkg` on your machine.
## Release Verification
## Verification
After you've finished the release, run this command from the release commit to verify the release was done correctly:
`make check-release`.
## Update kubernetes.io docs
If there are major changes, please send a PR upstream for this file https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/getting-started-guides/minikube.md in order to keep the getting started guide up to date.
If there are major changes, please send a PR to update the official setup guide: [Running Kubernetes Locally via Minikube](https://kubernetes.io/docs/setup/minikube/)
This document is written for system integrators who are familiar with minikube, and wish to run it within a customized VM environment.
`--vm-driver=none` allows advanced minikube users to skip VM creation, allowing minikube to be run on a user-supplied VM.
## What operating systems are supported?
`--vm-driver=none` supports releases of Debian, Fedora, and buildroot that are less than 2 years old.
While the standard minikube guest VM uses buildroot, minikube integration tests are also regularly run against Debian 9 for compatibility. In practice, any systemd-based modern distribution is likely to work, and we will happily accept pull requests which improve compatibility with other systems.
## Should vm-driver=none be used on a personal development machine? No.
No. Please do not do this, ever.
minikube was designed to run Kubernetes within a dedicated VM, and when used with `--vm-driver=none`, may overwrite system binaries, configuration files, and system logs. Executing `minikube --vm-driver=none` outside of a VM could result in data loss, system instability and decreased security.
Usage of `--vm-driver=none` outside of a VM could also result in services being exposed in a way that may make them accessible to the public internet. Even if your host is protected by a firewall, these services still be vulnerable to [CSRF](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)) or [DNS rebinding](https://en.wikipedia.org/wiki/DNS_rebinding) attacks.
## Can vm-driver=none be used outside of a VM?
Yes, but only after appropriate security and reliability precautions have been made. `minikube --vm-driver=none` assumes complete control over the environment is is executing within, and may overwrite system binaries, configuration files, and system logs.
The host running `minikube --vm-driver=none` should be:
* Isolated from the rest of the network with a firewall
* Disposable and easily reprovisioned, as this mode may overwrite system binaries, configuration files, and system logs
If you find yourself running a web browser on the same host running `--vm-driver=none`, please see __Should vm-driver=none be used on a personal development machine? No.__
## Known Issues
* You cannot run more than one `--vm-driver=none` instance on a single host #2781
*`--vm-driver=none` deletes other local docker images #2705
*`--vm-driver=none` fails on distro's which do not use systemd #2704
* Many `minikube` commands are not supported, such as: `dashboard`, `mount`, `ssh`, `stop` #3127