From a4003ad766c8ecd9ba07ad433b682ef91bd6bb76 Mon Sep 17 00:00:00 2001 From: zacharysarah Date: Tue, 1 Aug 2017 13:38:15 -0700 Subject: [PATCH 1/6] Completed sentence, applied style guide to section --- ...authenticate-across-clusters-kubeconfig.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md index 82a7fe3c89..44e0ff5420 100644 --- a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md +++ b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md @@ -164,25 +164,24 @@ the settings relevant to the `current-context` by passing `--minify`. See ## Building your own kubeconfig file -NOTE, that if you are deploying k8s via kube-up.sh, you do not need to create your own kubeconfig files, the script will do it for you. +You can use the [sample kubeconfig file](#example-kubeconfig-file) above as a template for your own kubeconfig files. -In any case, you can easily use this file as a template to create your own kubeconfig files. +**Note:** If you're deploying Kubernetes with `kube-up.sh`, you don't need to create your own kubeconfig files—the script does it for you. +{: .note} -So, lets do a quick walk through the basics of the above file so you can easily modify it as needed... - -The above file would likely correspond to an api-server which was launched using the `--token-auth-file=tokens.csv` option, where the tokens.csv file looked something like this: +The sample file corresponds to an [API server](https://kubernetes.io/docs/admin/kube-apiserver/) launched using the `--token-auth-file=tokens.csv` option, where the `tokens.csv` file contains: ```conf blue-user,blue-user,1 mister-red,mister-red,2 ``` -Also, since we have other users who validate using **other** mechanisms, the api-server would have probably been launched with other authentication options (there are many such options, make sure you understand which ones YOU care about before crafting a kubeconfig file, as nobody needs to implement all the different permutations of possible authentication schemes). +**Note:** There are many [options available](https://kubernetes.io/docs/admin/kube-apiserver/) for launching an API server. Make sure you understand the options you include. +{: .note} -- Since the user for the current context is "green-user", any client of the api-server using this kubeconfig file would naturally be able to log in successfully, because we are providing the green-user's client credentials. -- Similarly, we can operate as the "blue-user" if we choose to change the value of current-context. +The sample kubeconfig file provides client credentials for the user `green-user`. Because the user for `current-context` is `green-user`, any client of the API server using the sample kubeconfig file could log in successfully. Similarly, we can operate as `blue-user` by changing the value of `current-context`. -In the above scenario, green-user would have to log in by providing certificates, whereas blue-user would just provide the token. All this information would be handled for us by the +In the example provided, `green-user` logs in by providing certificates, and blue-user provides a token. Login information is specified with the `kubectl config set-credentials` command. For more information, see "[Commands for the example file](commands-for-the-example-file)". ## Loading and merging rules @@ -311,4 +310,4 @@ So, tying this all together, a quick start to create your own kubeconfig file: - Replace the snippet above with information for your cluster's api-server endpoint. -- Make sure your api-server is launched in such a way that at least one user (i.e. green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details. +- Make sure your api-server is launched in such a way that at least one user (for example, green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details. From 700bb5564b53f04624b0e60ad3db2e76e915f960 Mon Sep 17 00:00:00 2001 From: zacharysarah Date: Tue, 1 Aug 2017 15:34:50 -0700 Subject: [PATCH 2/6] Add task template --- .../authenticate-across-clusters-kubeconfig.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md index 44e0ff5420..d0cadc23e1 100644 --- a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md +++ b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md @@ -1,8 +1,5 @@ --- -assignees: -- mikedanese -- thockin -title: Authenticate Across Clusters with kubeconfig +title: Authenticate across clusters with kubeconfig --- Authentication in Kubernetes can differ for different individuals. @@ -311,3 +308,5 @@ So, tying this all together, a quick start to create your own kubeconfig file: - Replace the snippet above with information for your cluster's api-server endpoint. - Make sure your api-server is launched in such a way that at least one user (for example, green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details. + +{% include templates/task.md %} From b80cebf70b7b1842060fdd4109345caf3e27fb39 Mon Sep 17 00:00:00 2001 From: zacharysarah Date: Tue, 1 Aug 2017 15:38:20 -0700 Subject: [PATCH 3/6] Fixed broken link, consistent style usage --- .../authenticate-across-clusters-kubeconfig.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md index d0cadc23e1..d274a44c23 100644 --- a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md +++ b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md @@ -178,7 +178,7 @@ mister-red,mister-red,2 The sample kubeconfig file provides client credentials for the user `green-user`. Because the user for `current-context` is `green-user`, any client of the API server using the sample kubeconfig file could log in successfully. Similarly, we can operate as `blue-user` by changing the value of `current-context`. -In the example provided, `green-user` logs in by providing certificates, and blue-user provides a token. Login information is specified with the `kubectl config set-credentials` command. For more information, see "[Commands for the example file](commands-for-the-example-file)". +In the example provided, `green-user` logs in by providing certificates, and `blue-user` provides a token. Login information is specified with the `kubectl config set-credentials` command. For more information, see "[Commands for the example file](#commands-for-the-example-file)". ## Loading and merging rules @@ -194,7 +194,7 @@ The rules for loading and merging the kubeconfig files are straightforward, but Merge files together based on the following 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. + 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. Otherwise, use HomeDirectoryLocation (`~/.kube/config`) with no merging. @@ -307,6 +307,6 @@ So, tying this all together, a quick start to create your own kubeconfig file: - Replace the snippet above with information for your cluster's api-server endpoint. -- Make sure your api-server is launched in such a way that at least one user (for example, green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details. +- Make sure your api-server is launched in such a way that at least one user (for example, `green-user`) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details. {% include templates/task.md %} From 2f5370e0a7b2f6b07c01dd5a64e92ebc14e1f935 Mon Sep 17 00:00:00 2001 From: zacharysarah Date: Tue, 1 Aug 2017 15:45:18 -0700 Subject: [PATCH 4/6] Fixed an awkward sentence --- .../authenticate-across-clusters-kubeconfig.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md index d274a44c23..3f99bd5cd4 100644 --- a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md +++ b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md @@ -307,6 +307,6 @@ So, tying this all together, a quick start to create your own kubeconfig file: - Replace the snippet above with information for your cluster's api-server endpoint. -- Make sure your api-server is launched in such a way that at least one user (for example, `green-user`) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details. +- Make sure your api-server provides at least one set of credentials (for example, `green-user`) when launched. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details. {% include templates/task.md %} From 7febf3e780a1d27bacd55905182b9a9929a79838 Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Tue, 1 Aug 2017 22:37:46 -0700 Subject: [PATCH 5/6] add template tags --- .../authenticate-across-clusters-kubeconfig.md | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md index 3f99bd5cd4..a8ec6b55f9 100644 --- a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md +++ b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md @@ -2,6 +2,7 @@ title: Authenticate across clusters with kubeconfig --- +{% capture overview %} Authentication in Kubernetes can differ for different individuals. - A running kubelet might have one way of authenticating (i.e. certificates). @@ -14,11 +15,13 @@ So in order to easily switch between multiple clusters, for multiple users, a ku This file contains a series of authentication mechanisms and cluster connection information associated with nicknames. It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname. Multiple kubeconfig files are allowed, if specified explicitly. At runtime they are loaded and merged along with override options specified from the command line (see [rules](#loading-and-merging-rules) below). +{% endcapture %} -## Related discussion - -[http://issue.k8s.io/1755](http://issue.k8s.io/1755) +{% capture prerequisites %} +* {% include task-tutorial-prereqs.md %} +{% endcapture %} +{% capture steps %} ## Components of a kubeconfig file ### Example kubeconfig file @@ -298,7 +301,9 @@ $ kubectl config set-context queen-anne-context --cluster=pig-cluster --user=bla $ kubectl config set-context federal-context --cluster=horse-cluster --user=green-user --namespace=chisel-ns $ kubectl config use-context federal-context ``` +{% endcapture %} +{% capture discussion %} ### Final notes for tying it all together So, tying this all together, a quick start to create your own kubeconfig file: @@ -309,4 +314,8 @@ So, tying this all together, a quick start to create your own kubeconfig file: - Make sure your api-server provides at least one set of credentials (for example, `green-user`) when launched. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details. +## Related discussion +[http://issue.k8s.io/1755](http://issue.k8s.io/1755) +{% endcapture %} + {% include templates/task.md %} From d4893d4fe68725a8764e012e8e85185ae8e4550d Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Tue, 1 Aug 2017 22:42:55 -0700 Subject: [PATCH 6/6] bump up final notes to h2 --- .../authenticate-across-clusters-kubeconfig.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md index a8ec6b55f9..facc84a0e7 100644 --- a/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md +++ b/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md @@ -304,7 +304,7 @@ $ kubectl config use-context federal-context {% endcapture %} {% capture discussion %} -### Final notes for tying it all together +## Final notes for tying it all together So, tying this all together, a quick start to create your own kubeconfig file: