Change:
token: blue-token - name: green-user user: <ins> username: admin password: secret </ins> client-certificate: path/to/my/client/cert client-key: path/to/my/client/key ``` <ins> ## .kubernetes_auth files **WARNING**: merging auth from a mixture of kubernetes_auth file entries and .kubeconfig user entries is hard to debug and should be avoided. kubernetes_auth file support exists mostly for tests and is being deprecated. The kubernetes_auth file is a legacy config file that can contain a mix of server and client auth info. It is supported in .kubeconfig via `auth-path` for a user: ``` users: - name: black-user user: auth-path: path/to/my/existing/.kubernetes_auth_file ``` The entries in a file loaded via auth-path will be applied to both the user and cluster of the current context. ### Example .kubernetes_auth file ``` { "User": "admin", "Password": "secret", "CertFile": "/path/to/my/client/cert", "KeyFile": "/path/to/my/client/key", "CAFile": "/path/to/my/server/cafile", "BearerToken": "secrettoken", "Insecure": false } ``` All entries are optional. `User`, `Password`, `CertFile`, `KeyFile`, and `BearerToken` are applied to the kubectl user. `CAFile` and `Insecure` apply to the cluster. Note that it is invalid to set both `CAFile` and `Insecure`, or both `BearerToken` and `User,Password` (see loading and merging rules below). If the contents of the kubernetes_auth file conflict with entries in .kubeconfig, they are ignored. E.g, if the .kubeconfig cluster specifies a `certificate-authority`, and the user specifies an `auth-path` to a kubernetes_file that contains a `CAFile` entry, the former will be used and the latter ignored. </ins> ## Loading and merging rules The rules for loading and merging the .kubeconfig files are straightforward, but there are a lot of them.  The final config is built in this order: 1.  Merge together the kubeconfig itself.  This is done with the following hierarchy and merge rules: Empty filenames are ignored.  Files with non-deserializable content produced errors. The first file to set a particular value or map key wins and the value or map key is never changed. This means that the first file to set CurrentContext will have its context preserved.  It also means that if two files specify a "red-user", only values from the first file's red-user are used.  Even non-conflicting entries from the second file's "red-user" are discarded.

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.