Minor documentation cleanup (#7826)

* clarify link

* Add section headers

* console blocks

* grpc example json was not valid

* multi-tls update text

The preceding point 1 related to 4f2cb51ef8/ingress/controllers/nginx/examples/ingress.yaml
and the deployments referenced in 4f2cb51ef8/ingress/controllers/nginx/examples/README.md

They are not relevant to the current instructions.

* add whitespace around parens

* grammar

setup would be a proper noun, but it is not the intended concept, which is a state

* grammar

* is-only
* via

* Use bullets for choices

* ingress-controller

nginx is a distinct brand.

generally this repo talks about ingress-controller, although it is quite inconsistent about how...

* drop stray paren

* OAuth is a brand and needs an article here

also GitHub is a brand

* Indent text under numbered lists

* use e.g.

* Document that customer header config maps changes do not trigger updates

This should be removed if
https://github.com/kubernetes/ingress-nginx/issues/5238
is fixed.

* article

* period

* infinitive verb + period

* clarify that the gRPC server is responsible for listening for TCP traffic and not some other part of the backend application

* avoid using ; and reword

* whitespace

* brand: gRPC

* only-does is the right form

`for` adds nothing here

* spelling: GitHub

* punctuation

`;` is generally not the right punctuation...

* drop stray `to`

* sentence

* backticks

* fix link

* Improve readability of compare/vs

* Renumber list

* punctuation

* Favor Ingress-NGINX and Ingress NGINX

* Simplify custom header restart text

* Undo typo damage

Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
This commit is contained in:
Josh Soref 2022-01-16 19:57:28 -05:00 committed by GitHub
parent 784f9c53bb
commit 1614027cd4
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
27 changed files with 208 additions and 169 deletions

View file

@ -1,7 +1,7 @@
# External authentication, authentication service response headers propagation
This example demonstrates propagation of selected authentication service response headers
to backend service.
to a backend service.
Sample configuration includes:
@ -37,7 +37,7 @@ public-demo-echo-service public-demo-echo-service.kube.local 80
secure-demo-echo-service secure-demo-echo-service.kube.local 80 1m
```
Test 1: public service with no auth header
## Test 1: public service with no auth header
```console
$ curl -H 'Host: public-demo-echo-service.kube.local' -v 192.168.99.100
@ -60,7 +60,7 @@ $ curl -H 'Host: public-demo-echo-service.kube.local' -v 192.168.99.100
UserID: , UserRole:
```
Test 2: secure service with no auth header
## Test 2: secure service with no auth header
```console
$ curl -H 'Host: secure-demo-echo-service.kube.local' -v 192.168.99.100
@ -89,7 +89,7 @@ $ curl -H 'Host: secure-demo-echo-service.kube.local' -v 192.168.99.100
* Connection #0 to host 192.168.99.100 left intact
```
Test 3: public service with valid auth header
## Test 3: public service with valid auth header
```console
$ curl -H 'Host: public-demo-echo-service.kube.local' -H 'User:internal' -v 192.168.99.100
@ -113,7 +113,7 @@ $ curl -H 'Host: public-demo-echo-service.kube.local' -H 'User:internal' -v 192.
UserID: 1443635317331776148, UserRole: admin
```
Test 4: secure service with valid auth header
## Test 4: secure service with valid auth header
```console
$ curl -H 'Host: secure-demo-echo-service.kube.local' -H 'User:internal' -v 192.168.99.100