docs: added info about restricting cross unit communication

docs/explanation/traffic-authorization.md

@@ -59,6 +59,10 @@ class DetailsK8sCharm(CharmBase):
 
 This means that, when related to a Beacon charm via the `service_mesh` relation, `bookinfo-details-k8s` will request traffic authorization for every application related to its `details` integration.  Specifically, it will request that those related applications can `GET` the `/health` and `/details/*` endpoints on a given port.  It is then the responsibility of the related beacon charm to create the policies necessary for this communication in the given service mesh.
 
+```{note}
+By default peer units of the charm are not allowed to access each other. This behavior can be changed if required. Check this [How-to](../how-to/add-mesh-support-to-your-charm.md) guide for more details. 
+```
+
 ## Authorization Management in Charmed Istio
 
 Istio's [Authorization](https://istio.io/latest/docs/concepts/security/#authorization) model centers around the [`AuthorizationPolicy`](https://istio.io/latest/docs/reference/config/security/authorization-policy/).  This object is how service-to-service communication is opened in an Istio service mesh.  The [istio-beacon-k8s](https://charmhub.io/istio-beacon-k8s) charm manages `AuthorizationPolicies` for Charmed Istio.  It automatically creates policies for charms related to it via the [`service_mesh`](https://charmhub.io/istio-beacon-k8s/integrations) interface.  

docs/how-to/add-mesh-support-to-your-charm.md

@@ -91,6 +91,40 @@ class MyCharm(CharmBase):
 
 Exactly what should be defined for your `Endpoint`s depends on the application you've charmed.  Generally, you can look at your applications API reference or typical usage and include exactly what is needed, exposing only the necessary attack surface.  
 
+When a charm that is on the mesh is scaled to have more than one unit, by default all the units of the charm are not allowed to communicate with each other. To allow communication between the peers, you must explicitly add another `UnitPolicy` for the peers relation endpoint allowing access to the required ports.
+
+For example:
+
+```python
+class MyCharm(CharmBase):
+    def __init__(self, *args):
+        super().__init__(*args)
+    self._mesh = ServiceMeshConsumer(
+        self,
+        policies=[
+            AppPolicy(
+                relation="database",          # On the database relation
+                endpoints=[                   # allow a related application to access...
+                    Endpoint(
+                        paths=["/db"],                     # these specific paths
+                        ports=[DB_PORT],                   # on these specific ports
+                        methods=[Method.get, Method.Post], # using only these methods
+                    ),
+                ],
+            ),
+            UnitPolicy(
+                relation="metrics-endpoint",  # On the metrics-endpoint relations
+                ports=[HTTP_PORT],  # allow a related application to access this charm's individual units on these specific ports
+            ),
+            UnitPolicy(
+                relation="charm-peers",  # On the peers relation. FYI: use the name of the peers endpoint used in your charm.
+                ports=[HTTP_PORT],  # allow the peer units to access each other on the HTTP_PORT
+            )
+        ],
+    )
+```
+
+
 ## Cross-model Integrations (Optional)
 
 If your Charm provides integrations that can be used cross-model, the `ServiceMeshConsumer` library offers the additional `provide-cmr-mesh` and `require-cmr-mesh` integrations to ensure these generate policies properly.  These additional integrations are required because Juju cross-model relations do not natively provide all the information needed for a service mesh authorization policy to be generated.