apiserver unusable via kubernetes svc when using --extra-config=apiserver.ServiceClusterIPRange= due to TLS server names

[donaldguy]

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Environment:

Minikube version (use minikube version): v0.22.1

• OS macOS 10.12.6
• VM Driver : virtualbox
• ISO version: minikube-v0.23.3.iso / testing

I am seeing both dashboard and other addons failing with logs like

Error while initializing connection to Kubernetes apiserver. This most likely means that the cluster is misconfigured (e.g., it has invalid apiserver certificates or service accounts configuration) or the --apiserver-host param points to a server that does not exist. Reason: Get https://100.69.0.1:443/version: x509: certificate is valid for 192.168.99.100, 10.0.0.1, not 100.69.0.1

It would appear that the cert being generated for the API server is not getting an alternative service range as an Alternate Name

indeed

$ minikube ssh
                         _             _
            _         _ ( )           ( )
  ___ ___  (_)  ___  (_)| |/')  _   _ | |_      __
/' _ ` _ `\| |/' _ `\| || , <  ( ) ( )| '_`\  /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )(  ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ cd /var/lib/localkube/certs
$ cat apiserver.crt

copy output to macOS clipboard

$ pbpaste | openssl x509 -in /dev/stdin -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=minikubeCA
        Validity
            Not Before: Sep 26 16:38:12 2017 GMT
            Not After : Sep 26 16:38:12 2018 GMT
        Subject: O=system:masters, CN=minikube
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:bf:ad:85:32:c8:04:17:54:a6:d0:46:e4:75:ac:
                    14:11:32:ce:54:3b:e4:08:48:49:88:f6:17:33:94:
                    cd:4e:6e:46:55:a4:b9:53:6a:35:bf:0b:62:52:a3:
                    f7:56:c5:71:39:a9:c3:73:0a:57:5f:89:7c:82:b7:
                    a9:2b:e4:e7:a2:d2:c8:ef:9a:19:96:9f:28:4d:8b:
                    0c:6f:3b:d8:e0:08:c1:22:51:7f:89:36:e7:07:40:
                    bb:d8:de:71:50:0b:8c:5f:bc:0b:6a:8b:e2:a1:f8:
                    2d:08:7d:cb:f6:bc:a7:a1:b1:d1:05:b5:0d:99:d7:
                    02:83:fb:a3:6e:e8:d9:f5:c4:5f:ba:ba:fa:b1:a4:
                    5c:65:d0:56:7c:fe:b5:dc:b8:9e:45:ea:13:ae:68:
                    5a:d5:f3:ab:68:34:61:5c:b9:cb:55:e6:f7:c5:16:
                    69:56:a6:07:0c:1a:f5:d1:cb:92:09:83:55:f3:52:
                    97:90:b2:77:88:7b:fa:b0:02:2c:ed:e1:2b:f3:b7:
                    b2:8c:2e:6b:ad:80:c2:96:40:2f:ce:8b:5c:21:eb:
                    c9:23:fd:ce:18:c4:e8:bc:1d:b4:43:9c:82:7a:77:
                    05:3a:38:2e:ce:fe:c9:fd:af:ac:5c:77:b4:c4:31:
                    d3:4f:2c:72:9d:cd:3f:c3:3f:3c:e2:7c:87:7c:f3:
                    19:4d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Alternative Name:
                DNS:kubernetes.default.svc.cluster.local, DNS:kubernetes.default.svc, DNS:kubernetes.default, DNS:kubernetes, DNS:localhost, IP Address:192.168.99.100, IP Address:10.0.0.1

This is presumably the cause of e.g. #1536

[donaldguy]

raw logs for start and logs here: https://gist.github.com/donaldguy/1de948b037ddaf4102b0147039159422

[donaldguy]

Looks to be hardcoded in the bootstraper through

minikube/pkg/minikube/bootstrapper/certs.go

Line 42 in 023aea1

internalIP = net.ParseIP(util.DefaultServiceClusterIP)

to

minikube/pkg/util/constants.go

Line 25 in 023aea1

DefaultServiceClusterIP = "10.0.0.1"

[r2d4]

Closing as a dupe of #1747. This is definitely an issue, but we'll need to fix both the DNS addon and the apiserver to properly respect this flag.