Add TODOs and small changes

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

@@ -1,14 +1,14 @@
 ---
 sidebar_position: 5
-title: Egress Policy Automation
+title: Egress Network Policy Automation
 image: /img/quick-tutorials/egress-access-control/social.png
 ---
-Let’s learn how Otterize automates egress access control with network policies
+Let’s learn how Otterize automates egress access control with network policies.
 
 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 our network intents for each pod, including public internet and internal network egress rules.
+- 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.
 
 ## Prerequisites
@@ -45,38 +45,32 @@ We aim to secure the network in our example cluster by introducing a default den
 * Frontend - Needs to retrieve advice from our backend. This will result in an egress policy on our frontend and an ingress policy on our backend.
 * Backend - Needs to be able to accept our frontend request and communicate to an external API. This will create an ingress policy for our frontend and an egress policy for the external API.
 
-As previously mentioned, the pods will be non-isolated by default, and everything will work. Can you open up the logs on the frontend to see the free advice flowing:
+As previously mentioned, the pods will be non-isolated by default, and everything will work. Check the logs for the frontend service to see the free advice flowing:
 
 ```bash
 kubectl logs -f -n otterize-tutorial-egress-access deploy/frontend
 ```
 
+:::danger
+TODO Please add an example output here, and a screenshot of the resulting network map.
+:::
+
 ### 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.
 
 To enforce the strict communication rules for our services, we will start by applying a default deny policy, ensuring that only explicitly defined connections are allowed.  You’ll see that we are allowing UDP on port 53 to support any DNS lookups we need.
+:::danger
+TODO Please explain why it's important to allow DNS lookups (what would happen if we didn't).
+:::
 
 ```bash
 kubectl apply -n otterize-tutorial-egress-access -f ${ABSOLUTE_URL}/code-examples/egress-access-control/default-deny-policy.yaml
 ```
 
 *Default Deny Policy*
 ```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: default-deny-ingress
-spec:
-  podSelector: {}
-  policyTypes:
-  - Egress
-  - Ingress
-  egress:
-      - ports:
-        - protocol: UDP
-          port: 53
-
+{@include: ../../../../static/code-examples/egress-access-control/default-deny-policy.yaml}
 ```
 
 
@@ -92,36 +86,19 @@ Now that we have secured our broader network, we will apply the following Client
 kubectl apply -n otterize-tutorial-egress-access -f ${ABSOLUTE_URL}/code-examples/egress-access-control/intents.yaml
 ```
 
+:::danger
+TODO Please note the use of @include here to make sure the yaml showing below and the link lead to the same file.
+:::
 ```yaml
-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:
-        ips:
-          - 185.53.57.80 # IP address of our external API
-    - name: frontend
+{@include: ../../../../static/code-examples/egress-access-control/intents.yaml}
 ```
 
 Now, our network and our services are only able to open connections to those internal and external resources that are explicitly needed.
 
+:::danger
+TODO Please show the resulting network policies here, and explain how they work (e.g. why the rules that are there result in traffic being allowed).
+:::
+
 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"/>
 

static/code-examples/egress-access-control/default-deny-policy.yaml

@@ -2,7 +2,7 @@
 apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
-  name: default-deny-ingress
+  name: default-deny
 spec:
   podSelector: {}
   policyTypes: