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

Release controller 1.9.6 and helm 4.9.1 (#10919)

Browse source 
Signed-off-by: James Strong <strong.james.e@gmail.com>
This commit is contained in:
James Strong 2024-01-27 02:45:19 -05:00 • committed by GitHub
parent e8699bfb92
commit 4e97379b4e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
29 changed files with 318 additions and 436 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -2,117 +2,59 @@
It is possible to enable Client-Certificate Authentication by adding additional annotations to your Ingress Resource.
## 1. Prerequisites / Certificates
Before getting started you must have the following Certificates configured:
- Certificate Authority (CA) Certificate ```ca-cert.pem```
- Server Certificate (Signed by CA) and Key ```server-cert.pem``` and ```server-key.pem```
- Client Certificate (Signed by CA), Key and CA Certificate for following client side authentication (See Sub-Section 4 - Test)
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
:memo: If Intermediate CA-Certificates (Official CA, non-self-signed) used, they all need to be concatenated (CA authority chain) in one CA file.
For more details on the generation process, checkout the Prerequisite [docs](../../PREREQUISITES.md#client-certificate-authentication).
The following commands let you generate self-signed Certificates and Keys for testing-purpose.
- Generate the CA Key and Certificate:
```bash
openssl req -x509 -sha256 -newkey rsa:4096 -keyout ca-key.der -out ca-cert.der -days 356 -nodes -subj '/CN=My Cert Authority'
```
- Generate the Server Key, and Certificate and Sign with the CA Certificate:
```bash
openssl req -new -newkey rsa:4096 -keyout server-key.der -out server.csr -nodes -subj '/CN=mydomain.com'
openssl x509 -req -sha256 -days 365 -in server.csr -CA ca-cert.der -CAkey ca-key.der -set_serial 01 -out server-cert.der
```
:memo: The CN (Common Name) x.509 attribute for the server Certificate ***must*** match the dns hostname referenced in ingress definition, see example below.
- Generate the Client Key, and Certificate and Sign with the CA Certificate:
```bash
openssl req -new -newkey rsa:4096 -keyout client-key.der -out client.csr -nodes -subj '/CN=My Client'
openssl x509 -req -sha256 -days 365 -in client.csr -CA ca-cert.der -CAkey ca-key.der -set_serial 02 -out client-cert.der
```
## 2. Import Certificates / Keys to Kubernetes Secret-Backend
- Convert all files specified in 1) from .der (binary format) to .pem (base64 encoded):
You can have as many certificates as you want. If they're in the binary DER format, you can convert them as the following:
```bash
openssl x509 -in certificate.der -inform der -out certificate.crt -outform pem
```
:exclamation: Kubernetes Web-Services import relies on .pem Base64-encoded format.
:zap: There is no need to import the CA Private Key, the Private Key is used only to sign new Client Certificates by the CA.
- Import the CA Certificate as Kubernetes sub-type ```generic/ca.crt```
Then, you can concatenate them all into one file, named 'ca.crt' with the following:
```bash
kubectl create secret generic ca-secret --from-file=ca.crt=./ca-cert.pem
cat certificate1.crt certificate2.crt certificate3.crt >> ca.crt
```
- Import the Server Certificate and Key as Kubernetes sub-type ```tls``` for transport layer
**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.
```bash
kubectl create secret tls tls-secret --cert ./server-cert.pem --key ./server-key.pem
```
## Creating Certificate Secrets
- Optional import CA-cert, Server-cert and Server-Key for TLS and Client-Auth
There are many different ways of configuring your secrets to enable Client-Certificate
Authentication to work properly.
```bash
kubectl create secret generic tls-and-auth --from-file=tls.crt=./server-crt.pem --from-file=tls.key=./server-key.pem --from-file=ca.crt=./ca-cert.pem
```
* You can create a secret containing just the CA certificate and another
Secret containing the Server Certificate which is Signed by the CA.
- Optional import a CRL (Certificate Revocation List)
```bash
kubectl create secret generic ca-secret --from-file=ca.crt=ca.crt
kubectl create secret generic tls-secret --from-file=tls.crt=server.crt --from-file=tls.key=server.key
```
```bash
kubectl create secret generic ca-secret --from-file=ca.crt=./ca-cert.pem --from-file=ca.crl=./ca-crl.pem
```
* You can create a secret containing CA certificate along with the Server
Certificate that can be used for both TLS and Client Auth.
## 3. Annotations / Ingress-Reference
```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
```
Now we are able to reference the created secrets in the ingress definition.
* 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
```
:memo: The CA Certificate "authentication" will be reference in annotations.
Note: The CA Certificate must contain the trusted certificate authority chain to verify client certificates.
| Annotation | Description | Remark |
|---------------------------------------------------------------------------|----------------------------|--------------------|
| nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" | Activate Client-Auth | If "on", verify client Certificate |
| nginx.ingress.kubernetes.io/auth-tls-secret: "namespace/ca-secret" | CA "secret" reference | Secret namespace and service / ingress namespace must match |
| nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1" | CA "chain" depth | How many CA levels should be processed |
| nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true" | Pass Cert / Header | Pass Certificate to Web-App for e.g. parsing Client E-Mail Address x.509 Property |
:memo: The Server Certificate for transport layer will be referenced in tls .yaml subsection.
```yaml
tls:
- hosts:
- mydomain.com
secretName: tls-secret
```
## 4. Example / Test
The working .yaml Example: [ingress.yaml](ingress.yaml)
- Test by performing a curl / wget against the Ingress Path without the Client Cert and expect a Status Code 400 (Bad Request - No required SSL certificate was sent).
- Test by performing a curl / wget against the Ingress Path with the Client Cert and expect a Status Code 200.
```bash
wget \
--ca-cert=ca-cert.pem \
--certificate=client-cert.pem \
--private-key=client-key.pem \
https://mydomain.com
```
## 5. Remarks
| :exclamation: In future releases, CN verification seems to be "replaced" by SAN (Subject Alternate Name) for verrification, so do not forget to add |
|-----------------------------------------------------------------------------------------------------------------------------------------------------|
```bash
openssl req -addext "subjectAltName = DNS:mydomain.com" ...
```
## Setup Instructions
1. Add the annotations as provided in the [ingress.yaml](ingress.yaml) example to your own ingress resources as required.
2. Test by performing a curl against the Ingress Path without the Client Cert and expect a Status Code 400.
3. Test by performing a curl against the Ingress Path with the Client Cert and expect a Status Code 200.

2
docs/examples/customization/custom-errors/custom-default-backend.helm.values.yaml
View file

@ -6,7 +6,7 @@ defaultBackend:
image:
registry: registry.k8s.io
image: ingress-nginx/nginx-errors
tag: "v20231208-4c39e6acc@sha256:c2ca20775f41c0c89906dc74a31239d94ac48e84e7c6164affed41fe669cdaa5"
tag: "v20230505@sha256:3600dcd1bbd0d05959bb01af4b272714e94d22d24a64e91838e7183c80e53f7f"
extraVolumes:
- name: custom-error-pages
configMap:

2
docs/examples/customization/custom-errors/custom-default-backend.yaml
View file

@ -36,7 +36,7 @@ spec:
spec:
containers:
- name: nginx-error-server
image: registry.k8s.io/ingress-nginx/nginx-errors:v20231208-4c39e6acc@sha256:c2ca20775f41c0c89906dc74a31239d94ac48e84e7c6164affed41fe669cdaa5
image: registry.k8s.io/ingress-nginx/nginx-errors:v20230505@sha256:3600dcd1bbd0d05959bb01af4b272714e94d22d24a64e91838e7183c80e53f7f
ports:
- containerPort: 8080
# Setting the environment variable DEBUG we can see the headers sent

1
docs/examples/grpc/README.md
View file

@ -9,7 +9,6 @@ This example demonstrates how to route traffic to a gRPC service through the Ing
3. You have the ingress-nginx-controller installed as per docs.
4. You have a backend application running a gRPC server listening for TCP traffic. If you want, you can use <https://github.com/grpc/grpc-go/blob/91e0aeb192456225adf27966d04ada4cf8599915/examples/features/reflection/server/main.go> as an example.
5. You're also responsible for provisioning an SSL certificate for the ingress. So you need to have a valid SSL certificate, deployed as a Kubernetes secret of type `tls`, in the same namespace as the gRPC application.
- Note: To use gRPC with ingress-nginx, TLS _must_ be terminated by the ingress or gRPC server (using the `backend-protocol: "GRPCS"` annotation described below).
### Step 1: Create a Kubernetes `Deployment` for gRPC app

2
docs/examples/rewrite/README.md
View file

@ -31,7 +31,7 @@ Rewriting can be controlled using the following annotations:
[Captured groups](https://www.regular-expressions.info/refcapture.html) are saved in numbered placeholders, chronologically, in the form `$1`, `$2` ... `$n`. These placeholders can be used as parameters in the `rewrite-target` annotation.
!!! note
Please see the [FAQ](../../faq.md#validation-of-path) for Validation Of __`path`__
Please see the [FAQ](../faq.md#validation-of-path) for Validation Of __`path`__
Create an Ingress rule with a rewrite annotation: