github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-09-12 20:57:20 +00:00
Code Issues Projects Releases Wiki Activity

remove cmd respect for auth-path

Browse Source
This commit is contained in:
deads2k
2015-05-08 16:26:27 -04:00
parent 97004c87c1
commit 6498fc1fda
33 changed files with 49 additions and 98 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
docs/kubeconfig-file.md
View File

@@ -49,36 +49,6 @@ users:
client-key: path/to/my/client/key
```
## .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.
## 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. Get the kubeconfig from disk. This is done with the following hierarchy and merge rules:
@@ -108,8 +78,8 @@ The rules for loading and merging the kubeconfig files are straightforward, but
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.
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. Load precedence is 1) command line flag, 2) user fields from kubeconfig
1. The command line flags are: `client-certificate`, `client-key`, `username`, `password`, and `token`.
1. If there are two conflicting techniques, fail.
1. For any information still missing, use default values and potentially prompt for authentication information