mystiq/dex
Archived
4
0
Fork 1
Code Issues Pull requests Packages Projects Releases Wiki Activity

Kubernetes docs: wording nitpicks

Browse source
This commit is contained in:
Owen Tuz 2018-11-23 10:53:37 +00:00
parent 58093dbb29
commit 45eb9b279b
2 changed files with 4 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
Documentation/kubernetes.md
View file

@ -14,7 +14,7 @@ The authentication flow looks like:
3. Kubernetes uses dex's public keys to verify the ID Token.
4. A claim designated as the username (and optionally group information) will be associated with that request.
Username and group information can be combined with Kubernetes [authorization plugins][k8s-authz], such as roles based access control (RBAC), to enforce policy.
Username and group information can be combined with Kubernetes [authorization plugins][k8s-authz], such as role based access control (RBAC), to enforce policy.
## Configuring the OpenID Connect plugin
@ -133,14 +133,12 @@ $ kubectl create secret \
### Deploy the Dex server
Create the dex deployment, configmap, and node port service.
Create the dex deployment, configmap, and node port service. This will also create RBAC bindings allowing the Dex pod access to manage [Custom Resource Definitions](https://github.com/dexidp/dex/blob/master/Documentation/storage.md#kubernetes-custom-resource-definitions-crds) within Kubernetes.
```
$ kubectl create -f dex.yaml
```
The Dex pod requires access to manage [Custom Resource Definitions](https://github.com/dexidp/dex/blob/master/Documentation/storage.md#kubernetes-custom-resource-definitions-crds) within Kubernetes, so the example manifest also creates a service account and RBAC role bindings to provide these permissions.
__Caveats:__ No health checking is configured because dex does its own TLS termination complicating the setup. This is a known issue and can be tracked [here][dex-healthz].
## Logging into the cluster

4
Documentation/storage.md
View file

@ -38,9 +38,9 @@ Etcd storage can be customized further using the following options:
## Kubernetes custom resource definitions (CRDs)
__NOTE:__ CRDs are only supported by Kubernetes version 1.7+.
Kubernetes [custom resource definitions](crd) are a way for applications to create new resources types in the Kubernetes API.
Kubernetes [custom resource definitions](crd) are a way for applications to create new resources types in the Kubernetes API. The Custom Resource Definition (CRD) API object was introduced in Kubernetes version 1.7 to replace the Third Party Resource (TPR) extension. CRDs allows dex to run on top of an existing Kubernetes cluster without the need for an external database. While this storage may not be appropriate for a large number of users, it's extremely effective for many Kubernetes use cases.
The Custom Resource Definition (CRD) API object was introduced in Kubernetes version 1.7 to replace the Third Party Resource (TPR) extension. CRDs allow dex to run on top of an existing Kubernetes cluster without the need for an external database. While this storage may not be appropriate for a large number of users, it's extremely effective for many Kubernetes use cases.
The rest of this section will explore internal details of how dex uses CRDs. __Admins should not interact with these resources directly__, except while debugging. These resources are only designed to store state and aren't meant to be consumed by end users. For modifying dex's state dynamically see the [API documentation](api.md).