From dd6daec3e99a1c9647303e27970b83c72db9c86d Mon Sep 17 00:00:00 2001 From: Ori Shoshan Date: Wed, 21 Feb 2024 23:09:03 +0100 Subject: [PATCH] Add TODOs and small changes --- .../k8s-egress-access-control-tutorial.mdx | 63 ++++++------------- .../default-deny-policy.yaml | 2 +- 2 files changed, 21 insertions(+), 44 deletions(-) diff --git a/docs/features/network-mapping-network-policies/tutorials/k8s-egress-access-control-tutorial.mdx b/docs/features/network-mapping-network-policies/tutorials/k8s-egress-access-control-tutorial.mdx index de9ffb06a..b0f8e1b3a 100644 --- a/docs/features/network-mapping-network-policies/tutorials/k8s-egress-access-control-tutorial.mdx +++ b/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,17 +45,24 @@ 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 @@ -63,20 +70,7 @@ kubectl apply -n otterize-tutorial-egress-access -f ${ABSOLUTE_URL}/code-example *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: diff --git a/static/code-examples/egress-access-control/default-deny-policy.yaml b/static/code-examples/egress-access-control/default-deny-policy.yaml index a75e315a9..a24890287 100644 --- a/static/code-examples/egress-access-control/default-deny-policy.yaml +++ b/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: