minikube stop working after upgrade to macOs Catalina

[franxois]

The exact command to reproduce the issue:

minikube version

The full output of the command that failed:

Original message in french

Impossible d’ouvrir « minikube-darwin-amd64 » car le développeur ne peut pas être vérifié.
macOS ne peut pas vérifier que cette app ne contient aucun logiciel malveillant.
Homebrew Cask a téléchargé ce fichier le 20 septembre 2019 depuis github.com.

That says Unable to open minikube because macOS can't verify this app

The output of the minikube logs command:

The operating system version:

This appends just after upgrade to macOS Catalina 10.15

minikube installed with brew cask

[afbjorklund]

Taking “closed” to a whole new level...

https://developer.apple.com/developer-id/

Mac apps, installer packages, and kernel extensions that are signed with Developer ID must also be notarized by Apple in order to run on macOS Catalina.

Guess minikube has to get a Developer ID for the App Store ?

[afbjorklund]

The “open anyway” button has now been moved to settings :
https://support.apple.com/en-us/HT202491

[franxois]

I don't have the open anyway button in settings but it look like I added an exception by using a first time "open with" Terminal.app on the binary in finder.
Now I can run minikube

[tdensmore]

Also using sudo spctl --master-disable should allow most command line binaries to work

http://osxdaily.com/2016/09/27/allow-apps-from-anywhere-macos-gatekeeper/

[myersg86]

Allow apps from anywhere and sudo spctl --master-disable disable protections that can potentially leave a Mac vulnerable to malware, and should be avoided if at all possible. This is not an ideal solution.

After taking the following steps, I now seem to have an "Open anyways" option now, allowing running individual applications without disabling secure defaults.

Here's what I did, not sure if all steps are relevant:

• Switch spctl off and on:

sudo spctl --master-disable
sudo spctl --master-enable

• Set "Allow apps downloaded from: App Store" in Security and Privacy
• Reboot

[benjma]

Maybe, "Allow Anyway" just for "minikube-darwin-amd64"

[findpritish]

Switch spctl off

sudo spctl --master-disable

brew cask install minikube
minikube start

Switch spctl on

sudo spctl --master-enable

[afbjorklund]

I'm not sure how this "new" Apple requirement can be integrated into minikube release process:

https://developer.apple.com/developer-id/

https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

Maybe @tstromberg can take a look at if and how such a workflow could be added to the CI ?

[edreams]

sudo chown root:wheel /Users/chile/.minikube/bin/docker-machine-driver-hyperkit
sudo chmod u+s /Users/chile/.minikube/bin/docker-machine-driver-hyperkit

[tstromberg]

Related: #5792

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[pre]

Came here to document that my issue in Catalina was that hyperkit requires Docker for Mac. Withtout it, minikube either hangs (using minikube start -p profile) or crashes (minikube start).
My installation didn't even get to the "minikube was blocked" security message.

My problem was solved by launching Docker for Mac which then asked security privileges for itself. After that, minikube was able to start.

Related: #5811 (comment)

[mjgallag]

New version of hyperkit with Catalina fix is finally available on Homebrew, see Homebrew/homebrew-core#50655 & moby/hyperkit#267 for details.

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.