docs: added info about restricting cross unit communication

Author: adhityaravi

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 different units of the charm are allowed to access each other without any policy restrictions. 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,37 @@ 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 allowed to communicate with each other Without any restriction. But the `ServiceMeshConsumer` allows you to configure your charm to restrict the cross unit communication within your charm. This can be achieved by setting the `restrict_cross_unit_communication` argument of the `ServiceMeshConsumer` object to `True`.
+
+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
+            ),
+        ],
+        restrict_cross_unit_communication=True,  # restrict the communication between the units of this charm
+    )
+```
+
+
 ## 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.