From 19ac992525f229809f21e06ef83ff18641e31ecf Mon Sep 17 00:00:00 2001 From: John Torres Date: Thu, 11 Aug 2016 10:41:58 -0400 Subject: [PATCH 1/8] updated access to cluster/api w/o proxy post kube v1.3.2 --- docs/user-guide/accessing-the-cluster.md | 26 ++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/accessing-the-cluster.md b/docs/user-guide/accessing-the-cluster.md index cf15072373..7cfacf0176 100644 --- a/docs/user-guide/accessing-the-cluster.md +++ b/docs/user-guide/accessing-the-cluster.md @@ -69,7 +69,7 @@ $ curl http://localhost:8080/api/ } ``` -#### Without kubectl proxy +#### Without kubectl proxy (before v1.3.x) It is also possible to avoid using kubectl proxy by passing an authentication token directly to the apiserver, like this: @@ -85,7 +85,29 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure } ``` -The above example uses the `--insecure` flag. This leaves it subject to MITM +#### Without kubectl proxy (post v1.3.x) + +In recent versions of Kubernetes, `kubectl config view` no longer displays the token. Use `kubectl describe secret...` to get the token for the default service account, like this: + +``` shell +$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ") +$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d '\t') +$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +The above examples use the `--insecure` flag. This leaves it subject to MITM attacks. When kubectl accesses the cluster it uses a stored root certificate and client certificates to access the server. (These are installed in the `~/.kube` directory). Since cluster certificates are typically self-signed, it From 6c4163fa64bf1b0efc2d8cbbfa39b9f3c39c45af Mon Sep 17 00:00:00 2001 From: John Torres Date: Sun, 11 Sep 2016 16:41:02 -0400 Subject: [PATCH 2/8] updates based on comments from @devin-donnelly --- docs/user-guide/accessing-the-cluster.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/accessing-the-cluster.md b/docs/user-guide/accessing-the-cluster.md index 7cfacf0176..73289371e5 100644 --- a/docs/user-guide/accessing-the-cluster.md +++ b/docs/user-guide/accessing-the-cluster.md @@ -71,7 +71,7 @@ $ curl http://localhost:8080/api/ #### Without kubectl proxy (before v1.3.x) -It is also possible to avoid using kubectl proxy by passing an authentication token +It is possible to avoid using kubectl proxy by passing an authentication token directly to the apiserver, like this: ```shell @@ -87,7 +87,7 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure #### Without kubectl proxy (post v1.3.x) -In recent versions of Kubernetes, `kubectl config view` no longer displays the token. Use `kubectl describe secret...` to get the token for the default service account, like this: +In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the token. Use `kubectl describe secret...` to get the token for the default service account, like this: ``` shell $ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ") From bf8b978cc97d283e1aa5d52f9347831cb668d13a Mon Sep 17 00:00:00 2001 From: Sam Stoelinga Date: Fri, 16 Sep 2016 12:51:51 -0700 Subject: [PATCH 3/8] Fix update-demo references to doc location It seems docs were moved from kubernetes repo and now live in the website repo. I've updated the update-demo docs to work again with actual references. --- docs/user-guide/update-demo/index.md | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/docs/user-guide/update-demo/index.md b/docs/user-guide/update-demo/index.md index aa10b2a362..d51bcffc08 100644 --- a/docs/user-guide/update-demo/index.md +++ b/docs/user-guide/update-demo/index.md @@ -13,11 +13,11 @@ here](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch} ### Step Zero: Prerequisites -This example assumes that you have forked the repository and [turned up a Kubernetes cluster](/docs/getting-started-guides/): +This example assumes that you have forked the docs repository and [turned up a Kubernetes cluster](/docs/getting-started-guides/): ```shell -$ cd kubernetes -$ ./cluster/kube-up.sh +$ git clone -b {{page.docsbranch}} https://github.com/kubernetes/kubernetes.github.io +$ cd kubernetes.github.io ``` ### Step One: Turn up the UX for the demo @@ -81,14 +81,7 @@ This first stops the replication controller by turning the target number of repl ### Step Six: Cleanup -To turn down a Kubernetes cluster: - -```shell -$ ./cluster/kube-down.sh -``` - -Kill the proxy running in the background: -After you are done running this demo make sure to kill it: +After you are done running this demo make sure to kill the proxy running in the background: ```shell $ jobs From f2b90fa2c3fc23a3cba13a35628c35d59cadeea7 Mon Sep 17 00:00:00 2001 From: YuPengZTE Date: Thu, 22 Sep 2016 16:22:31 +0800 Subject: [PATCH 4/8] 'etc' should be 'etc.' Signed-off-by: YuPengZTE --- docs/getting-started-guides/rackspace.md | 2 +- docs/getting-started-guides/scratch.md | 2 +- docs/user-guide/jobs.md | 2 +- docs/user-guide/volumes.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/getting-started-guides/rackspace.md b/docs/getting-started-guides/rackspace.md index 5ed73f495f..5087344b83 100644 --- a/docs/getting-started-guides/rackspace.md +++ b/docs/getting-started-guides/rackspace.md @@ -62,7 +62,7 @@ There is a specific `cluster/rackspace` directory with the scripts for the follo ## Network Design - eth0 - Public Interface used for servers/containers to reach the internet -- eth1 - ServiceNet - Intra-cluster communication (k8s, etcd, etc) communicate via this interface. The `cloud-config` files use the special CoreOS identifier `$private_ipv4` to configure the services. +- eth1 - ServiceNet - Intra-cluster communication (k8s, etcd, etc.) communicate via this interface. The `cloud-config` files use the special CoreOS identifier `$private_ipv4` to configure the services. - eth2 - Cloud Network - Used for k8s pods to communicate with one another. The proxy service will pass traffic via this interface. ## Support Level diff --git a/docs/getting-started-guides/scratch.md b/docs/getting-started-guides/scratch.md index 38b7fa82f9..773cc796e0 100644 --- a/docs/getting-started-guides/scratch.md +++ b/docs/getting-started-guides/scratch.md @@ -72,7 +72,7 @@ accomplished in two ways: pod network through traffic encapsulation (e.g vxlan). - Encapsulation reduces performance, though exactly how much depends on your solution. - **Without an overlay network** - - Configure the underlying network fabric (switches, routers, etc) to be aware of pod IP addresses. + - Configure the underlying network fabric (switches, routers, etc.) to be aware of pod IP addresses. - This does not require the encapsulation provided by an overlay, and so can achieve better performance. diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md index 59e09e7bcd..ae5e16b3d3 100644 --- a/docs/user-guide/jobs.md +++ b/docs/user-guide/jobs.md @@ -157,7 +157,7 @@ parallelism, for a variety or reasons: remaining completions. Higher values of `.spec.parallelism` are effectively ignored. - For work queue jobs, no new pods are started after any pod has succeeded -- remaining pods are allowed to complete, however. - If the controller has not had time to react. -- If the controller failed to create pods for any reason (lack of ResourceQuota, lack of permission, etc), +- If the controller failed to create pods for any reason (lack of ResourceQuota, lack of permission, etc.), then there may be fewer pods than requested. - The controller may throttle new pod creation due to excessive previous pod failures in the same Job. - When a pod is gracefully shutdown, it make take time to stop. diff --git a/docs/user-guide/volumes.md b/docs/user-guide/volumes.md index 9ccc8c73c3..0001dbd667 100644 --- a/docs/user-guide/volumes.md +++ b/docs/user-guide/volumes.md @@ -485,7 +485,7 @@ spec: ## Resources -The storage media (Disk, SSD, etc) of an `emptyDir` volume is determined by the +The storage media (Disk, SSD, etc.) of an `emptyDir` volume is determined by the medium of the filesystem holding the kubelet root dir (typically `/var/lib/kubelet`). There is no limit on how much space an `emptyDir` or `hostPath` volume can consume, and no isolation between containers or between From b0d3fd5f6b9f58536d4bc3d72704f8c5789f7d36 Mon Sep 17 00:00:00 2001 From: YuPengZTE Date: Thu, 22 Sep 2016 17:07:06 +0800 Subject: [PATCH 5/8] Capitalizes the first letter Signed-off-by: YuPengZTE --- .../fedora/flannel_multi_node_cluster.md | 2 +- docs/getting-started-guides/gce.md | 8 ++++---- docs/getting-started-guides/scratch.md | 6 +++--- docs/user-guide/federation/federated-services.md | 6 +++--- docs/user-guide/images.md | 8 ++++---- docs/user-guide/jobs/expansions/index.md | 2 +- 6 files changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md b/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md index 4c89d85e90..7f4504f2c9 100644 --- a/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md +++ b/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md @@ -18,7 +18,7 @@ You need 2 or more machines with Fedora installed. **Perform following commands on the Kubernetes master** -* Configure flannel by creating a `flannel-config.json` in your current directory on fed-master. flannel provides udp and vxlan among other overlay networking backend options. In this guide, we choose kernel based vxlan backend. The contents of the json are: +* Configure flannel by creating a `flannel-config.json` in your current directory on fed-master. Flannel provides udp and vxlan among other overlay networking backend options. In this guide, we choose kernel based vxlan backend. The contents of the json are: ```json { diff --git a/docs/getting-started-guides/gce.md b/docs/getting-started-guides/gce.md index d768c4db7f..bbb210f95e 100644 --- a/docs/getting-started-guides/gce.md +++ b/docs/getting-started-guides/gce.md @@ -64,10 +64,10 @@ If you run into trouble, please see the section on [troubleshooting](/docs/getti The next few steps will show you: -1. how to set up the command line client on your workstation to manage the cluster -1. examples of how to use the cluster -1. how to delete the cluster -1. how to start clusters with non-default options (like larger clusters) +1. How to set up the command line client on your workstation to manage the cluster +1. Examples of how to use the cluster +1. How to delete the cluster +1. How to start clusters with non-default options (like larger clusters) ### Installing the Kubernetes command line tools on your workstation diff --git a/docs/getting-started-guides/scratch.md b/docs/getting-started-guides/scratch.md index 38b7fa82f9..7fffe7145e 100644 --- a/docs/getting-started-guides/scratch.md +++ b/docs/getting-started-guides/scratch.md @@ -514,9 +514,9 @@ availability. To run an etcd instance: -1. copy `cluster/saltbase/salt/etcd/etcd.manifest` -1. make any modifications needed -1. start the pod by putting it into the kubelet manifest directory +1. Copy `cluster/saltbase/salt/etcd/etcd.manifest` +1. Make any modifications needed +1. Start the pod by putting it into the kubelet manifest directory ### Apiserver, Controller Manager, and Scheduler diff --git a/docs/user-guide/federation/federated-services.md b/docs/user-guide/federation/federated-services.md index 1734d0af29..18c26d4014 100644 --- a/docs/user-guide/federation/federated-services.md +++ b/docs/user-guide/federation/federated-services.md @@ -40,9 +40,9 @@ API for traditional Kubernetes Services. Once created, the Federated Service automatically: -1. creates matching Kubernetes Services in every cluster underlying your Cluster Federation, -2. monitors the health of those service "shards" (and the clusters in which they reside), and -3. manages a set of DNS records in a public DNS provider (like Google Cloud DNS, or AWS Route 53), thus ensuring that clients +1. Creates matching Kubernetes Services in every cluster underlying your Cluster Federation, +2. Monitors the health of those service "shards" (and the clusters in which they reside), and +3. Manages a set of DNS records in a public DNS provider (like Google Cloud DNS, or AWS Route 53), thus ensuring that clients of your federated service can seamlessly locate an appropriate healthy service endpoint at all times, even in the event of cluster, availability zone or regional outages. diff --git a/docs/user-guide/images.md b/docs/user-guide/images.md index c4a7b7c00a..e739bb0ca9 100644 --- a/docs/user-guide/images.md +++ b/docs/user-guide/images.md @@ -118,12 +118,12 @@ in the `$HOME` of user `root` on a kubelet, then docker will use it. Here are the recommended steps to configuring your nodes to use a private registry. In this example, run these on your desktop/laptop: - 1. run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json`. - 1. view `$HOME/.docker/config.json` in an editor to ensure it contains just the credentials you want to use. - 1. get a list of your nodes, for example: + 1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json`. + 1. View `$HOME/.docker/config.json` in an editor to ensure it contains just the credentials you want to use. + 1. Get a list of your nodes, for example: - if you want the names: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')` - if you want to get the IPs: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')` - 1. copy your local `.docker/config.json` to the home directory of root on each node. + 1. Copy your local `.docker/config.json` to the home directory of root on each node. - for example: `for n in $nodes; do scp ~/.docker/config.json root@$n:/root/.docker/config.json; done` Verify by creating a pod that uses a private image, e.g.: diff --git a/docs/user-guide/jobs/expansions/index.md b/docs/user-guide/jobs/expansions/index.md index c955bbf124..9dd2786530 100644 --- a/docs/user-guide/jobs/expansions/index.md +++ b/docs/user-guide/jobs/expansions/index.md @@ -32,7 +32,7 @@ We also put the same label on the pod template so that we can check on all Pods with a single command. After the job is created, the system will add more labels that distinguish one Job's pods from another Job's pods. -Note that the label key `jobgroup` is not special to Kubernetes. you can pick your own label scheme. +Note that the label key `jobgroup` is not special to Kubernetes. You can pick your own label scheme. Next, expand the template into multiple files, one for each item to be processed. From d322b78c53c1f5f4224aa9ee697d5c6cf53de2b9 Mon Sep 17 00:00:00 2001 From: Chmouel Boudjnah Date: Mon, 19 Sep 2016 13:48:04 +0200 Subject: [PATCH 6/8] minor spelling update using mispellings https://pypi.python.org/pypi/misspellings --- README.md | 2 +- docs/admin/authentication.md | 2 +- docs/admin/cluster-management.md | 2 +- docs/admin/garbage-collection.md | 2 +- docs/admin/multiple-zones.md | 2 +- docs/hellonode.md | 2 +- docs/templatedemos/filledout.md | 4 ++-- docs/user-guide/petset/bootstrapping/index.md | 4 ++-- 8 files changed, 10 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index e2fc558f9d..a468c1f947 100644 --- a/README.md +++ b/README.md @@ -67,7 +67,7 @@ Your copy of the site will then be viewable at: [http://localhost:4000](http://l ## GitHub help -If you're a bit rusty with git/GitHub, you might wanna read +If you're a bit rusty with git/GitHub, you might want to read [this](http://readwrite.com/2013/10/02/github-for-beginners-part-2) for a refresher. ## Common Tasks diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md index 08fde3265f..c3c5e52c77 100644 --- a/docs/admin/authentication.md +++ b/docs/admin/authentication.md @@ -228,7 +228,7 @@ it must be an array of strings. Kubernetes does not provide an OpenID Connect Identity Provider. You can use an existing public OpenID Connect Identity Provider (such as Google, or [others](http://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)). -Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), [Keycloak](https://github.com/keycloak/keycloak) or CloudFoundary [UAA](https://github.com/cloudfoundry/uaa). +Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), [Keycloak](https://github.com/keycloak/keycloak) or CloudFoundry [UAA](https://github.com/cloudfoundry/uaa). The provider needs to support [OpenID connect discovery](https://openid.net/specs/openid-connect-discovery-1_0.html); not all do. diff --git a/docs/admin/cluster-management.md b/docs/admin/cluster-management.md index c681a45996..7781368bc8 100644 --- a/docs/admin/cluster-management.md +++ b/docs/admin/cluster-management.md @@ -84,7 +84,7 @@ no node that has enough free capacity (or doesn't match other pod requirements) to wait until some pods are terminated or a new node is added. Cluster autoscaler looks for the pods that cannot be scheduled and checks if adding a new node, similar -to the other in the cluster, would help. If yes, then it resizes the cluster to accomodate the waiting pods. +to the other in the cluster, would help. If yes, then it resizes the cluster to accommodate the waiting pods. Cluster autoscaler also scales down the cluster if it notices that some node is not needed anymore for an extended period of time (10min but it may change in the future). diff --git a/docs/admin/garbage-collection.md b/docs/admin/garbage-collection.md index bb7f2c2133..a3112a07f1 100644 --- a/docs/admin/garbage-collection.md +++ b/docs/admin/garbage-collection.md @@ -52,5 +52,5 @@ Containers can potentially be garbage collected before their usefulness has expi can contain logs and other data that can be useful for troubleshooting. A sufficiently large value for `maximum-dead-containers-per-container` is highly recommended to allow at least 2 dead containers to be retained per expected container. A higher value for `maximum-dead-containers` is also recommended for a -similiar reason. +similar reason. See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details. diff --git a/docs/admin/multiple-zones.md b/docs/admin/multiple-zones.md index e5d1367862..bfde54213e 100644 --- a/docs/admin/multiple-zones.md +++ b/docs/admin/multiple-zones.md @@ -39,7 +39,7 @@ or service across nodes in a single-zone cluster (to reduce the impact of failures.) With multiple-zone clusters, this spreading behaviour is extended across zones (to reduce the impact of zone failures.) (This is achieved via `SelectorSpreadPriority`). This is a best-effort -placement, and so if the zones in your cluster are heterogenous +placement, and so if the zones in your cluster are heterogeneous (e.g. different numbers of nodes, different types of nodes, or different pod resource requirements), this might prevent perfectly even spreading of your pods across zones. If desired, you can use diff --git a/docs/hellonode.md b/docs/hellonode.md index e489927aff..602a383a5b 100755 --- a/docs/hellonode.md +++ b/docs/hellonode.md @@ -117,7 +117,7 @@ curl http://localhost:8080 You should see `Hello World!` -**Note:** *If you recieve a `Connection refused` message from Docker for Mac, ensure you are using the latest version of Docker (1.12 or later). Alternatively, if you are using Docker Toolbox on OSX, make sure you are using the VM's IP and not localhost:* +**Note:** *If you receive a `Connection refused` message from Docker for Mac, ensure you are using the latest version of Docker (1.12 or later). Alternatively, if you are using Docker Toolbox on OSX, make sure you are using the VM's IP and not localhost:* ```shell curl "http://$(docker-machine ip YOUR-VM-MACHINE-NAME):8080" diff --git a/docs/templatedemos/filledout.md b/docs/templatedemos/filledout.md index ba56528a20..9622fa2c14 100644 --- a/docs/templatedemos/filledout.md +++ b/docs/templatedemos/filledout.md @@ -42,7 +42,7 @@ kubectl get pod | Return Value | Description | |--------------|-------------| -| `READY` | Describes the number of containers that are ready to recieve traffic. | +| `READY` | Describes the number of containers that are ready to receive traffic. | | `STATUS` | A value from the `PodPhase` enum describing the current status of the pod. Can be `Running`, `Pending`, `Succeeded`, `Failed`, and `Unknown`. | TODO: Link to refpage for `kubectl get pod` @@ -77,4 +77,4 @@ YAML EXAMPLE HERE {% endcapture %} -{% include templates/concept-overview.md %} \ No newline at end of file +{% include templates/concept-overview.md %} diff --git a/docs/user-guide/petset/bootstrapping/index.md b/docs/user-guide/petset/bootstrapping/index.md index 7ad12cc8e8..e9b04fc135 100644 --- a/docs/user-guide/petset/bootstrapping/index.md +++ b/docs/user-guide/petset/bootstrapping/index.md @@ -19,7 +19,7 @@ This example shows you how to "carry over" runtime state across Pet restart by s ### Background -Applications that incrementally build state usually need strong guarantees that they will not restart for extended durations. This is tricky to achieve with containers, so instead, we will ensure that the results of previous computations are trasferred to future pets. Doing so is straightforward using vanilla Persistent Volumes (which Pet Set already gives you), unless the volume mount point itself needs to be initialized for the Pet to start. This is exactly the case with "virtual machine" docker images, like those based on ubuntu or fedora. Such images embed the entier rootfs of the distro, including package managers like `apt-get` that assume a certain layout of the filesystem. Meaning: +Applications that incrementally build state usually need strong guarantees that they will not restart for extended durations. This is tricky to achieve with containers, so instead, we will ensure that the results of previous computations are transferred to future pets. Doing so is straightforward using vanilla Persistent Volumes (which Pet Set already gives you), unless the volume mount point itself needs to be initialized for the Pet to start. This is exactly the case with "virtual machine" docker images, like those based on ubuntu or fedora. Such images embed the entire rootfs of the distro, including package managers like `apt-get` that assume a certain layout of the filesystem. Meaning: * If you mount an empty volume under `/usr`, you won't be able to `apt-get` * If you mount an empty volume under `/lib`, all your `apt-gets` will fail because there are no system libraries @@ -130,7 +130,7 @@ Here's a tiny peer finder helper script that handles peer discovery, [available * A DNS domain * An `on-start` script to run with the initial constituency of the given domain as input -* An `on-change` script to run everytime the constituency of the given domain changes +* An `on-change` script to run every time the constituency of the given domain changes The role of the peer finder: From 6a54f558229dbfadc4d4f6721c0af730e6832d19 Mon Sep 17 00:00:00 2001 From: Alex Robinson Date: Fri, 23 Sep 2016 11:45:19 -0400 Subject: [PATCH 7/8] Don't reference elasticsearch/kibana in gce getting started guide The default GCE configuration uses fluentd-cloud-logging, so it's misleading to tell people about elasticsearch/kibana being in their cluster. --- docs/getting-started-guides/gce.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/getting-started-guides/gce.md b/docs/getting-started-guides/gce.md index bc3d664909..f7cce78a7c 100644 --- a/docs/getting-started-guides/gce.md +++ b/docs/getting-started-guides/gce.md @@ -46,7 +46,7 @@ wget -q -O - https://get.k8s.io | bash Once this command completes, you will have a master VM and four worker VMs, running as a Kubernetes cluster. -By default, some containers will already be running on your cluster. Containers like `kibana` and `elasticsearch` provide [logging](/docs/getting-started-guides/logging), while `heapster` provides [monitoring](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/README.md) services. +By default, some containers will already be running on your cluster. Containers like `fluentd` provide [logging](/docs/getting-started-guides/logging), while `heapster` provides [monitoring](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/README.md) services. The script run by the commands above creates a cluster with the name/prefix "kubernetes". It defines one specific cluster config, so you can't run it more than once. From 3750c217ec498b1754332fb93563d8129c4a4c39 Mon Sep 17 00:00:00 2001 From: Eric Tune Date: Mon, 29 Aug 2016 16:17:24 -0700 Subject: [PATCH 8/8] How to refer to rervice account groups in RBAC --- docs/admin/authorization.md | 63 +++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/docs/admin/authorization.md b/docs/admin/authorization.md index 3b1fa47e4d..544270bb84 100644 --- a/docs/admin/authorization.md +++ b/docs/admin/authorization.md @@ -323,6 +323,69 @@ roleRef: apiVersion: rbac.authorization.k8s.io/v1alpha1 ``` +### Referring to Subjects + +RoleBindings and ClusterRoleBindings bind "subjects" to "roles". +Subjects can be groups, users or service accounts. + +Users are represented by strings. These can be plain usernames, like +"alice", or email style names, like "bob@example.com", or numeric ids +as string. It is up to the Kubernetes admin to configure +the [authentication modules](/doc/admin/authentication/) to produce +usernames in the desired format. The RBAC authorization system does +not require any particular format. However, the prefix `system:` is +reserved for Kubernetes system use, and so the admin should ensure +usernames should not contain this prefix by accident. + +Groups information in Kubernetes is currently provided by the Authenticator +modules. (In the future we may add a separate way for the RBAC Authorizer +to query groups information for users.) Groups, like users, are represented +by a string, and that string has no format requirements, other than that the +prefix `system:` is reserved. + +Service Accounts have usernames with the `system:` prefix and belong +to groups with the `system:` prefix. + +#### Role Binding Examples + +Only the `subjects` section of a RoleBinding object shown in the following examples. + +For a user called `alice@example.com`, specify +```yaml +subjects: + - kind: User + name: "alice@example.com" +``` + +For a group called `frontend-admins`, specify: +```yaml +subjects: + - kind: Group + name: "frontend-admins" +``` + +For the default service account in the kube-system namespace: +```yaml +subjects: + - kind: ServiceAccount + name: default + namespace: kube-system +``` + +For all service accounts in the `qa` namespace: +```yaml +subjects: +- kind: Group + name: system:serviceaccounts:qa +``` + +For all service accounts everywhere: +```yaml +subjects: +- kind: Group + name: system:serviceaccounts +``` + ### Privilege Escalation Prevention and Bootstrapping The `rbac.authorization.k8s.io` API group inherently attempts to prevent users