K8s Istio authorization policies tutorial - new screenshots

docs/quick-tutorials/k8s-istio-authorization-policies.mdx

@@ -161,9 +161,9 @@ And upon clicking the green arrow:
 ![Access graph](/img/quick-tutorials/k8s-istio-authorization-policies/protected-edge.png)
 
 It's now clear what happened:
-1. The server is now protected, and is also blocking some of its clients. Click on it and go to focus mode, to see what's allowed and how to unblock any blocked clients (if desired).
-2. Calls from **[client]** → **[nginx]** are declared and therefore allowed (solid green arrow).
-3. Calls from **[client-other]** → **[nginx]** are not declared and therefore blocked (dashed red arrow). Click on the arrow to see what to do about it.
+1. The server is now protected, and is also blocking some of its clients.
+2. Calls from **[client]** → **[nginx]** are declared and therefore allowed (green arrow).
+3. Calls from **[client-other]** → **[nginx]** are not declared and therefore blocked (red arrow). Click on the arrow to see what to do about it.
 
 :::tip Done!
 Otterize did its job of both protecting the server *and* allowing intended access.
@@ -190,7 +190,7 @@ with a server in a namespace, and uses service accounts to identify clients, as
    The Istio authorization policy stipulates that it applies to the ingress of server pods with this label.
 2. The client's service account is looked up through its pod, and used in the policy.
    The authorization policy stipulates that only services with this service account can access the server.
-   In the event that the service account is shared by multiple services, an Event is placed on the ClientIntent to warn about this, which is also picked up as a warning in Otterize Cloud, if connected.
+   In the event that the service account is shared by multiple services, an Event is placed on the `ClientIntent` to warn about this, which is also picked up as a warning in Otterize Cloud, if connected.
 
 Otterize saved us from doing all this work: by simply declaring the client's intents in `intents.yaml`,
 all the appropriate configuration was managed automatically behind the scenes.