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

Update charts

Browse Source
This commit is contained in:
noam
2023-07-24 17:24:40 +03:00
parent 08583fdb4c
commit edd357f297
53 changed files with 707 additions and 251 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -76,14 +76,14 @@ else it would make it impossible to evacuate a node. See [gh issue #7127](https:
### Prometheus Metrics
The Nginx ingress controller can export Prometheus metrics, by setting `controller.metrics.enabled` to `true`.
The Ingress-Nginx Controller can export Prometheus metrics, by setting `controller.metrics.enabled` to `true`.
You can add Prometheus annotations to the metrics service using `controller.metrics.service.annotations`.
Alternatively, if you use the Prometheus Operator, you can enable ServiceMonitor creation using `controller.metrics.serviceMonitor.enabled`. And set `controller.metrics.serviceMonitor.additionalLabels.release="prometheus"`. "release=prometheus" should match the label configured in the prometheus servicemonitor ( see `kubectl get servicemonitor prometheus-kube-prom-prometheus -oyaml -n prometheus`)
### ingress-nginx nginx\_status page/stats server
Previous versions of this chart had a `controller.stats.*` configuration block, which is now obsolete due to the following changes in nginx ingress controller:
Previous versions of this chart had a `controller.stats.*` configuration block, which is now obsolete due to the following changes in Ingress-Nginx Controller:
- In [0.16.1](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md#0161), the vts (virtual host traffic status) dashboard was removed
- In [0.23.0](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md#0230), the status page at port 18080 is now a unix socket webserver only available at localhost.
@@ -140,8 +140,10 @@ controller:
internal:
enabled: true
annotations:
# Create internal ELB
service.beta.kubernetes.io/aws-load-balancer-internal: "true"
# Create internal NLB
service.beta.kubernetes.io/aws-load-balancer-scheme: "internal"
# Create internal ELB(Deprecated)
# service.beta.kubernetes.io/aws-load-balancer-internal: "true"
# Any other annotation can be declared here.
```
@@ -184,13 +186,15 @@ controller:
# Any other annotation can be declared here.
```
The load balancer annotations of more cloud service providers can be found: [Internal load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer).
An use case for this scenario is having a split-view DNS setup where the public zone CNAME records point to the external balancer URL while the private zone CNAME records point to the internal balancer URL. This way, you only need one ingress kubernetes object.
Optionally you can set `controller.service.loadBalancerIP` if you need a static IP for the resulting `LoadBalancer`.
### Ingress Admission Webhooks
With nginx-ingress-controller version 0.25+, the nginx ingress controller pod exposes an endpoint that will integrate with the `validatingwebhookconfiguration` Kubernetes feature to prevent bad ingress from being added to the cluster.
With nginx-ingress-controller version 0.25+, the Ingress-Nginx Controller pod exposes an endpoint that will integrate with the `validatingwebhookconfiguration` Kubernetes feature to prevent bad ingress from being added to the cluster.
**This feature is enabled by default since 0.31.0.**
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)
@@ -199,7 +203,7 @@ With nginx-ingress-controller in 0.25.* work only with kubernetes 1.14+, 0.26 fi
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.
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