DevFW-CICD/ingress-nginx-helm
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Minor documentation cleanup (#7826)

Browse source 
* 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
Download patch file Download diff file Expand all files Collapse all files

21
docs/examples/auth/client-certs/README.md
View file

@ -1,11 +1,12 @@
# Client Certificate Authentication
It is possible to enable Client-Certificate Authentication by adding additional annotations to your Ingress Resource.
Before getting started you must have the following Certificates Setup:
1. CA certificate and Key(Intermediate Certs need to be in CA)
2. Server Certificate(Signed by CA) and Key (CN should be equal the hostname you will use)
3. Client Certificate(Signed by CA) and Key
Before getting started you must have the following Certificates configured:
1. CA certificate and Key (Intermediate Certs need to be in CA)
2. Server Certificate (Signed by CA) and Key (CN should be equal the hostname you will use)
3. Client Certificate (Signed by CA) and Key
For more details on the generation process, checkout the Prerequisite [docs](../../PREREQUISITES.md#client-certificate-authentication).
@ -15,13 +16,13 @@ You can have as many certificates as you want. If they're in the binary DER form
openssl x509 -in certificate.der -inform der -out certificate.crt -outform pem
```
Then, you can concatenate them all in only one file, named 'ca.crt' as the following:
Then, you can concatenate them all into one file, named 'ca.crt' with the following:
```bash
cat certificate1.crt certificate2.crt certificate3.crt >> ca.crt
```
**Note:** Make sure that the Key Size is greater than 1024 and Hashing Algorithm(Digest) is something better than md5
**Note:** Make sure that the Key Size is greater than 1024 and Hashing Algorithm (Digest) is something better than md5
for each certificate generated. Otherwise you will receive an error.
## Creating Certificate Secrets
@ -29,7 +30,7 @@ for each certificate generated. Otherwise you will receive an error.
There are many different ways of configuring your secrets to enable Client-Certificate
Authentication to work properly.
1. You can create a secret containing just the CA certificate and another
* You can create a secret containing just the CA certificate and another
Secret containing the Server Certificate which is Signed by the CA.
```bash
@ -37,14 +38,14 @@ Authentication to work properly.
kubectl create secret generic tls-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key
```
2. You can create a secret containing CA certificate along with the Server
Certificate, that can be used for both TLS and Client Auth.
* You can create a secret containing CA certificate along with the Server
Certificate that can be used for both TLS and Client Auth.
```bash
kubectl create secret generic ca-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key --from-file=ca.crt=ca.crt
```
3. If you want to also enable Certificate Revocation List verification you can
* If you want to also enable Certificate Revocation List verification you can
create the secret also containing the CRL file in PEM format:
```bash
kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt --from-file=ca.crl=ca.crl