github_mirrors/openappsec
3
0
Fork 1
mirror of https://github.com/openappsec/openappsec.git synced 2025-10-01 03:57:44 +03:00
Code Issues Packages Projects Releases Wiki Activity

Updating the NGINX Ingress helm chart

Browse Source
This commit is contained in:
Ned Wright
2023-05-29 16:30:53 +00:00
parent dfcc71c8c2
commit 36f65b9b1f
55 changed files with 1690 additions and 1274 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
build_system/charts/open-appsec-k8s-nginx-ingress/README.md.gotmpl
View File

@@ -7,10 +7,7 @@ To use, add `ingressClassName: nginx` spec field or the `kubernetes.io/ingress.c
This chart bootstraps an ingress-nginx deployment on a [Kubernetes](http://kubernetes.io) cluster using the [Helm](https://helm.sh) package manager.
## Prerequisites
- Chart version 3.x.x: Kubernetes v1.16+
- Chart version 4.x.x and above: Kubernetes v1.19+
{{ template "chart.requirementsSection" . }}
## Get Repo Info
@@ -51,10 +48,6 @@ helm upgrade [RELEASE_NAME] [CHART] --install
_See [helm upgrade](https://helm.sh/docs/helm/helm_upgrade/) for command documentation._
### Upgrading With Zero Downtime in Production
By default the ingress-nginx controller has service interruptions whenever it's pods are restarted or redeployed. In order to fix that, see the excellent blog post by Lindsay Landry from Codecademy: [Kubernetes: Nginx and Zero Downtime in Production](https://medium.com/codecademy-engineering/kubernetes-nginx-and-zero-downtime-in-production-2c910c6a5ed8).
### Migrating from stable/nginx-ingress
There are two main ways to migrate a release from `stable/nginx-ingress` to `ingress-nginx/ingress-nginx` chart:
@@ -65,7 +58,6 @@ There are two main ways to migrate a release from `stable/nginx-ingress` to `ing
1. Redirect your DNS traffic from the old controller to the new controller
1. Log traffic from both controllers during this changeover
1. [Uninstall](#uninstall-chart) the old controller once traffic has fully drained from it
1. For details on all of these steps see [Upgrading With Zero Downtime in Production](#upgrading-with-zero-downtime-in-production)
Note that there are some different and upgraded configurations between the two charts, described by Rimas Mocevicius from JFrog in the "Upgrading to ingress-nginx Helm chart" section of [Migrating from Helm chart nginx-ingress to ingress-nginx](https://rimusz.net/migrating-to-ingress-nginx). As the `ingress-nginx/ingress-nginx` chart continues to update, you will want to check current differences by running [helm configuration](#configuration) commands on both charts.
@@ -99,7 +91,7 @@ Previous versions of this chart had a `controller.stats.*` configuration block,
### ExternalDNS Service Configuration
Add an [ExternalDNS](https://github.com/kubernetes-incubator/external-dns) annotation to the LoadBalancer service:
Add an [ExternalDNS](https://github.com/kubernetes-sigs/external-dns) annotation to the LoadBalancer service:
```yaml
controller:
@@ -110,7 +102,7 @@ controller:
### AWS L7 ELB with SSL Termination
Annotate the controller as shown in the [nginx-ingress l7 patch](https://github.com/kubernetes/ingress-nginx/blob/main/deploy/aws/l7/service-l7.yaml):
Annotate the controller as shown in the [nginx-ingress l7 patch](https://github.com/kubernetes/ingress-nginx/blob/ab3a789caae65eec4ad6e3b46b19750b481b6bce/deploy/aws/l7/service-l7.yaml):
```yaml
controller:
@@ -125,19 +117,6 @@ controller:
service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: '3600'
```
### AWS route53-mapper
To configure the LoadBalancer service with the [route53-mapper addon](https://github.com/kubernetes/kops/tree/master/addons/route53-mapper), add the `domainName` annotation and `dns` label:
```yaml
controller:
service:
labels:
dns: "route53"
annotations:
domainName: "kubernetes-example.com"
```
### Additional Internal Load Balancer
This setup is useful when you need both external and internal load balancers but don't want to have multiple ingress controllers and multiple ingress objects per application.
@@ -174,7 +153,7 @@ controller:
internal:
enabled: true
annotations:
# Create internal LB. More informations: https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing
# Create internal LB. More information: https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing
# For GKE versions 1.17 and later
networking.gke.io/load-balancer-type: "Internal"
# For earlier versions
@@ -216,6 +195,21 @@ With nginx-ingress-controller version 0.25+, the nginx ingress controller pod ex
With nginx-ingress-controller in 0.25.* work only with kubernetes 1.14+, 0.26 fix [this issue](https://github.com/kubernetes/ingress-nginx/pull/4521)
#### How the Chart Configures the Hooks
A validating and configuration requires the endpoint to which the request is sent to use TLS. It is possible to set up custom certificates to do this, but in most cases, a self-signed certificate is enough. The setup of this component requires some more complex orchestration when using helm. The steps are created to be idempotent and to allow turning the feature on and off without running into helm quirks.
1. A pre-install hook provisions a certificate into the same namespace using a format compatible with provisioning using end user certificates. If the certificate already exists, the hook exits.
2. The ingress nginx controller pod is configured to use a TLS proxy container, which will load that certificate.
3. Validating and Mutating webhook configurations are created in the cluster.
4. A post-install hook reads the CA from the secret created by step 1 and patches the Validating and Mutating webhook configurations. This process will allow a custom CA provisioned by some other process to also be patched into the webhook configurations. The chosen failure policy is also patched into the webhook configurations
#### Alternatives
It should be possible to use [cert-manager/cert-manager](https://github.com/cert-manager/cert-manager) if a more complete solution is required.
You can enable automatic self-signed TLS certificate provisioning via cert-manager by setting the `controller.admissionWebhooks.certManager.enabled` value to true.
Please ensure that cert-manager is correctly installed and configured.
### Helm Error When Upgrading: spec.clusterIP: Invalid value: ""
If you are upgrading this chart from a version between 0.31.0 and 1.2.2 then you may get an error like this:
@@ -228,8 +222,4 @@ Detail of how and why are in [this issue](https://github.com/helm/charts/pull/13
As of version `1.26.0` of this chart, by simply not providing any clusterIP value, `invalid: spec.clusterIP: Invalid value: "": field is immutable` will no longer occur since `clusterIP: ""` will not be rendered.
{{ template "chart.requirementsSection" . }}
{{ template "chart.valuesSection" . }}
{{ template "helm-docs.versionFooter" . }}