isHttpsAvailable isn't reliable

[willthames]

Doing a GET on https://$KUBERNETES_MASTER/ to decide whether isHttpsAvailable is problematic

• Most roles without full cluster permissions are unable to GET / - whereas all authenticated users are in the system:discovery group which could call GET /api for example

$ curl k -H "Authorization: Bearer $KUBERNETES_TOKEN" https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT/
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "forbidden: User \"system:serviceaccount:default:default\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {
    
  },
  "code": 403
}

$ curl k -H "Authorization: Bearer $KUBERNETES_TOKEN" https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT/api
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "ip-10-0-167-167.ap-southeast-2.compute.internal:443"
    }
  ]
}

• There is no distinction made between an unauthorized response (log an error and bomb out) and being unable to talk HTTPS to an HTTP server

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[manusa]

kubernetes-client/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/internal/SSLUtils.java

Line 71 in 64bdd32

return response.isSuccessful();

Should consider 403 status too as a valid option. Probably even any status code (except 5**) should be considered since the SSL handshake was successful.