Change:
1.  command line arguments - `server`, `api-version`, `certificate-authority`, and `insecure-skip-tls-verify` 1.  If cluster info is present and a value for the attribute is present, use it. 1.  If you don't have a server location, error. <del> 1.  User is build using the same rules as cluster info, EXCEPT that you can only have one authentication  technique per user. The command line flags are: `auth-path`, `client-certificate`, `client-key`, and `token`.  If there are two conflicting techniques, fail. </del> <ins> 1.  Determine the actual user info to use. User is built using the same rules as cluster info, EXCEPT that you can only have one authentication technique per user. 1. Load precedence is 1) command line flag, 2) user fields from .kubeconfig, 3) kubernetes_auth file fields (if user has a `auth-path` or the `--auth-path` was provided) 1. The command line flags are: `auth-path`, `client-certificate`, `client-key`, `username`, `password`, and `token`. 1. If there are two conflicting techniques, fail. </ins> 1.  For any information still missing, use default values and potentially prompt for authentication information ## Manipulation of .kubeconfig via `kubectl config <subcommand>`

Discussion:
After installing nginx on the kubernetes master (currently non-k8s docker container) and forwarding external http requests to the kubernetes-ro service through nginx with simple htpasswd auth, I tested it (to use within CI tool), but it failed to pass nginx. Is it because we are required to use https when querying the apiserver using kubectl? Or because the -a option is used for a different auth ? How would you solve this issue ? Thank you in advance!
I tried to run kubectl proxy in one shell and query kubectl get in the other, without success: Shell 1 Shell 2
Looks like the isn't forwarding authorization as expected? Can you take a look please?
takes a full qualified URL. If you pass the plain ip string it will do a get over http, which the apiserver correctly rejects. Replace with and it should work as expected. Note that if you set up a kubeconfig file you can avoid some of this pain. Run for help/commands to set up a kubeconfig.
Please reopen if the above does not work for you.
I understood that I cannot use kubectl with remote server through http, so I modified my nginx to support ssl. I still have a problem with the or parameter. Is the kubernetes_auth supposed to have a different format maybe? I do not have the option to reopen the ticket. thanks for the kubectl config tip. But it's only a v0.9+ feature, so I'll try it when I upgrade later from v0.8.1
after testing , I came up with that kubeconfig: Still getting the same error:
That config looks fine. message is usually a json unmarshalling error. I wonder if there might be something wrong with your .kubernetes_auth file? It should look like
Sorry, forgot to come back here after solving the issue. Correct, the problem was with the kubernetesauth file. The keys must be capitalized, and I was trying This naming convention should be better documented, or more useful error should be raised. Neither the Json standard (ECMA) nor the JSON-RPC specs are requiring capitalized keys. Renaming this issue to "kubernetesauth missing documentation"
Thanks Adrien. I think the right thing to do here is raise an error if the kubernetes_auth file exists but doesn't have the required keys.
JSON RPC states that identifiers must be case-sensitive.