kubernetes: Cluster tab freezes after entering wrong server definition

[jniederm]

Cluster tab get stuck if wrong server configuration is entered - correct api server address but authentication is left unchecked even-though actually required.

version: master, commit 6befb5a

steps to reproduce:

1. Log in to Cockpit as 'root' user
2. In server adding dialog enter address to kube-apiserver, check "Skip certificate verification", uncheck "Requires authentization"
3. Confirm the dialog

Actual result: Server adding dialog is stuck with a moving spinner, when page is reloaded, the cluster tab is stuck with moving spinner.

workaround: delete /root/.kube/config

[petervo]

Are you sure the connection doesn't time out after a while. That's what happens for me. If that is not the case that's a separate bug from the dialog accepting no auth when it shouldn't. If it doesn't timeout, do you have any logs in the browser console?

The accepting no auth thing is a known problem. The basic issue is kubernetes has changed a lot since this was written and now between different bugs in different possible versions and configurations of kubernetes it is really convoluted and hard to answer the questions did these credentials work? and do they grant the access we need?

There are two issues. If we present login creds it's we don't always get a straight answer to the question of were they accepted or if they just let us through as system:anonymous. Kubernetes needs a better way to check this. There's been various proposals but nothing has been accepted yet AFAIK. I've been meaning to write a proposed patch to https://kubernetes.io/docs/api-reference/v1.7/#subjectaccessreviewstatus-v1-authorization to provide the user id used to perform the access check. That way we can tell if we are system:anonymous or not. But I haven't gotten around to it yet. We've been using a ugly hack in the standalone auth mode to force bad creds and see what sort of response we get.

If we didn't present any creds we need to know if we have enough access or if we need more. This is complicated by the fact that what we need to work with openshift and stock kubernetes is a little different.

Anyways none of this is unsolvable and there are probably incremental solutions we can do, I just haven't had time to work on it. If you are up for submitting patches I'm happy to review and provide input based on the all the use cases and setups I've seen.

[jniederm]

Hi Peter, this bug was meant to be about the page being stuck on spinner. I haven't known about authentication problems.

I can't say it doesn't timeout (it's like halting problem) but it certainly doesn't timeout in reasonable time. The spinner is still there after 15 minutes.

[jniederm]

And the browser console prints nothing extra compared to case when connection is configured properly. I.e. it prints only:

Content Security Policy: The page’s settings blocked the loading of a resource at self (“default-src http://localhost:9090 http://localhost:9090”). Source: ;(function installGlobalHook(window) {
 ....  kubernetes:1
Content Security Policy: The page’s settings blocked the loading of a resource at self (“default-src http://localhost:9090 http://localhost:9090”). Source: !function(t){function __webpack_require_....  kubernetes:1
Content Security Policy: The page’s settings blocked the loading of a resource at self (“default-src http://localhost:9090 http://localhost:9090”). Source: !function(t){function __webpack_require_....  index.html:1
Content Security Policy: The page’s settings blocked the loading of a resource at self (“default-src http://localhost:9090 http://localhost:9090”). Source: !function(t){function __webpack_require_....  index.html:1

[petervo]

@jniederm ah ok. i was able to reproduce and opened #7707 that should fix the problem.