OSSM-1148 [DOCS] Istio Ambient mode waypoint docs: L7 features

install/ossm-istio-ambient-mode.adoc

@@ -41,6 +41,12 @@ include::modules/ossm-deploying-waypoint-proxy.adoc[leveloffset=+1]
 
 include::modules/ossm-enabling-cross-namespace-waypoint-usage.adoc[leveloffset=+1]
 
+include::modules/ossm-about-l7-features-ambient-mode.adoc[leveloffset=+1]
+
+include::modules/ossm-routing-traffic-using-waypoint-proxies.adoc[leveloffset=+1]
+
+include::modules/ossm-adding-authorization-policy.adoc[leveloffset=+1]
+
 [role="_additional-resources"]
 [id="additional-resources_{context}"]
 == Additional resources

modules/ossm-about-l7-features-ambient-mode.adoc

@@ -0,0 +1,15 @@
+// Module included in the following assemblies:
+
+// * service-mesh-docs-main/install/ossm-istio-ambient-mode.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="ossm-about-l7-features-ambient-mode_{context}"]
+= About Layer 7 features in ambient mode
+
+Ambient mode includes stable Layer 7 (L7) capabilities implemented through the Gateway API `HTTPRoute` resource and the {istio} `AuthorizationPolicy` resource.
+
+The `AuthorizationPolicy` resource works in both sidecar and ambient modes. In ambient mode, authorization policies can be targeted for `ztunnel` enforcement or attached for waypoint enforcement. To attach a policy to a waypoint, include a `targetRef` that references either the waypoint itself or a Service configured to use that waypoint.
+
+You can attach Layer 4 (L4) or L7 policies to the waypoint proxy to ensure correct identity-based enforcement, as the destination `ztunnel` recognizes traffic by the identity of the waypoint, once it is part of the traffic path.
+
+{istio} peer authentication policies, which configure mutual TLS (mTLS) modes, are supported by ztunnel. In ambient mode, policies that set the mode to `DISABLE` are ignored because ztunnel and HBONE always enforce mTLS. For more information, see "Peer authentication".

modules/ossm-adding-authorization-policy.adoc

@@ -0,0 +1,98 @@
+// Module included in the following assemblies:
+
+// * service-mesh-docs-main/install/ossm-istio-ambient-mode.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-adding-authorization-policy_{context}"]
+= Adding authorization policy
+
+Use an Layer 7 (L7) authorization policy to explicitly allow the `curl` service to send `GET` requests to the `productpage` service while blocking all other operations.
+
+.Procedure
+
+. Create the authorization policy similar to the following example:
++
+.Example configuration
+[source,yaml]
+----
+apiVersion: security.istio.io/v1
+kind: AuthorizationPolicy
+metadata:
+  name: productpage-waypoint
+  namespace: bookinfo
+spec:
+  targetRefs:
+  - kind: Service
+    group: ""
+    name: productpage
+  action: ALLOW
+  rules:
+  - from:
+    - source:
+        principals:
+        - cluster.local/ns/default/sa/curl
+    to:
+    - operation:
+        methods: ["GET"]
+----
+
+. Apply the authorization policy by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f authorization-policy.yaml
+----
+
+[NOTE]
+====
+The `targetRefs` field specifies the service targeted by the authorization policy of the waypoint proxy.
+====
+
+.Verification
+
+. Deploy the `curl` application in the `default` namespace by running the following command:
++
+[source,terminal]
+----
+$ oc apply -n default -f https://raw.githubusercontent.com/openshift-service-mesh/istio/refs/heads/master/samples/curl/curl.yaml
+----
+
+. Wait and get the status of the `curl` deployment by running the following command:
++
+[source,terminal]
+----
+$ oc -n default rollout status deploy/curl --timeout=3m
+----
+
+. Verify that a `GET` request to the `productpage` service succeeds with an HTTP 200 response when made from the `default/curl` pod, by running the following command:
++
+[source,terminal]
+----
+$ oc -n default exec deploy/curl -- sh -c \
+  'curl -s -o /dev/null -w "HTTP %{http_code}\n" http://productpage.bookinfo.svc.cluster.local:9080/productpage'
+----
+
+. Verify that a `POST` request to the same service is denied with an HTTP 403 response due to the applied authorization policy, by running the following command:
++
+[source,terminal]
+----
+$ oc -n default exec deploy/curl -- sh -c \
+  'curl -s -o /dev/null -w "HTTP %{http_code}\n" -X POST http://productpage.bookinfo.svc.cluster.local:9080/productpage'
+----
+
+. Verify that a `GET` request from another service, such as the `ratings` pod in the `bookinfo` namespace, is also denied with `RBAC: access denied`, by running the following command:
++
+[source,terminal]
+----
+$ oc exec "$(oc get pod -l app=ratings -n bookinfo \
+-o jsonpath='{.items[0].metadata.name}')" \
+-c ratings -n bookinfo \
+-- curl -sS productpage:9080/productpage
+----
+
+. Delete the `curl` application to clean up resources by running the following command:
++
+[source,terminal]
+----
+$ oc delete -n default -f https://raw.githubusercontent.com/openshift-service-mesh/istio/refs/heads/master/samples/curl/curl.yaml
+----

modules/ossm-routing-traffic-using-waypoint-proxies.adoc

@@ -0,0 +1,57 @@
+// Module included in the following assemblies:
+
+// * service-mesh-docs-main/install/ossm-istio-ambient-mode.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="ossm-routing-traffic-using-waypoint-proxies_{context}"]
+= Routing traffic using waypoint proxies
+
+You can use a deployed waypoint proxy to split traffic between different versions of the Bookinfo `reviews` service for feature testing or A/B testing.
+
+.Procedure
+
+. Create the traffic routing configuration similar to the following example:
++
+.Example configuration
+[source,yaml]
+----
+apiVersion: gateway.networking.k8s.io/v1
+kind: HTTPRoute
+metadata:
+  name: reviews
+  namespace: bookinfo
+spec:
+  parentRefs:
+  - group: ""
+    kind: Service
+    name: reviews
+    port: 9080
+  rules:
+  - backendRefs:
+    - name: reviews-v1
+      port: 9080
+      weight: 90
+    - name: reviews-v2
+      port: 9080
+      weight: 10
+----
+
+. Apply the traffic routing configuration by running the following command:
++
+[source,terminal]
+----
+$ oc apply -f traffic-route.yaml
+----
+
+.Verification
+
+* Open the `productpage` service from within the ratings pod by running the following command:
++
+[source,terminal]
+----
+$ oc exec "$(oc get pod -l app=ratings -n bookinfo \
+-o jsonpath='{.items[0].metadata.name}')" -c ratings -n bookinfo \
+-- curl -sS productpage:9080/productpage | grep -om1 'reviews-v[12]'
+----
++
+Most responses (90%) will contain `reviews-v1` output, while a smaller portion (10%) will contain `reviews-v2` output.