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

Move documents related to third-party extensions under third-party-addons

Browse source
This commit is contained in:
Aarni Koskela 2018-04-24 14:50:33 +03:00
parent e677ea22e2
commit 8aa9db8397
3 changed files with 0 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

16
docs/user-guide/third-party-addons/modsecurity.md Normal file
View file

@ -0,0 +1,16 @@
# ModSecurity Web Application Firewall
ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx that is developed by Trustwave's SpiderLabs. It has a robust event-based programming language which provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis - https://www.modsecurity.org
The [ModSecurity-nginx](https://github.com/SpiderLabs/ModSecurity-nginx) connector is the connection point between NGINX and libmodsecurity (ModSecurity v3).
The default ModSecurity configuration file is located in `/etc/nginx/modsecurity/modsecurity.conf`. This is the only file located in this directory and contains the default recommended configuration. Using a volume we can replace this file with the desired configuration.
To enable the ModSecurity feature we need to specify `enable-modsecurity: "true"` in the configuration configmap.
**NOTE:** the default configuration use detection only, because that minimises the chances of post-installation disruption.
The file `/var/log/modsec_audit.log` contains the log of ModSecurity.
The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls. The CRS aims to protect web applications from a wide range of attacks, including the OWASP Top Ten, with a minimum of false alerts.
The directory `/etc/nginx/owasp-modsecurity-crs` contains the https://github.com/SpiderLabs/owasp-modsecurity-crs repository.
Using `enable-owasp-modsecurity-crs: "true"` we enable the use of the rules.

42
docs/user-guide/third-party-addons/opentracing.md Normal file
View file

@ -0,0 +1,42 @@
# OpenTracing
Using the third party module [opentracing-contrib/nginx-opentracing](https://github.com/opentracing-contrib/nginx-opentracing) the NGINX ingress controller can configure NGINX to enable [OpenTracing](http://opentracing.io) instrumentation.
By default this feature is disabled.
To enable the instrumentation we just need to enable the instrumentation in the configuration configmap and set the host where we should send the traces.
In the [rnburn/zipkin-date-server](https://github.com/rnburn/zipkin-date-server)
github repository is an example of a dockerized date service. To install the example and zipkin collector run:
```
kubectl create -f https://raw.githubusercontent.com/rnburn/zipkin-date-server/master/kubernetes/zipkin.yaml
kubectl create -f https://raw.githubusercontent.com/rnburn/zipkin-date-server/master/kubernetes/deployment.yaml
```
Also we need to configure the NGINX controller configmap with the required values:
```
$ echo '
apiVersion: v1
kind: ConfigMap
data:
enable-opentracing: "true"
zipkin-collector-host: zipkin.default.svc.cluster.local
metadata:
name: nginx-configuration
namespace: ingress-nginx
labels:
app: ingress-nginx
' | kubectl replace -f -
```
Using curl we can generate some traces:
```console
$ curl -v http://$(minikube ip)
$ curl -v http://$(minikube ip)
```
In the zipkin interface we can see the details:
![zipkin screenshot](../images/zipkin-demo.png "zipkin collector screenshot")