Merge branch 'main' into patch-5

Author: LaurenceJJones

.github/workflows/values_parameters.yaml

@@ -0,0 +1,54 @@
+name: Generate values parameters
+
+on:
+  schedule:
+    # Tous les jours à 02:00 UTC
+    - cron: "0 2 * * *"
+  workflow_dispatch:
+
+jobs:
+  update_values_parameters:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v5
+      - name: Checkout
+        uses: actions/checkout@v5
+        with:
+          repository: crowdsecurity/helm-charts
+          path: helm-charts
+      - name: Set up Node.js (readme-generator requires Node 22.x)
+        uses: actions/setup-node@v6
+        with:
+          node-version: "22"
+
+      - name: Install readme-generator-for-helm
+        run: npm i -g @bitnami/readme-generator-for-helm@2.7.2
+
+      - name: Generate README.md & values.schema.json
+        run: |
+          find . 
+          readme-generator \
+            --values "helm-charts/charts/crowdsec/values.yaml" \
+            --readme "crowdsec-docs/docs/configuration/values_parameters.md" \
+            --schema "/tmp/schema.json"
+
+      - name: Create Pull Request
+        id: cpr
+        uses: peter-evans/create-pull-request@v6
+        with:
+          branch: chore/regen-values-parameters
+          delete-branch: true
+          commit-message: "chore(charts): regenerate values parameters"
+          title: "chore(charts): regenerate values parameters"
+          body: |
+            Regenerate values parameters from helm-charts values.yaml.
+          labels: |
+            automation
+
+      - name: Enable PR auto-merge
+        if: steps.cpr.outputs.pull-request-number != ''
+        uses: peter-evans/enable-pull-request-automerge@v3
+        with:
+          pull-request-number: ${{ steps.cpr.outputs.pull-request-number }}
+          merge-method: squash

crowdsec-docs/archives/version-v1.3.4.tar.gz

@@ -1,10 +1,10 @@
 ---
 id: advanced_deployments
-title: Advanced WAF Deployments
+title: WAF Deployment Strategies
 sidebar_position: 6
 ---
 
-# Advanced WAF Deployments
+# WAF Deployment Strategies
 
 This guide covers advanced CrowdSec WAF deployment strategies for organizations looking to gradually enhance their web application security posture. Learn how to progressively improve your WAF configuration from basic virtual patching to comprehensive multi-layer protection.
 
@@ -44,7 +44,7 @@ CrowdSec WAF supports multiple deployment strategies that can be implemented pro
 
 ### 2. Enhanced Detection (Out-of-band CRS)
 **Next Step**: Add comprehensive attack detection without performance impact
-- Add: [`crowdsecurity/appsec-crs-inband`](https://app.crowdsec.net/hub/author/crowdsecurity/collections/appsec-crs-inband) (out-of-band) alongside existing virtual patching
+- Add: [`crowdsecurity/appsec-crs`](https://app.crowdsec.net/hub/author/crowdsecurity/collections/crowdsecurity/appsec-crs) (out-of-band) alongside existing virtual patching
 - Mode: Non-blocking analysis + behavioral banning
 - Coverage: OWASP Top 10 + comprehensive attack patterns + specific CVE protection
 - Performance: No latency impact ⚡
@@ -259,7 +259,7 @@ In-band CRS blocking provides maximum protection but requires:
 
 Once you've implemented advanced deployments:
 
-- Configure [Custom Rules](/appsec/create_rules.md) for application-specific protection
-- Set up [Hooks](/appsec/hooks.md) for custom response actions
-- Explore [Configuration Options](/appsec/configuration.md) for fine-tuning
-- Review [Troubleshooting Guide](/appsec/troubleshooting.md) for operational issues
+- Configure [Custom Rules](create_rules.md) for application-specific protection
+- Set up [Hooks](hooks.md) for custom response actions
+- Explore [Configuration Options](configuration.md) for fine-tuning
+- Review [Troubleshooting Guide](troubleshooting.md) for operational issues

crowdsec-docs/archives/version-v1.4.0.tar.gz

@@ -6,7 +6,7 @@ sidebar_position: 5
 
 ## Generated Events Layout
 
-HTTP requests that trigger _In-Band_ or _Out-Of-Band_ AppSec/WAF rules generate events. These events can trigger scenarios that react by banning or alerting when rules are matched.
+HTTP requests that trigger _In-Band_ or _Out-Of-Band_ AppSec/WAF rules generate events. These events can trigger scenarios that ban or alert when rules are matched.
 
 The [`crowdsecurity/appsec-logs` parser](https://app.crowdsec.net/hub/author/crowdsecurity/configurations/appsec-logs) is designed as a general-purpose tool to convert events into a format that is easier to process with scenarios.
 
@@ -21,7 +21,7 @@ The generated event looks like this:
  - `evt.Meta.target_host` is set to the FQDN if present (`Host` header in the HTTP request)
  - `evt.Meta.target_uri` is set to the complete URI of the HTTP request
  - `evt.Meta.rule_name` is set to the name of the triggered rule
- - `evt.Meta.remediation_cmpt_ip` is set to the IP of the Remediation Component (Bouncer) that sent the HTTP request.
+ - `evt.Meta.remediation_cmpt_ip` is set to the IP of the Remediation Component (bouncer) that sent the HTTP request.
 
 :::info
 The [`crowdsecurity/appsec-logs` parser](https://app.crowdsec.net/hub/author/crowdsecurity/configurations/appsec-logs) is already part of the generic AppSec/WAF collections and doesn't have to be manually installed.
@@ -56,7 +56,7 @@ Let's try to solve an imaginary scenario:
 > We aim to prevent users from enumerating certain URLs (specifically, those that begin with `/foobar/*`) when a particular HTTP header is present (`something: *test*`). However, we want to impose this restriction only on users attempting to access two or more distinct `/foobar/*` URLs while this header is set.
 
 :::info
-Keep in mind that _Out-Of-Band_ rules will  generate an event instead of blocking the HTTP Request.
+Keep in mind that _Out-Of-Band_ rules generate an event instead of blocking the HTTP request.
 :::
 
 #### The AppSec/WAF Rule
@@ -85,7 +85,7 @@ rules:
       value: test
 ```
 
-Let ensure it's loaded as an _Out-Of-Band_ rule, first by creating a new appsec-config:
+Let's ensure it's loaded as an _Out-Of-Band_ rule by creating a new AppSec config:
 
 ```yaml title="/etc/crowdsec/appsec-configs/appsec-oob.yaml"
 name: crowdsecurity/appsec-oob
@@ -109,7 +109,7 @@ source: appsec
 
 #### The Scenario
 
-We can now create a scenario that will trigger when a single IPs triggers this rule on distinct URLs:
+We can now create a scenario that will trigger when a single IP triggers this rule on distinct URLs:
 
 ```yaml title="/etc/crowdsec/scenarios/foobar-enum.yaml"
 type: leaky

crowdsec-docs/archives/version-v1.5.0.tar.gz

@@ -17,9 +17,9 @@ sidebar_position: 80
 
 # Basic Benchmark
 
-The Application Security Component benchmarks have been run on a AWS EC2 Instance `t2.medium` (2vCPU/4GiB RAM).
+The Application Security Component benchmarks were run on an AWS EC2 instance `t2.medium` (2vCPU/4GiB RAM).
 
-All the benchmarks have been run with only one `routine` configured for the Application Security Component.
+All benchmarks were run with a single `routine` configured for the Application Security Component.
 
 The benchmarks cover the following tests:
 
@@ -32,11 +32,11 @@ The benchmarks cover the following tests:
   - 15 concurrent connections / 1000 requests
 -->
 
-Each test has been run with multiple cases:
+Each test was run with multiple cases:
 
 - Application Security Component enabled but without any rules
-- Application Security Component enabled with 100 vpatch rules (in in-band)
-- Application Security Component enabled with all the CRS (in in-band)
+- Application Security Component enabled with 100 vpatch rules (in-band)
+- Application Security Component enabled with all the CRS (in-band)
 
 On the system, we deployed:
 
@@ -76,9 +76,9 @@ Tested versions are:
 - CrowdSec `v1.7.0`
 - cs-openresty-bouncer `v1.1.2`
 
-Openresty was configured to not log anything and forward requests to a Go backend that always return 200, in order to improve raw throughput and not be limited by disk access.
+Openresty was configured to not log anything and forward requests to a Go backend that always returns 200, to improve raw throughput and avoid disk access limits.
 
-Crowdsec WAF was configured with 16 routines to make use of as much CPU as possible.
+CrowdSec WAF was configured with 16 routines to make use of as much CPU as possible.
 
 All tests were simulating 400 concurrent users, making requests as quickly as possible during 1 minute.