From 9646edb410519330a1c89559b505c9da226f0801 Mon Sep 17 00:00:00 2001
From: R-Lawton <rlawton@redhat.com>
Date: Mon, 2 Dec 2024 21:57:16 +0000
Subject: [PATCH] Updated SCP to currenrt versions and removed old and
 unecessary parts

Signed-off-by: R-Lawton <rlawton@redhat.com>

Updated SCP to currenrt versions and removed old and unecessary parts

Signed-off-by: R-Lawton <rlawton@redhat.com>
---
 .../secure-protect-connect-openshift.md       | 750 +++++++-----------
 1 file changed, 280 insertions(+), 470 deletions(-)

diff --git a/doc/user-guides/full-walkthrough/secure-protect-connect-openshift.md b/doc/user-guides/full-walkthrough/secure-protect-connect-openshift.md
index c9c178024..d5602f62c 100644
--- a/doc/user-guides/full-walkthrough/secure-protect-connect-openshift.md
+++ b/doc/user-guides/full-walkthrough/secure-protect-connect-openshift.md
@@ -1,103 +1,136 @@
-# Secure, protect, and connect APIs with Kuadrant on OpenShift
+# Secure, protect, and connect APIs with Kuadrant
 
 ## Overview
 
-This guide walks you through using Kuadrant on OpenShift to secure, protect, and connect an API exposed by a Gateway that is based on Kubernetes Gateway API. You can use this walkthrough for a Gateway deployed on a single OpenShift cluster or a Gateway distributed across multiple OpenShift clusters with a shared listener hostname. This guide shows how the platform engineer and application developer user roles can each use Kuadrant to achieve their goals.
+This guide walks you through using Kuadrant to secure, protect, and connect an API exposed by a Gateway (Kubernetes Gateway API) from the personas platform engineer and application developer. For more information on the different personas please see the [Gateway API documentation](https://gateway-api.sigs.k8s.io/concepts/roles-and-personas/#key-roles-and-personas)
 
-### What Kuadrant can do for you in a multicluster environment
-
-You can leverage Kuadrant's capabilities in single or multiple clusters. The following features are designed to work across multiple clusters as well as in a single-cluster environment.
-
-- **Multicluster ingress:** Kuadrant provides multicluster ingress connectivity using DNS to bring traffic to your Gateways by using a strategy defined in a `DNSPolicy`. 
-- **Global rate limiting:** Kuadrant can enable global rate limiting use cases when configured to use a shared Redis store for counters based on limits defined by a `RateLimitPolicy`.
-- **Global auth:** You can configure a Kuadrant `AuthPolicy` to leverage external auth providers to ensure that different clusters exposing the same API authenticate and authorize in the same way. 
-- **Integration with federated metrics stores:** Kuadrant has example dashboards and metrics for visualizing your Gateways and observing traffic hitting those Gateways across multiple clusters. 
+## Prerequisites
 
-### User roles
+- Completed the steps in [Install Kuadrant on an OpenShift cluster](../../install/install-openshift.md).
+- [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) command line tool.
+- AWS/Azure or GCP with DNS capabilities.
 
-- **Platform engineer**: This guide walks you through deploying a Gateway that provides secure communication and is protected and ready for use by application development teams to deploy an API. It then walks through using this Gateway in clusters in different geographic regions, leveraging Kuadrant to bring specific traffic to your geo-located Gateways to reduce latency and distribute load, while still being protected and secured with global rate limiting and auth. 
 
-- **Application developer**: This guide walks through how you can use the Kuadrant OpenAPI Specification (OAS) extensions and `kuadrantctl` CLI to generate an `HTTPRoute` for your API and to add specific auth and rate limiting requirements.
+### Set the environment variables
 
-As an optional extra, this guide highlights how both user roles can observe and monitor these Gateways when the OpenShift user workload monitoring and observability stack is deployed. 
+Set the following environment variables used for convenience in this guide:
 
-### Deployment management tooling
+```bash
+export KUADRANT_GATEWAY_NS=api-gateway # Namespace for the example Gateway
+export KUADRANT_GATEWAY_NAME=external # Name for the example Gateway
+export KUADRANT_DEVELOPER_NS=toystore # Namespace for an example toystore app
+export KUADRANT_AWS_ACCESS_KEY_ID=xxxx # AWS Key ID with access to manage the DNS Zone ID below
+export KUADRANT_AWS_SECRET_ACCESS_KEY=xxxx # AWS Secret Access Key with access to manage the DNS Zone ID below
+export KUADRANT_AWS_REGION=us-east-1 # Region to create the DNS resources in AWS
+export KUADRANT_AWS_DNS_PUBLIC_ZONE_ID=xxxx # AWS Route 53 Zone ID for the Gateway
+export KUADRANT_ZONE_ROOT_DOMAIN=example.com # Root domain associated with the Zone ID above
+export KUADRANT_CLUSTER_ISSUER_NAME=lets-encrypt # Name for the ClusterIssuer
+export KUADRANT_EMAIL=foo@example.com # Email address to associate with the example LetsEncrypt issuer
+```
 
-While this document uses `kubectl` commands for simplicity, working with multiple clusters is complex, and it is best to use a tool such as Argo CD to manage the deployment of resources to multiple clusters.
+### Set up a DNS Provider
 
-## Prerequisites
+The DNS provider declares credentials to access the zone(s) that Kuadrant can use to set up DNS configuration. Ensure that this credential only has access to the zones you want Kuadrant to manage via `DNSPolicy`
 
-This guide expects that you have successfully installed Kuadrant on at least one OpenShift cluster:
+Create the namespace the Gateway will be deployed in:
 
-- You have completed the steps in [Install Kuadrant on an OpenShift cluster](../../install/install-openshift.md) for one or more clusters.
-- For multicluster scenarios, you have installed Kuadrant on at least two different OpenShift clusters, and have a shared accessible Redis store.
-- You have the `kubectl` command line installed.
-- Optional: User workload monitoring is configured to remote write to a central storage system such as Thanos, as described in [Install Kuadrant on an OpenShift cluster](../../install/install-openshift.md).
+```bash
+kubectl create ns ${KUADRANT_GATEWAY_NS}
+```
 
-## Platform engineer workflow
+Create the secret credentials in the same namespace as the Gateway - these will be used to configure DNS:
 
-NOTE: You must perform the following steps in each cluster individually, unless specifically excluded. 
+```bash
+kubectl -n ${KUADRANT_GATEWAY_NS} create secret generic aws-credentials \
+  --type=kuadrant.io/aws \
+  --from-literal=AWS_ACCESS_KEY_ID=$KUADRANT_AWS_ACCESS_KEY_ID \
+  --from-literal=AWS_SECRET_ACCESS_KEY=$KUADRANT_AWS_SECRET_ACCESS_KEY
+```
 
-### Step 1 - Set your environment variables
+Before adding a TLS issuer, create the secret credentials in the cert-manager namespace:
 
-Set the following environment variables used for convenience in this guide:
 ```bash
-export zid=change-this-to-your-zone-id
-export rootDomain=example.com
-export gatewayNS=api-gateway
-export gatewayName=external
-export devNS=toystore
-export AWS_ACCESS_KEY_ID=xxxx
-export AWS_SECRET_ACCESS_KEY=xxxx
-export AWS_REGION=us-east-1
-export clusterIssuerName=lets-encrypt
-export EMAIL=foo@example.com
+kubectl -n cert-manager create secret generic aws-credentials \
+  --type=kuadrant.io/aws \
+  --from-literal=AWS_ACCESS_KEY_ID=$KUADRANT_AWS_ACCESS_KEY_ID \
+  --from-literal=AWS_SECRET_ACCESS_KEY=$KUADRANT_AWS_SECRET_ACCESS_KEY
 ```
 
-### Step 2 - Set up a DNS Provider
+### Deploy the Toystore app
+
+Create the namespace for the Toystore application:
 
-The DNS provider declares a credential to access the zone(s) that Kuadrant can use to set up DNS configuration. You should ensure that this credential only has access to the zones you want managed.
+```bash
 
-#### Create the DNS Provider Secret resource
+kubectl create ns ${KUADRANT_DEVELOPER_NS}
+```
 
-Apply the following `Secret` resource to each cluster. Alternatively, if you are adding an additional cluster, add it to the new cluster:
+Deploy the Toystore app to the developer namespace:
 
 ```bash
-kubectl create ns ${gatewayNS}
+kubectl apply -f https://raw.githubusercontent.com/Kuadrant/Kuadrant-operator/main/examples/toystore/toystore.yaml -n ${KUADRANT_DEVELOPER_NS}
 ```
 
-Create the secret credentials as follows:
+### Setup Toystore application HTTPRoute
 
+```bash
+
+kubectl apply -f - <<EOF
+apiVersion: gateway.networking.k8s.io/v1
+kind: HTTPRoute
+metadata:
+  name: toystore
+  namespace: ${KUADRANT_DEVELOPER_NS}
+  labels:
+    deployment: toystore
+    service: toystore
+spec:
+  parentRefs:
+  rules:
+  - group: gateway.networking.k8s.io
+    kind: Gateway
+    name: ${KUADRANT_GATEWAY_NAME}
+    namespace: ${KUADRANT_GATEWAY_NAMESPACE}
+  hostnames:
+  - "api.${KUADRANT_ZONE_ROOT_DOMAIN}"
+  rules:
+  - matches:
+    - method: GET
+      path:
+        type: PathPrefix
+        value: "/cars"
+EOF
 ```
-kubectl -n ${gatewayNS} create secret generic aws-credentials \
-  --type=kuadrant.io/aws \
-  --from-literal=AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
-  --from-literal=AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
-```
+The status of the HTTPRoute will not be accepted or enforced, it will be unknown as the Gateway hasn't been created yet:
 
-### Step 3 - Add a TLS issuer
+```bash
+kubectl get httproute toystore -n ${KUADRANT_DEVELOPER_NS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Enforced")].message}'
 
-To secure communication to the Gateways, you will define a TLS issuer for TLS certificates. This example uses Let's Encrypt, but you can use any issuer supported by `cert-manager`.
+```
+### Add a TLS issuer
 
-The following example uses Let's Encrypt staging, which you must also apply to all clusters:
+To secure communication to the Gateways, define a TLS issuer for TLS certificates.
+
+!!! note 
+    This example uses Let's Encrypt, but you can use any issuer supported by `cert-manager`.
 
 ```bash
 kubectl apply -f - <<EOF
 apiVersion: cert-manager.io/v1
 kind: ClusterIssuer
 metadata:
-  name: ${clusterIssuerName}
+  name: ${KUADRANT_CLUSTER_ISSUER_NAME}
 spec:
   acme:
-    email: ${EMAIL} 
+    email: ${KUADRANT_EMAIL}
     privateKeySecretRef:
       name: le-secret
     server: https://acme-staging-v02.api.letsencrypt.org/directory
     solvers:
       - dns01:
           route53:
-            hostedZoneID: ${zid}
-            region: ${AWS_REGION}
+            hostedZoneID: ${KUADRANT_AWS_DNS_PUBLIC_ZONE_ID}
+            region: ${KUADRANT_AWS_REGION}
             accessKeyIDSecretRef:
               key: AWS_ACCESS_KEY_ID
               name: aws-credentials
@@ -107,25 +140,21 @@ spec:
 EOF
 ```
 
-Then wait for the `ClusterIssuer` to become ready as follows:
+Wait for the `ClusterIssuer` to become ready.
 
 ```bash
-kubectl wait clusterissuer/${clusterIssuerName} --for=condition=ready=true
+kubectl wait clusterissuer/${KUADRANT_CLUSTER_ISSUER_NAME} --for=condition=ready=true
 ```
 
-### Step 4 - Set up a Gateway
-
-For Kuadrant to balance traffic using DNS across two or more clusters, you must define a Gateway with a shared host. You will define this by using an HTTPS listener with a wildcard hostname based on the root domain. As mentioned earlier, you must apply these resources to all clusters. 
-
-NOTE: For now, the Gateway is set to accept an `HTTPRoute` from the same namespace only. This allows you to restrict who can use the Gateway until it is ready for general use.
+### Deploy a Gateway
 
 ```bash
 kubectl apply -f - <<EOF
 apiVersion: gateway.networking.k8s.io/v1
 kind: Gateway
 metadata:
-  name: ${gatewayName}
-  namespace: ${gatewayNS}
+  name: ${KUADRANT_GATEWAY_NAME}
+  namespace: ${KUADRANT_GATEWAY_NS}
   labels:
     kuadrant.io/gateway: "true"
 spec:
@@ -133,8 +162,8 @@ spec:
     listeners:
     - allowedRoutes:
         namespaces:
-          from: Same
-      hostname: "*.${rootDomain}"
+          from: All 
+      hostname: "*.${KUADRANT_ZONE_ROOT_DOMAIN}"
       name: api
       port: 443
       protocol: HTTPS
@@ -142,375 +171,222 @@ spec:
         certificateRefs:
         - group: ""
           kind: Secret
-          name: api-${gatewayName}-tls
+          name: api-${KUADRANT_GATEWAY_NAME}-tls
         mode: Terminate
 EOF
 ```
 
-Check the status of your Gateway as follows:
 
-```bash
-kubectl get gateway ${gatewayName} -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}'
-kubectl get gateway ${gatewayName} -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Programmed")].message}'
-```
-
-Your Gateway should be accepted and programmed (valid and assigned an external address). However, if you check your listener status as follows, you will see that it is not yet programmed or ready to accept traffic due to bad TLS configuration:
+Check the status of the `Gateway` ensuring the gateway is Accepted and Programmed:
 
 ```bash
-kubectl get gateway ${gatewayName} -n ${gatewayNS} -o=jsonpath='{.status.listeners[0].conditions[?(@.type=="Programmed")].message}'
+kubectl get gateway ${KUADRANT_GATEWAY_NAME} -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Programmed")].message}'
 ```
 
-Kuadrant can help with this by using a TLSPolicy.
-
-### Step 4a - (Optional) Configure metrics to be scraped from the Gateway instance
-
-If you have prometheus in your cluster, set up a PodMonitor to configure it to scrape metrics directly from the Gateway pod.
-This must be done in the namespace where the Gateway is running.
-This configuration is required for metrics such as `istio_requests_total`.
+Check the status of the listener, you will see that it is not yet programmed or ready to accept traffic due to bad TLS configuration. This will be fixed in the next step with the `TLSPolicy`:
 
 ```bash
-kubectl apply -f - <<EOF
-apiVersion: monitoring.coreos.com/v1
-kind: PodMonitor
-metadata:
-  name: istio-proxies-monitor
-  namespace: ${gatewayNS}
-spec:
-  selector:
-    matchExpressions:
-      - key: istio-prometheus-ignore
-        operator: DoesNotExist
-  podMetricsEndpoints:
-    - path: /stats/prometheus
-      interval: 30s
-      relabelings:
-        - action: keep
-          sourceLabels: ["__meta_kubernetes_pod_container_name"]
-          regex: "istio-proxy"
-        - action: keep
-          sourceLabels:
-            ["__meta_kubernetes_pod_annotationpresent_prometheus_io_scrape"]
-        - action: replace
-          regex: (\d+);(([A-Fa-f0-9]{1,4}::?){1,7}[A-Fa-f0-9]{1,4})
-          replacement: "[\$2]:\$1"
-          sourceLabels:
-            [
-              "__meta_kubernetes_pod_annotation_prometheus_io_port",
-              "__meta_kubernetes_pod_ip",
-            ]
-          targetLabel: "__address__"
-        - action: replace
-          regex: (\d+);((([0-9]+?)(\.|$)){4})
-          replacement: "\$2:\$1"
-          sourceLabels:
-            [
-              "__meta_kubernetes_pod_annotation_prometheus_io_port",
-              "__meta_kubernetes_pod_ip",
-            ]
-          targetLabel: "__address__"
-        - action: labeldrop
-          regex: "__meta_kubernetes_pod_label_(.+)"
-        - sourceLabels: ["__meta_kubernetes_namespace"]
-          action: replace
-          targetLabel: namespace
-        - sourceLabels: ["__meta_kubernetes_pod_name"]
-          action: replace
-          targetLabel: pod_name
-EOF
+kubectl get gateway ${KUADRANT_GATEWAY_NAME} -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.listeners[0].conditions[?(@.type=="Programmed")].message}'
 ```
 
-### Step 5 - Secure and protect the Gateway with auth, TLS, rate limit, and DNS policies
-
-While your Gateway is now deployed, it has no exposed endpoints and your listener is not programmed. Next, you can set up a `TLSPolicy` that leverages your CertificateIssuer to set up your listener certificates. 
-
-You will also define an `AuthPolicy` that will set up a default `403` response for any unprotected endpoints, as well as a `RateLimitPolicy` that will set up a default artificially low global limit to further protect any endpoints exposed by this Gateway.
-
-#### Set the Auth policy
-
-Set a default, deny-all `AuthPolicy` for your Gateway as follows:
+### Deploy the gateway TLS policy
 
 ```bash
 kubectl apply -f - <<EOF
 apiVersion: kuadrant.io/v1
-kind: AuthPolicy
+kind: TLSPolicy
 metadata:
-  name: ${gatewayName}-auth
-  namespace: ${gatewayNS}
+  name: ${KUADRANT_GATEWAY_NAME}-tls
+  namespace: ${KUADRANT_GATEWAY_NS}
 spec:
   targetRef:
+    name: ${KUADRANT_GATEWAY_NAME}
     group: gateway.networking.k8s.io
     kind: Gateway
-    name: ${gatewayName}
-  defaults:
-    rules:
-      authorization:
-        "deny":
-          opa:
-            rego: "allow = false"
+  issuerRef:
+    group: cert-manager.io
+    kind: ClusterIssuer
+    name: ${KUADRANT_CLUSTER_ISSUER_NAME}
 EOF
 ```
 
-Check that your auth policy was accepted by the controller as follows:
+Check that the `TLSpolicy` has an Accepted and Enforced status:
 
 ```bash
-kubectl get authpolicy ${gatewayName}-auth -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}'
-
+kubectl get tlspolicy ${KUADRANT_GATEWAY_NAME}-tls -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Enforced")].message}'
 ```
 
-#### Set the TLS policy
+### Secure and protect the Gateway with Auth, Rate Limit, and DNS policies.
+
+While the `Gateway` is now deployed, it currently has exposed endpoints. The next steps will be defining an `AuthPolicy` to set up a default `403` response for any unprotected endpoints, as well as a `RateLimitPolicy` to set up a default unrealistic low global limit to further protect any exposed endpoints.
 
-Set the `TLSPolicy` for your Gateway as follows:
+### Set the `Deny all` Gateway AuthPolicy
 
 ```bash
 kubectl apply -f - <<EOF
 apiVersion: kuadrant.io/v1
-kind: TLSPolicy
+kind: AuthPolicy
 metadata:
-  name: ${gatewayName}-tls
-  namespace: ${gatewayNS}
+  name: ${KUADRANT_GATEWAY_NAME}-auth
+  namespace: ${KUADRANT_GATEWAY_NS}
 spec:
   targetRef:
-    name: ${gatewayName}
     group: gateway.networking.k8s.io
     kind: Gateway
-  issuerRef:
-    group: cert-manager.io
-    kind: ClusterIssuer
-    name: ${clusterIssuerName}
+    name: ${KUADRANT_GATEWAY_NAME}
+  defaults:
+   rules:
+    authorization:
+      deny-all:
+        opa:
+          rego: "allow = false"
+    response:
+      unauthorized:
+        headers:
+          "content-type":
+            value: application/json
+        body:
+          value: |
+            {
+              "error": "Forbidden",
+              "message": "Access denied by default by the gateway operator. If you are the administrator of the service, create a specific auth policy for the route."
+            }
 EOF
 ```
 
-Check that your TLS policy was accepted by the controller as follows:
+Check that the `AuthPolicy` has Accepted and Enforced status:
 
 ```bash
-kubectl get tlspolicy ${gatewayName}-tls -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}'
-```
+kubectl get authpolicy ${KUADRANT_GATEWAY_NAME}-auth -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Enforced")].message}'
 
-#### Set the rate limit policy
+```
 
-Set the default `RateLimitPolicy` for your Gateway as follows:
+### Deploy the `low-limit` Gateway RateLimitPolicy
 
 ```bash
 kubectl apply -f  - <<EOF
 apiVersion: kuadrant.io/v1
 kind: RateLimitPolicy
 metadata:
-  name: ${gatewayName}-rlp
-  namespace: ${gatewayNS}
+  name: ${KUADRANT_GATEWAY_NAME}-rlp
+  namespace: ${KUADRANT_GATEWAY_NS}
 spec:
   targetRef:
     group: gateway.networking.k8s.io
     kind: Gateway
-    name: ${gatewayName}
+    name: ${KUADRANT_GATEWAY_NAME}
   defaults:
     limits:
       "low-limit":
         rates:
-        - limit: 2
+        - limit: 1
           window: 10s
 EOF
 ```
 
-To check your rate limits have been accepted, enter the following command:
+Check that the `RateLimitPolicy` has Accepted and Enforced status:
 
 ```bash
-kubectl get ratelimitpolicy ${gatewayName}-rlp -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}'
+kubectl get ratelimitpolicy ${KUADRANT_GATEWAY_NAME}-rlp -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Enforced")].message}'
 ```
 
-#### Set the DNS policy
-
-Set the `DNSPolicy` for your Gateway as follows:
+### Create the Gateway DNSPolicy
 
 ```bash
 kubectl apply -f - <<EOF
 apiVersion: kuadrant.io/v1
 kind: DNSPolicy
 metadata:
-  name: ${gatewayName}-dnspolicy
-  namespace: ${gatewayNS}
+  name: ${KUADRANT_GATEWAY_NAME}-dnspolicy
+  namespace: ${KUADRANT_GATEWAY_NS}
 spec:
   loadBalancing:
     defaultGeo: true
-    geo: GEO-US
+    geo: GEO-NA
     weight: 120
   targetRef:
-    name: ${gatewayName}
+    name: ${KUADRANT_GATEWAY_NAME}
     group: gateway.networking.k8s.io
     kind: Gateway
   providerRefs:
-  - name: aws-credentials
+  - name: aws-credentials # Secret created earlier
 EOF
-```    
-
-NOTE:  The `DNSPolicy` will use the DNS Provider `Secret` that you defined earlier.
-
-Check that your `DNSPolicy` has been accepted as follows:
-
-```bash
-kubectl get dnspolicy ${gatewayName}-dnspolicy -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}'
 ```
 
-#### Create an HTTP route
-
-Create an `HTTPRoute` for your Gateway as follows:
+Check that the `DNSPolicy` has been Accepted and Enforced:
 
 ```bash
-kubectl apply -f - <<EOF
-apiVersion: gateway.networking.k8s.io/v1
-kind: HTTPRoute
-metadata:
-  name: test
-  namespace: ${gatewayNS}
-spec:
-  parentRefs:
-  - name: ${gatewayName}
-    namespace: ${gatewayNS}
-  hostnames:
-  - "test.${rootDomain}"
-  rules:
-  - backendRefs:
-    - name: toystore
-      port: 80
-EOF
-```
-
-Check your Gateway policies are enforced as follows:
-
-```bash
-kubectl get dnspolicy ${gatewayName}-dnspolicy -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Enforced")].message}'
-kubectl get authpolicy ${gatewayName}-auth -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Enforced")].message}'
-kubectl get ratelimitpolicy ${gatewayName}-rlp -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Enforced")].message}'
-```
-
-Check your listener is ready as follows:
-
-```
-kubectl get gateway ${gatewayName} -n ${gatewayNS} -o=jsonpath='{.status.listeners[0].conditions[?(@.type=="Programmed")].message}'
-```
-
-### Step 6 - Test connectivity and deny all auth 
-
-You can use `curl` to hit your endpoint. You should see a `403`. Because this example uses Let's Encrypt staging, you can pass the `-k` flag:
-
-```bash
-curl -k -w "%{http_code}" https://$(kubectl get httproute test -n ${gatewayNS} -o=jsonpath='{.spec.hostnames[0]}')
+kubectl get dnspolicy ${KUADRANT_GATEWAY_NAME}-dnspolicy -n ${KUADRANT_GATEWAY_NS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Enforced")].message}'
 ```
 
-### Step 7 - Opening up the Gateway for other namespaces
-
-Because you have configured the Gateway, secured it with Kuadrant policies, and tested it, you can now open it up for use by other teams in other namespaces:
+### Test the `low-limit` and deny all policies
 
 ```bash
-kubectl patch gateway ${gatewayName} -n ${gatewayNS} --type='json' -p='[{"op": "replace", "path": "/spec/listeners/0/allowedRoutes/namespaces/from", "value":"All"}]'
+while :; do curl -k --write-out '%{http_code}\n' --silent --output /dev/null  "https://api.$KUADRANT_ZONE_ROOT_DOMAIN/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done
 ```
 
-### Step 8 - Extending this Gateway to multiple clusters and configuring geo-based routing
-
-To distribute this Gateway across multiple clusters, repeat this setup process for each cluster. By default, this will implement a round-robin DNS strategy to distribute traffic evenly across the different clusters. Setting up your Gateways to serve clients based on their geographic location is straightforward with your current configuration.
+### (Optional) Configure metrics to be scraped from the Gateway instance
 
-Assuming that you have deployed Gateway instances across multiple clusters as per this guide, the next step involves updating the DNS controller with the geographic regions of the visible Gateways.
-
-For instance, if you have one cluster in North America and another in the EU, you can direct traffic to these Gateways based on their location by applying the appropriate labels:
-
-For your North American cluster, enter the following command:
+If Prometheus is installed on the cluster, set up a `PodMonitor` to configure it to scrape metrics directly from the Gateway pod.
+This must be done in the namespace where the Gateway is running. For a list of the metrics you'll get see the Kuadrant [docs](https://docs.kuadrant.io/0.11.0/kuadrant-operator/doc/observability/metrics/)
 
 ```bash
-kubectl label --overwrite gateway ${gatewayName} kuadrant.io/lb-attribute-geo-code=US -n ${gatewayNS}
-```
-
-## Application developer workflow
-
-This section of the walkthrough focuses on using an OpenAPI Specification (OAS) to define an API. You will use Kuadrant OAS extensions to specify the routing, authentication, and rate limiting requirements. Next, you will use the `kuadrantctl` tool to generate an `AuthPolicy`, an `HTTPRoute`, and a `RateLimitPolicy`, which you will then apply to your cluster to enforce the settings defined in your OAS.
-
-NOTE: While this section uses the `kuadrantctl` tool, this is not essential. You can also create and apply an `AuthPolicy`, `RateLimitPolicy`, and `HTTPRoute` by using the `oc` or `kubectl` commands.
-
-### Prerequisites
-
-- You have installed `kuadrantctl`. You can find a compatible binary and download it from the [kuadrantctl releases page](https://github.com/Kuadrant/kuadrantctl/releases/tag/v0.2.2).
-- You have the ability to distribute resources generated by `kuadrantctl` to multiple clusters, as though you are a platform engineer.
-
-
-### Step 1 - Deploy the toystore app
-
-To begin, deploy a new version of the `toystore` app to a developer namespace as follows:
-
-```bash
-kubectl apply -f https://raw.githubusercontent.com/Kuadrant/Kuadrant-operator/main/examples/toystore/toystore.yaml -n ${devNS}
-```
-
-
-### Step 2 - Set up HTTPRoute and backend
-
-Copy at least one of the following example OAS to a local location:
-
-- [Sample OAS for rate limiting with API key](../../../examples/oas-apikey.yaml)
-
-- [Sample OAS for rate limiting with OIDC](../../../examples/oas-oidc.yaml)
-
-Set up some new environment variables as follows:
-
-```bash
-export oasPath=examples/oas-apikey.yaml
-# Ensure you still have these environment variables setup from the start of this guide:
-export rootDomain=example.com
-export gatewayNS=api-gateway
-```
-
-### Step 3 - Use OAS to define your HTTPRoute rules
-
-You can generate Kuadrant and Gateway API resources directly from OAS documents by using an `x-kuadrant` extension.
-
-NOTE: For a more in-depth look at the OAS extension, see the [kuadrantctl documentation](https://docs.kuadrant.io/latest/kuadrantctl/).
-
-You will use `kuadrantctl` to generate your `HTTPRoute`.
-
-NOTE: The sample OAS has some placeholders for namespaces and domains. You will inject valid values into these placeholders based on your previous environment variables.
-
-Generate the resource from your OAS as follows, (`envsubst` will replace the placeholders):
-
-```bash
-cat $oasPath | envsubst | kuadrantctl generate gatewayapi httproute --oas - | kubectl apply -f -
-```
-
-```bash
-kubectl get httproute toystore -n ${devNS} -o=yaml
-```
-
-You should see that this route is affected by the `AuthPolicy` and `RateLimitPolicy` defined as defaults on the Gateway in the Gateway namespace.
-
-```yaml
-- lastTransitionTime: "2024-04-26T13:37:43Z"
-        message: Object affected by AuthPolicy demo/external
-        observedGeneration: 2
-        reason: Accepted
-        status: "True"
-        type: kuadrant.io/AuthPolicyAffected
-- lastTransitionTime: "2024-04-26T14:07:28Z"
-        message: Object affected by RateLimitPolicy demo/external
-        observedGeneration: 1
-        reason: Accepted
-        status: "True"
-        type: kuadrant.io/RateLimitPolicyAffected        
-```
-
-### Step 4 - Test connectivity and deny-all auth 
-
-You can use `curl` to hit an endpoint in the toystore app. Because you are using Let's Encrypt staging in this example, you can pass the `-k` flag as follows:
-
-```bash
-curl -s -k -o /dev/null -w "%{http_code}" "https://$(kubectl get httproute toystore -n ${devNS} -o=jsonpath='{.spec.hostnames[0]}')/v1/toys"
+kubectl apply -f - <<EOF
+apiVersion: monitoring.coreos.com/v1
+kind: PodMonitor
+metadata:
+  name: istio-proxies-monitor
+  namespace: ${KUADRANT_GATEWAY_NS}
+spec:
+  selector:
+    matchExpressions:
+      - key: istio-prometheus-ignore
+        operator: DoesNotExist
+  podMetricsEndpoints:
+    - path: /stats/prometheus
+      interval: 30s
+      relabelings:
+        - action: keep
+          sourceLabels: ["__meta_kubernetes_pod_container_name"]
+          regex: "istio-proxy"
+        - action: keep
+          sourceLabels:
+            ["__meta_kubernetes_pod_annotationpresent_prometheus_io_scrape"]
+        - action: replace
+          regex: (\d+);(([A-Fa-f0-9]{1,4}::?){1,7}[A-Fa-f0-9]{1,4})
+          replacement: "[\$2]:\$1"
+          sourceLabels:
+            [
+              "__meta_kubernetes_pod_annotation_prometheus_io_port",
+              "__meta_kubernetes_pod_ip",
+            ]
+          targetLabel: "__address__"
+        - action: replace
+          regex: (\d+);((([0-9]+?)(\.|$)){4})
+          replacement: "\$2:\$1"
+          sourceLabels:
+            [
+              "__meta_kubernetes_pod_annotation_prometheus_io_port",
+              "__meta_kubernetes_pod_ip",
+            ]
+          targetLabel: "__address__"
+        - action: labeldrop
+          regex: "__meta_kubernetes_pod_label_(.+)"
+        - sourceLabels: ["__meta_kubernetes_namespace"]
+          action: replace
+          targetLabel: namespace
+        - sourceLabels: ["__meta_kubernetes_pod_name"]
+          action: replace
+          targetLabel: pod_name
+EOF
 ```
 
-You are getting a `403` because of the existing default, deny-all `AuthPolicy` applied at the Gateway. You can override this for your `HTTPRoute`.
-
-Choose one of the following options:
 
-- API key auth flow
-- OpenID Connect auth flow 
+### Override the Gateway's deny-all AuthPolicy 
 
-### Step 5 - Set up API key auth flow
+### Set up API key auth flow
 
-Set up an example API key in each cluster as follows:
+Set up an example API key for the new users:
 
 ```bash
 kubectl apply -f - <<EOF
@@ -518,7 +394,7 @@ apiVersion: v1
 kind: Secret
 metadata:
   name: toystore-api-key
-  namespace: ${devNS}
+  namespace: ${KUADRANT_DEVELOPER_NS}
   labels:
     authorino.kuadrant.io/managed-by: authorino
     kuadrant.io/apikeys-by: api_key
@@ -528,167 +404,101 @@ type: Opaque
 EOF
 ```
 
-Next, generate an `AuthPolicy` that uses secrets in your cluster as API keys as follows:
+Create a new AuthPolicy in a different namespace that overrides the `Deny all` created earlier:
 
 ```bash
-cat $oasPath | envsubst | kuadrantctl generate kuadrant authpolicy --oas -
-```
-
-From this, you can see an `AuthPolicy` generated based on your OAS that will look for API keys in secrets labeled `api_key` and look for that key in the header `api_key`. You can now apply this to the Gateway as follows:
-
-```bash
-cat $oasPath | envsubst | kuadrantctl generate kuadrant authpolicy --oas -  | kubectl apply -f -
-```
-
-You should get a `200` from the following `GET` because it has no auth requirement:
-
-```bash
-curl -s -k -o /dev/null -w "%{http_code}" "https://$(kubectl get httproute toystore -n ${devNS} -o=jsonpath='{.spec.hostnames[0]}')/v1/toys"
-```
-
-You should get a `401` for the following `POST` request because it does not have any auth requirements:
-
-```bash
-curl -XPOST -s -k -o /dev/null -w "%{http_code}" "https://$(kubectl get httproute toystore -n ${devNS} -o=jsonpath='{.spec.hostnames[0]}')/v1/toys"
-```
-
-Finally, if you add your API key header, with a valid key as follows, you should get a `200` response:
-
-```bash
-curl -XPOST -H 'api_key: secret' -s -k -o /dev/null -w "%{http_code}" "https://$(kubectl get httproute toystore -n ${devNS} -o=jsonpath='{.spec.hostnames[0]}')/v1/toys"
-```
-
-### Optional: Step 6 - Set up OpenID Connect auth flow (skip if using API key only)
-
-This section of the walkthrough uses the `kuadrantctl` tool to create an `AuthPolicy` that integrates with an OpenID provider and a `RateLimitPolicy` that leverages JWT values for per-user rate limiting. It is important to note that OpenID requires an external provider. Therefore, you should adapt the following example to suit your specific needs and provider.
-
-The platform engineer workflow established default policies for authentication and rate limiting at your Gateway. The new developer-defined policies, which you will create, are intended to target your HTTPRoute and will supersede the existing policies for requests to your API endpoints, similar to your previous API key example.
-
-The example OAS uses Kuadrant-based extensions. These extensions enable you to define routing and service protection requirements. For more details, see [OpenAPI Kuadrant extensions](https://docs.kuadrant.io/latest/kuadrantctl/doc/openapi-kuadrant-extensions/).
-
-#### Prerequisites
-
-- You have installed and configured an OpenID Connect provider, such as <https://www.keycloak.org/>. 
-- You have a realm, client, and users set up. This example assumes a realm in a Keycloak instance called `toystore`.
-- Copy the OAS from [sample OAS for rate-limiting and OIDC](../../../examples/oas-oidc.yaml) to a local location.
-
-#### Set up an OpenID AuthPolicy
-
-Set the following environment variables:
-
-```bash
-export openIDHost=some.keycloak.com
-export oasPath=examples/oas-oidc.yaml
-```
-
-NOTE: The sample OAS has some placeholders for namespaces and domains. You will inject valid values into these placeholders based on your previous environment variables.
-
-You can use your OAS and `kuadrantctl` to generate an `AuthPolicy` to replace the default on the Gateway as follows:
-
-```bash
-cat $oasPath | envsubst | kuadrantctl generate kuadrant authpolicy --oas -
-```
-
-If you are happy with the generated resource, you can apply it to the cluster as follows:
-
-```bash
-cat $oasPath | envsubst | kuadrantctl generate kuadrant authpolicy --oas - | kubectl apply -f -
-```
-
-You should see in the status of the `AuthPolicy` that it has been accepted and enforced:
-
-```bash
-kubectl get authpolicy -n ${devNS} toystore -o=jsonpath='{.status.conditions}'
-```
-
-On your `HTTPRoute`, you should also see it now affected by this `AuthPolicy` in the toystore namespace:
-
-```bash
-kubectl get httproute toystore -n ${devNS} -o=jsonpath='{.status.parents[0].conditions[?(@.type=="kuadrant.io/AuthPolicyAffected")].message}'
-```
-
-#### Test your OpenID AuthPolicy
-
-You can test your `AuthPolicy` as follows:
-
-```bash
-export ACCESS_TOKEN=$(curl -k -H "Content-Type: application/x-www-form-urlencoded" \
-        -d 'grant_type=password' \
-        -d 'client_id=toystore' \
-        -d 'scope=openid' \
-        -d 'username=bob' \
-        -d 'password=p' "https://${openIDHost}/auth/realms/toystore/protocol/openid-connect/token" | jq -r '.access_token')
-```        
-
-```bash
-curl -k -XPOST --write-out '%{http_code}\n' --silent --output /dev/null "https://$(kubectl get httproute toystore -n ${devNS} -o=jsonpath='{.spec.hostnames[0]}')/v1/toys"
-```
-
-You should see a `401` response code. Make a request with a valid bearer token as follows:
-
-```bash
-curl -k -XPOST --write-out '%{http_code}\n' --silent --output /dev/null -H "Authorization: Bearer $ACCESS_TOKEN" "https://$(kubectl get httproute toystore -n ${devNS} -o=jsonpath='{.spec.hostnames[0]}')/v1/toys"
+kubectl apply -f - <<EOF
+apiVersion: kuadrant.io/v1
+kind: AuthPolicy
+metadata:
+  name: toystore-auth
+  namespace: ${KUADRANT_DEVELOPER_NS}
+spec:
+  targetRef:
+    group: gateway.networking.k8s.io
+    kind: HTTPRoute
+    name: toystore
+  rules:
+    authentication:
+      "api-key-users":
+        apiKey:
+          selector:
+            matchLabels:
+              app: toystore
+        credentials:
+          authorizationHeader:
+            prefix: APIKEY
+    response:
+      success:
+        filters:
+          "identity":
+            json:
+              properties:
+                "userid":
+                  selector: auth.identity.metadata.annotations.secret\.kuadrant\.io/user-id
+EOF
 ```
 
-You should see a `200` response code.
+### Override `low-limit` RateLimitPolicy for specific users
 
-### Step 7 - Set up rate limiting
-
-Lastly, you can generate your `RateLimitPolicy` to add your rate limits, based on your OAS file. Rate limiting is simplified for this walkthrough and is based on either the bearer token or the API key value. There are more advanced examples in the How-to guides on the Kuadrant documentation site, for example: [Authenticated rate limiting with JWTs and Kubernetes RBAC](https://docs.kuadrant.io/latest/kuadrant-operator/doc/user-guides/ratelimiting/authenticated-rl-with-jwt-and-k8s-authnz/).
-
- You can continue to use this sample OAS document, which includes both authentication and a rate limit:
+Create a new `RateLimitPolicy` in a different namespace to override the default `RateLimitPolicy` created earlier:
 
 ```bash
-export oasPath=examples/oas-oidc.yaml
-
+kubectl apply -f - <<EOF
+apiVersion: kuadrant.io/v1
+kind: RateLimitPolicy
+metadata:
+  name: toystore-rlp
+  namespace: ${KUADRANT_DEVELOPER_NS}
+spec:
+  targetRef:
+    group: gateway.networking.k8s.io
+    kind: HTTPRoute
+    name: toystore
+  limits:
+    "general-user":
+      rates:
+      - limit: 1
+        window: 3s
+      counters:
+      - expression: auth.identity.userid
+      when:
+      - predicate: "auth.identity.userid != 'bob'"
+    "bob-limit":
+      rates:
+      - limit: 2
+        window: 3s
+      when:
+      - predicate: "auth.identity.userid == 'bob'"
+EOF
 ```
 
-Again, you should see the rate limit policy accepted and enforced:
+The `RateLimitPolicy` should be Accepted and Enforced:
 
 ```bash
-kubectl get ratelimitpolicy -n ${devNS} toystore -o=jsonpath='{.status.conditions}'
+kubectl get ratelimitpolicy -n ${KUADRANT_DEVELOPER_NS} toystore-rlp -o=jsonpath='{.status.conditions}'
 ```
 
-On your `HTTRoute`, you should now see it is affected by the `RateLimitPolicy` in the same namespace:
+Check the status of the `HTTPRoute`, is now affected by the `RateLimitPolicy` in the same namespace:
 
 ```bash
-kubectl get httproute toystore -n ${devNS} -o=jsonpath='{.status.parents[0].conditions[?(@.type=="kuadrant.io/RateLimitPolicyAffected")].message}'
+kubectl get httproute toystore -n ${KUADRANT_DEVELOPER_NS} -o=jsonpath='{.status.parents[0].conditions[?(@.type=="kuadrant.io/RateLimitPolicyAffected")].message}'
 ```
 
-#### Test your RateLimitPolicy
-
-You can now test your rate limiting as follows:
+### Test the new Rate limit and Auth policy
 
-NOTE: You might need to wait a minute for the new rate limits to be applied. With the following requests, you should see a number of 429 responses.
-
-##### API Key auth
+#### Send requests as Alice:
 
 ```bash
-for i in {1..3}
-do
-printf "request $i "
-curl -XPOST -H 'api_key:secret' -s -k -o /dev/null -w "%{http_code}"  "https://$(kubectl get httproute toystore -n ${devNS} -o=jsonpath='{.spec.hostnames[0]}')/v1/toys"
-printf "\n -- \n"
-done 
+while :; do curl -k --write-out '%{http_code}\n' --silent --output /dev/null -H 'Authorization: APIKEY IAMALICE' "https://api.$KUADRANT_ZONE_ROOT_DOMAIN/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done
 ```
-##### OpenID Connect auth
 
-```bash
-export ACCESS_TOKEN=$(curl -k -H "Content-Type: application/x-www-form-urlencoded" \
-        -d 'grant_type=password' \
-        -d 'client_id=toystore' \
-        -d 'scope=openid' \
-        -d 'username=bob' \
-        -d 'password=p' "https://${openIDHost}/auth/realms/toystore/protocol/openid-connect/token" | jq -r '.access_token')
-```      
+#### Send requests as Bob:
 
 ```bash
-for i in {1..3}
-do
-curl -k -XPOST --write-out '%{http_code}\n' --silent --output /dev/null -H "Authorization: Bearer $ACCESS_TOKEN" https://$(kubectl get httproute toystore -n ${devNS}-o=jsonpath='{.spec.hostnames[0]}')/v1/toys
-done
+while :; do curl -k --write-out '%{http_code}\n' --silent --output /dev/null -H 'Authorization: APIKEY IAMBOB' "https://api.$KUADRANT_ZONE_ROOT_DOMAIN/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done
 ```
 
 ## Conclusion
 
-You have completed the secure, protect, and connect walkthrough. To learn more about Kuadrant, visit <https://docs.kuadrant.io>.
+To learn more about Kuadrant and see more how to guides, visit Kuadrant [documentation](https://docs.kuadrant.io)