Updating the egress tutorial to include a domain name clientintent ex…

…ample

docs/features/network-mapping-network-policies/reference/README.mdx

@@ -1,10 +1,10 @@
 ---
 sidebar_position: 3
 title: Reference
-hide_table_of_contents: true
+hide_table_of_contents: false
 ---
 
-### ClientIntents example (YAML)
+## ClientIntents example (YAML)
 
 ```yaml
 apiVersion: k8s.otterize.com/v1alpha3
@@ -28,8 +28,22 @@ spec:
           methods: [ get, post ]
 ```
 
+#### ClientIntents and DNS values
 
-### Helm Chart options
+When a ClientIntent is specified utilizing DNS identifiers, such as domain names, it initiates a sequence of operations to integrate the relevant IP addresses into the respective NetworkPolicies.
+
+1. The NetworkMapper incorporates a DNS cache layer, which identifies and archives all resolved DNS records alongside their corresponding IPv4 and IPv6 IP addresses.
+2. Without a ClientIntent associated with the given domain or its related IP addresses, Otterize will propose a policy tailored to the observed traffic.
+3. Upon the application of a ClientIntent with a domain name present in the cache, the NetworkMapper dynamically updates the intent’s `status` section at one-second intervals with any newly identified IP addresses. It is important to note that Otterize retains all previously identified IP addresses to ensure backward compatibility.
+4. The IntentOperator reviews changes within the `status` section and amends the associated NetworkPolicy to include these newly discovered IP addresses.
+
+
+
+
+
+
+
+## Helm Chart options
 
 | Key                                     | Description                                                                                                                           | Default |
 |-----------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------|---------|
@@ -39,12 +53,12 @@ spec:
 
 View the [Helm chart reference](/reference/configuration/otterize-chart) for all other options
 
-### Network mapper parameters
+## Network mapper parameters
 All configurable parameters of the network mapper can be configured under the alias `networkMapper`.
 Further information about network mapper parameters can be found [in the network mapper's chart](https://github.com/otterize/helm-charts/tree/main/network-mapper).
 
 
-### CLI: Network mapper commands
+## CLI: Network mapper commands
 
 All `otterize network-mapper` commands share a set of optional flags which will not be repeated in the documentation
 for each command.

docs/features/network-mapping-network-policies/tutorials/k8s-egress-access-control-tutorial.mdx

@@ -14,12 +14,14 @@ In this tutorial, we will:
 - Deploy an example cluster consisting of an example frontend for a personal advice application and a server with an external dependency to retrieve wisdom.
 - Declare ClientIntents for each service, including public internet and internal network egress intents.
 - See that a network policy was autogenerated to allow just that and block the (undeclared) calls from the other client.
+- Revise our intent to use DNS records to tie our network policies to domain names.
 
 ## Prerequisites
 ### Install Otterize on your cluster
 To deploy Otterize, head over to [Otterize Cloud](https://app.otterize.com/), and to integrate your cluster, navigate to the [Integrations page](https://app.otterize.com/integrations) and follow the instructions, but be sure to add the flag below.
 
 **Note:**  Egress policy creation is off by default. We must add the following flag when installing Otterize to enable egress policy creation.
+
 ```bash
 --set intentsOperator.operator.enableEgressNetworkPolicyCreation=true
 ```
@@ -65,10 +67,10 @@ Stop procrastinating.
 The answer to all your problems is to:
 Don't feed Mogwais after midnight.
 ```
+
 View of our non-isolated cluster within Otterize Cloud
 <img className="tw-w-128 tw-mb-4" src="/img/quick-tutorials/egress-access-control/unprotected-network-egress-tutorial.png"/>
 
-
 ### Applying our intents
 
 Given that this is a serious advice application, we want to lock down our pods to ensure no outside inference can occur.
@@ -244,19 +246,71 @@ Spec:
 The protected network can be seen on Otterize Cloud:
 <img className="tw-w-128 tw-mb-4" src="/img/quick-tutorials/egress-access-control/cluster-intents-applied.png"/>
 
+### Using DNS and domain names in ClientIntents
 
+In the preceding example, a static IP address was employed for the definitions of our intents. Typically, in practical scenarios, a domain name precedes an external service rather than a static IP address. The inherent absence of a direct method to handle NetworkPolicies via domain names presents a considerable challenge in devising policy configurations for services characterized by dynamic IP addresses. However, the capability of ClientIntents to incorporate domain names, DNS records, and static IP addresses offers a flexible solution to this challenge. Below is an enhanced version of a ClientIntent that leverages a domain name.
 
-## Teardown
+```yaml
+{@include: ../../../../static/code-examples/egress-access-control/domain-intents.yaml}
+```
 
-To remove the deployed examples, run:
+In the above YAML file, we have replaced the IP address with our service’s domain name.
 
-```*bash*
-kubectl delete namespace otterize-tutorial-egress-access
+Otterize will now track the resolved IP addresses for `api.adviceslip.com` and add them to NetworkPolicies within your clusters. Let’s deploy the revised intent with the command below:
+
+```bash
+kubectl apply -n otterize-tutorial-egress-access -f ${ABSOLUTE_URL}/code-examples/egress-access-control/domain-intents.yaml
+```
+
+After the updated definition takes effect, with the command below we can view the policy again to find some additions.
+
+```bash
+kubectl describe clientintents -n otterize-tutorial-egress-access backend --show-events=false
 ```
+<details>
+<summary>View Updated ClientIntent Description</summary>
 
+```yaml
 
+Name:         backend
+Namespace:    otterize-tutorial-egress-access
+Labels:       none
+Annotations:  none
+API Version:  k8s.otterize.com/v1alpha3
+Kind:         ClientIntents
+Metadata:
+  Creation Timestamp:  2024-03-08T18:53:40Z
+  Finalizers:
+    intents.otterize.com/client-intents-finalizer
+  Generation:        2
+  Resource Version:  2122
+  UID:               c93d8cc4-2a8f-404e-b06c-1935176f1dc8
+Spec:
+  Calls:
+    Internet:
+      Domains:
+        api.adviceslip.com
+    Type:  internet
+    Name:  frontend
+  Service:
+    Name:  backend
+Status:
+  Observed Generation:  2
+  Resolved I Ps:
+    Dns:  api.adviceslip.com
+    Ips:
+      185.53.57.80
+  Up To Date:  true
+```
 
+</details>
 
+It is observed that Otterize identifies the IP addresses associated with the domain and incorporates them into a newly established section within the `status` block. This action informs the [Intent Operator](/reference/configuration/intents-operator) to dynamically adjust the network policies in response to the detection of new IP addresses originating from the specified domain name. For services that utilize dynamic IP addresses, each discovered IP address is systematically added to the network policy. Further details on DNS intents can be explored in the [Reference](/features/network-mapping-network-policies/reference#clientintents-with-dns).
 
+## Teardown
 
+To remove the deployed examples, run the following:
 
+```bash
+kubectl delete namespace otterize-tutorial-egress-access
+```

package.json

@@ -28,7 +28,7 @@
     "prism-react-renderer": "^1.3.5",
     "react": "^17.0.2",
     "react-dom": "^17.0.2",
-    "vercel": "^33.4.0"
+    "vercel": "^33.5.4"
   },
   "devDependencies": {
     "@docusaurus/module-type-aliases": "^2.4.3",

static/code-examples/egress-access-control/dns-enabled-npol.yaml

@@ -0,0 +1,22 @@
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-dns-access
+spec:
+  egress:
+    - ports:
+        - port: 53
+          protocol: UDP
+      to:
+        - namespaceSelector:
+            matchLabels:
+              kubernetes.io/metadata.name: kube-system
+          podSelector:
+            matchLabels:
+              k8s-app: kube-dns
+  podSelector:
+    matchExpressions:
+      - key: intents.otterize.com/service
+        operator: Exists
+  policyTypes:
+    - Egress

static/code-examples/egress-access-control/domain-intents.yaml

@@ -0,0 +1,26 @@
+apiVersion: k8s.otterize.com/v1alpha3
+kind: ClientIntents
+metadata:
+  name: frontend
+  namespace:  otterize-tutorial-egress-access
+spec:
+  service:
+    name: frontend
+  calls:
+    - name: backend
+---
+apiVersion: k8s.otterize.com/v1alpha3
+kind: ClientIntents
+metadata:
+  name: backend
+  namespace: otterize-tutorial-egress-access
+spec:
+  service:
+    name: backend
+  calls:
+    - type: internet
+      internet:
+        domains:
+          # Domain name for our advice service
+          - api.adviceslip.com
+    - name: frontend