From 07cc1d8f8f4f06b40f23cf3ca00224a7356f6a6f Mon Sep 17 00:00:00 2001 From: Christopher Tauchen Date: Fri, 20 Dec 2024 17:15:11 +0000 Subject: [PATCH 1/2] Typo fix --- calico-enterprise/networking/gateway-api.mdx | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/calico-enterprise/networking/gateway-api.mdx b/calico-enterprise/networking/gateway-api.mdx index d40de8a3f..d0530f119 100644 --- a/calico-enterprise/networking/gateway-api.mdx +++ b/calico-enterprise/networking/gateway-api.mdx @@ -16,13 +16,13 @@ This feature is tech preview. Tech preview features may be subject to significan ## Value -{{prodname}} includes support for the Kubernetes Gateway API, which allows advanced routing to services in a cluster, including weighted or blue-green load balancing. +$[prodname] includes support for the Kubernetes Gateway API, which allows advanced routing to services in a cluster, including weighted or blue-green load balancing. ## Concepts ### Gateway API -The Gateway API is an official Kubernetes API for advanced routing to services in a cluster. To read about its use cases, structure and design, please see [the official docs](https://gateway-api.sigs.k8s.io/). {{prodname}} provides the following resources and versions of the Gateway API. +The Gateway API is an official Kubernetes API for advanced routing to services in a cluster. To read about its use cases, structure and design, please see [the official docs](https://gateway-api.sigs.k8s.io/). $[prodname] provides the following resources and versions of the Gateway API. | Resource | Versions | | ---------------- | ----------------- | @@ -39,11 +39,11 @@ The Gateway API is an official Kubernetes API for advanced routing to services i ### Envoy Gateway -Several implementations of the Gateway API are available, one of which is the [Envoy Gateway](https://gateway.envoyproxy.io/). {{prodname}} integrates the Envoy Gateway implementation in order to provide support for the Gateway API. +Several implementations of the Gateway API are available, one of which is the [Envoy Gateway](https://gateway.envoyproxy.io/). $[prodname] integrates the Envoy Gateway implementation in order to provide support for the Gateway API. ### Access into a cluster from outside -The Gateway API only provides access into a cluster from outside when the cluster is _also_ provisioned to support Kubernetes Services with `type: LoadBalancer`. When a Gateway is configured, {{prodname}} creates a Deployment that does the actual work of routing and load balancing, etc., and a Service with `type: LoadBalancer` that fronts that Deployment. If the cluster has a `type: LoadBalancer` provider, it will then allocate an IP outside the cluster and arrange for requests to that IP to be forwarded to the Gateway Service. +The Gateway API only provides access into a cluster from outside when the cluster is _also_ provisioned to support Kubernetes Services with `type: LoadBalancer`. When a Gateway is configured, $[prodname] creates a Deployment that does the actual work of routing and load balancing, etc., and a Service with `type: LoadBalancer` that fronts that Deployment. If the cluster has a `type: LoadBalancer` provider, it will then allocate an IP outside the cluster and arrange for requests to that IP to be forwarded to the Gateway Service. Managed Kubernetes services like AKS, EKS and GKE include a `type: LoadBalancer` provider that automatically integrates with Azure, AWS and GCP respectively. On-prem clusters and non-managed clusters in the cloud need to set up their own `type: LoadBalancer` support. @@ -91,7 +91,7 @@ tlsroutes udproutes gateway.networking.k8s.io/v1alpha2 true UDPRoute ``` -And also that there is a GatewayClass resource corresponding to the Envoy Gateway implementation included in {{prodname}}: +And also that there is a GatewayClass resource corresponding to the Envoy Gateway implementation included in $[prodname]: ```bash kubectl get gatewayclass -o yaml | yq r - 'items[0].spec' @@ -415,4 +415,4 @@ metadata: EOF ``` -Please note that the Gateway API CRDs will be left in place. This is to allow for the possibility of using other Gateway API implementations in addition to the one provided by {{prodname}}. +Please note that the Gateway API CRDs will be left in place. This is to allow for the possibility of using other Gateway API implementations in addition to the one provided by $[prodname]. From aa737086dbe073038441f294027b76adb3b617ac Mon Sep 17 00:00:00 2001 From: Christopher Tauchen Date: Fri, 20 Dec 2024 18:18:24 +0000 Subject: [PATCH 2/2] Fixes WAF link --- calico-cloud/threat/web-application-firewall.mdx | 2 +- .../version-20-2/threat/web-application-firewall.mdx | 2 +- calico-enterprise/threat/web-application-firewall.mdx | 2 +- .../version-3.17/threat/web-application-firewall.mdx | 2 +- .../version-3.18-2/threat/web-application-firewall.mdx | 4 ++-- .../version-3.19-2/threat/web-application-firewall.mdx | 2 +- .../version-3.20-1/threat/web-application-firewall.mdx | 2 +- .../version-3.20-2/threat/web-application-firewall.mdx | 2 +- 8 files changed, 9 insertions(+), 9 deletions(-) diff --git a/calico-cloud/threat/web-application-firewall.mdx b/calico-cloud/threat/web-application-firewall.mdx index 93b434f0a..e60f8908a 100644 --- a/calico-cloud/threat/web-application-firewall.mdx +++ b/calico-cloud/threat/web-application-firewall.mdx @@ -220,7 +220,7 @@ By default WAF will not block a request even if it has matching rule violations. ##### Other basic customizations -For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/embed/coreruleset/tigera.conf#L8-L17) are situated there. +For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/ruleset/coreruleset/tigera.conf#L8-L17) are situated there. An example is adding a sampling mode. For that, the `tigera.conf` will look like this: diff --git a/calico-cloud_versioned_docs/version-20-2/threat/web-application-firewall.mdx b/calico-cloud_versioned_docs/version-20-2/threat/web-application-firewall.mdx index 93b434f0a..e60f8908a 100644 --- a/calico-cloud_versioned_docs/version-20-2/threat/web-application-firewall.mdx +++ b/calico-cloud_versioned_docs/version-20-2/threat/web-application-firewall.mdx @@ -220,7 +220,7 @@ By default WAF will not block a request even if it has matching rule violations. ##### Other basic customizations -For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/embed/coreruleset/tigera.conf#L8-L17) are situated there. +For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/ruleset/coreruleset/tigera.conf#L8-L17) are situated there. An example is adding a sampling mode. For that, the `tigera.conf` will look like this: diff --git a/calico-enterprise/threat/web-application-firewall.mdx b/calico-enterprise/threat/web-application-firewall.mdx index bf76f994a..c33d4f955 100644 --- a/calico-enterprise/threat/web-application-firewall.mdx +++ b/calico-enterprise/threat/web-application-firewall.mdx @@ -199,7 +199,7 @@ By default WAF will not block a request even if it has matching rule violations. #### Other basic customizations -For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/embed/coreruleset/tigera.conf#L8-L17) are situated there. +For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/ruleset/coreruleset/tigera.conf#L8-L17) are situated there. An example is adding a sampling mode. For that, the `tigera.conf` will look like this: diff --git a/calico-enterprise_versioned_docs/version-3.17/threat/web-application-firewall.mdx b/calico-enterprise_versioned_docs/version-3.17/threat/web-application-firewall.mdx index 762a0faf3..ff3eea800 100644 --- a/calico-enterprise_versioned_docs/version-3.17/threat/web-application-firewall.mdx +++ b/calico-enterprise_versioned_docs/version-3.17/threat/web-application-firewall.mdx @@ -177,7 +177,7 @@ The default rule sets work fine for most deployments. However, you can customize By default, $[prodname] ships with Core Rule Set v3.3.5 with the following setup files pre-loaded: -- [tigera.conf](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/embed/coreruleset/tigera.conf) +- [tigera.conf](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/ruleset/coreruleset/tigera.conf) To start creating your rules, it is recommended that you download the files (all three) and create your modifications from there, as follows: diff --git a/calico-enterprise_versioned_docs/version-3.18-2/threat/web-application-firewall.mdx b/calico-enterprise_versioned_docs/version-3.18-2/threat/web-application-firewall.mdx index b9508133c..a93f59da4 100644 --- a/calico-enterprise_versioned_docs/version-3.18-2/threat/web-application-firewall.mdx +++ b/calico-enterprise_versioned_docs/version-3.18-2/threat/web-application-firewall.mdx @@ -26,7 +26,7 @@ Historically, web application firewalls (WAFs) were deployed at the edge of your WAF is deployed in your cluster along with Envoy DaemonSet. $[prodname] proxies selected service traffic through Envoy, checking HTTP requests using the industry-standard [ModSecurity](https://owasp.org/www-project-modsecurity-core-rule-set/) with OWASP Core Rule Set v3.3.5 modified for kubernetes workloads. - + You simply enable WAF in Manager UI, and determine the services that you want to enable for WAF protection. By default WAF is set to `DetectionOnly` so no traffic will be denied until you are ready to turn on blocking mode. @@ -177,7 +177,7 @@ Some common changes are detailed below, for example: By default, $[prodname] ships with Core Rule Set v3.3.5 with the following setup files pre-loaded: -- [tigera.conf](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/embed/coreruleset/tigera.conf) +- [tigera.conf](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/ruleset/coreruleset/tigera.conf) There are two ways to edit your rules. 1. Edit the configmap directly using kubectl. The config map combines all the rule files together, so you will need to know how to search and find the exact place in the configmap that you want to update. diff --git a/calico-enterprise_versioned_docs/version-3.19-2/threat/web-application-firewall.mdx b/calico-enterprise_versioned_docs/version-3.19-2/threat/web-application-firewall.mdx index 1d31a4115..3e9fa5446 100644 --- a/calico-enterprise_versioned_docs/version-3.19-2/threat/web-application-firewall.mdx +++ b/calico-enterprise_versioned_docs/version-3.19-2/threat/web-application-firewall.mdx @@ -218,7 +218,7 @@ By default WAF will not block a request even if it has matching rule violations. ##### Other basic customizations -For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/embed/coreruleset/tigera.conf#L8-L17) are situated there. +For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/ruleset/coreruleset/tigera.conf#L8-L17) are situated there. An example is adding a sampling mode. For that, the `tigera.conf` will look like this: diff --git a/calico-enterprise_versioned_docs/version-3.20-1/threat/web-application-firewall.mdx b/calico-enterprise_versioned_docs/version-3.20-1/threat/web-application-firewall.mdx index 1d31a4115..3e9fa5446 100644 --- a/calico-enterprise_versioned_docs/version-3.20-1/threat/web-application-firewall.mdx +++ b/calico-enterprise_versioned_docs/version-3.20-1/threat/web-application-firewall.mdx @@ -218,7 +218,7 @@ By default WAF will not block a request even if it has matching rule violations. ##### Other basic customizations -For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/embed/coreruleset/tigera.conf#L8-L17) are situated there. +For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/ruleset/coreruleset/tigera.conf#L8-L17) are situated there. An example is adding a sampling mode. For that, the `tigera.conf` will look like this: diff --git a/calico-enterprise_versioned_docs/version-3.20-2/threat/web-application-firewall.mdx b/calico-enterprise_versioned_docs/version-3.20-2/threat/web-application-firewall.mdx index 707e93cb9..c2e81c584 100644 --- a/calico-enterprise_versioned_docs/version-3.20-2/threat/web-application-firewall.mdx +++ b/calico-enterprise_versioned_docs/version-3.20-2/threat/web-application-firewall.mdx @@ -198,7 +198,7 @@ By default WAF will not block a request even if it has matching rule violations. #### Other basic customizations -For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/embed/coreruleset/tigera.conf#L8-L17) are situated there. +For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/ruleset/coreruleset/tigera.conf#L8-L17) are situated there. An example is adding a sampling mode. For that, the `tigera.conf` will look like this: