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

[shreyasiddhartha]

Change type: Doc update; Istio Ambient mode waypoint docs: L7 features

Doc JIRA: https://issues.redhat.com/browse/OSSM-11148

Fix Version: service-mesh-docs-main and service-mesh-docs-3.2

Doc Preview:

SME Review/QE Review:
Peer Review:

[ocpdocs-previewbot]

🤖 Wed Oct 08 05:42:57 - Prow CI generated the docs preview:

https://100107--ocpdocs-pr.netlify.app/openshift-service-mesh/latest/install/ossm-istio-ambient-mode.html

[openshift-ci]

@shreyasiddhartha: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[shreyasiddhartha]

/label service-mesh

[unsortedhashsets]

Confirm configurations and commands with rosa/ipv6/dualstack
+ with verification bellow on same clusters

However, suppose that can be added CLI verification replacing Open the bookinfo application in a web browser ... as on previous steps we did not create route/gw for bookinfo to open it in a browser 🤔

for: 1.

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 -o 'reviews-v[12]'

Just to get outputs as reviews-v1 or reviews-v2 (~90% will be v1)

for 2.

Verified with extra curl pod in default namespace as example requires cluster.local/ns/default/sa/curl

oc apply -n default -f https://raw.githubusercontent.com/openshift-service-mesh/istio/refs/heads/master/samples/curl/curl.yaml
oc -n default rollout status deploy/curl --timeout=3m

And two curl commands:

Get request should pass with 200 only from default/curl

oc -n default exec deploy/curl -- sh -c \
  'curl -s -o /dev/null -w "HTTP code: %{http_code}\n" http://productpage.bookinfo.svc.cluster.local:9080/productpage'

with output HTTP code: 200

Post request should fail with 403 even from default/curl

oc -n default exec deploy/curl -- sh -c \
  'curl -s -o /dev/null -w "HTTP code: %{http_code}\n" -X POST http://productpage.bookinfo.svc.cluster.local:9080/productpage'

with output HTTP code: 403

CC @shreyasiddhartha @sridhargaddam

[sridhargaddam]

However, suppose that can be added CLI verification replacing Open the bookinfo application in a web browser ... as on previous steps we did not create route/gw for bookinfo to open it in a browser 🤔

Good observation Mikhail. Recommending the user to use webbrowser without any instructions for ingress-gw/route will be an incomplete documentation. Mikhail, can you please suggest inline changes so that @shreyasiddhartha can make necessary changes.

[sridhargaddam]

I also like the suggestion from Mikhail about the successful (HTTP 200 OK) and failure scenarios using Auth policies.

[unsortedhashsets]

Here are inline updates with commands and doc-like words :D

[unsortedhashsets]

Open the `bookinfo` application in a web browser and refresh the page several times. Most requests (90%) are routed to `reviews-v1`, which displays no stars, while a smaller portion (10%) are routed to `reviews-v2`, which displays black stars.

Need to replace verification section as we did not applied gw/route before to make bookinfo accessible in browser, like (example without doc styling) :

---

Run the following curl command from within the ratings pod to access the productpage. Most responses (90%) will contain reviews-v1, while a smaller portion (10%) will contain reviews-v2 output.

$ 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]'

[unsortedhashsets]

Add .Verification section like (example without doc styling) :

---

To verify access control, deploy a curl application in the default namespace. This is required because the example policy references the cluster.local/ns/default/sa/curl service account:

a. Apply curl application deployment

$ oc apply -n default -f https://raw.githubusercontent.com/openshift-service-mesh/istio/refs/heads/master/samples/curl/curl.yaml

b. Wait curl application is ready

$ oc -n default rollout status deploy/curl --timeout=3m

A GET request to the productpage service should succeed (HTTP 200) when made from the default/curl pod:

$ 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'

A POST request to the same service should be denied (HTTP 403) due to the applied authorization policy, even when made from the same pod:

$ 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'

A GET request from another service, such as the ratings pod in the bookinfo namespace, will also be denied with RBAC: access denied. This confirms that only requests from the explicitly allowed service account are permitted.:

$ 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

Clean-up curl application

$ oc delete -n default -f https://raw.githubusercontent.com/openshift-service-mesh/istio/refs/heads/master/samples/curl/curl.yaml