Merge remote-tracking branch 'origin/main' into amitlicht/azure_iam_t…

…utorial

.github/workflows/test-build.yml

@@ -19,4 +19,4 @@ jobs:
       - name: Install dependencies
         run: yarn install --frozen-lockfile
       - name: Test build website
-        run: yarn build
+        run: yarn validate

docs/faq/README.mdx

@@ -36,7 +36,7 @@ the labels which Otterize configured Kubernetes to put on the pod serve as a kin
 IBAC is short for intent-based access control, which is **a new paradigm** for configuring service-to-service access
 control based on the client service declaring what server calls (or operations) it intends to make.
 
-For more information, see the [IBAC documentation page](/intent-based-access-control).
+For more information, see the [IBAC documentation page](/overview/intent-based-access-control).
 
 </details>
 
@@ -87,7 +87,7 @@ to integrate with your infrastructure, e.g. for integrating with Kafka outside o
 
 Sure, in fact we recommend that you roll out IBAC gradually, to grow your and your organization's confidence in this approach.
 Change, even when positive, is not always easy to manage. Tools such as the network mapper let you bootstrap intents files to make
-adoption by teams that own specific services much easier. Read the various tutorials for [network policies](/quickstart/access-control/k8s-network-policies), [Kafka](/quickstart/access-control/k8s-kafka-mtls), [network mapping](/quickstart/visualization/k8s-network-mapper).
+adoption by teams that own specific services much easier. Read the various tutorials for [network policies](/features/network-mapping-network-policies/tutorials/k8s-network-policies), [Kafka](/features/kafka/tutorials/k8s-kafka-mtls), [network mapping](/features/network-mapping-network-policies/tutorials/k8s-network-mapper).
 to see how to roll out IBAC gradually for various use cases.
 
 </details>
@@ -98,7 +98,7 @@ to see how to roll out IBAC gradually for various use cases.
 
 Otterize's approach is to configure and use your existing infrastructure as much as possible, rather than replacing existing components, and help you achieve zero-trust through effective use of authentication and authorization across heterogeneous infrastructures and tech stacks. The drivers for authentication and authorization are client intents: metadata that's used to configure enforcement points.
 
-In contrast, service meshes aim to solve a whole slew of problems and tasks related to microservices, such as request routing and load balancing, circuit breaking, retries, rate limiting, blue/green deployment, service discovery, observability and metrics, as well as authentication and authorization. Otterize does not aim to do all of these things &mdash; only authentication and authorization. And even there, it does not aim to replace enforcement points for authN/authZ &mdash; it just configures them based on client intents and any overriding rules. So if a service mesh is used to enforce access, Otterize would configure it based on client intents (and any override rules) &mdash; as we do with [our support for Istio](/quickstart/access-control/k8s-istio-authorization-policies).
+In contrast, service meshes aim to solve a whole slew of problems and tasks related to microservices, such as request routing and load balancing, circuit breaking, retries, rate limiting, blue/green deployment, service discovery, observability and metrics, as well as authentication and authorization. Otterize does not aim to do all of these things &mdash; only authentication and authorization. And even there, it does not aim to replace enforcement points for authN/authZ &mdash; it just configures them based on client intents and any overriding rules. So if a service mesh is used to enforce access, Otterize would configure it based on client intents (and any override rules) &mdash; as we do with [our support for Istio](/features/istio/tutorials/k8s-istio-authorization-policies).
 
 Unlike Otterize, service meshes generally aim to be the a one-stop-shop for all your needs, replacing many of the technologies you currently use. For many, this actually turns out to be friction, especially if you just want to apply authorization, and don't wish to change various technologies that are already working for you.
 

docs/features/istio/tutorials/k8s-istio-authorization-policies.mdx

@@ -258,8 +258,8 @@ Try to create an intents file yourself for **client-other**, and apply it to all
 
 ### What's next
 
-- Get started with the [Otterize network mapper for Istio](/quickstart/visualization/k8s-istio-watcher) to help you bootstrap intents files with HTTP resources
-  for use in [intent-based access control (IBAC)](/intent-based-access-control).
+- Get started with the [Otterize network mapper for Istio](/features/istio/tutorials/k8s-istio-watcher) to help you bootstrap intents files with HTTP resources
+  for use in [intent-based access control (IBAC)](/overview/intent-based-access-control).
 
 ## Teardown
 

docs/features/istio/tutorials/k8s-istio-watcher.mdx

@@ -108,9 +108,9 @@ the intents files. We'll see more of that below.
 
 Where to go next?
 
-- Learn how to roll out [Istio authorization-policy-based access control](/quickstart/access-control/k8s-istio-authorization-policies) using intents.
-- If you haven't already, see the [automate network policies tutorial](/quickstart/access-control/k8s-network-policies).
-- Or go to the next tutorial to [automate secure access for Kafka](/quickstart/access-control/k8s-kafka-mtls).
+- Learn how to roll out [Istio authorization-policy-based access control](/features/istio/tutorials/k8s-istio-authorization-policies) using intents.
+- If you haven't already, see the [automate network policies tutorial](/features/network-mapping-network-policies/tutorials/k8s-network-policies).
+- Or go to the next tutorial to [automate secure access for Kafka](/features/kafka/tutorials/k8s-kafka-mtls).
 
 ## Teardown
 

docs/features/kafka/tutorials/k8s-kafka-mapping.mdx

@@ -110,7 +110,7 @@ You can consume this information in various ways:
 
 ### What's next
 
-- Try our [secure access for Kafka](/quickstart/access-control/k8s-kafka-mtls) tutorial
+- Try our [secure access for Kafka](/features/kafka/tutorials/k8s-kafka-mtls) tutorial
 
 ## Teardown
 

docs/features/kafka/tutorials/k8s-kafka-mtls-cert-manager.mdx

@@ -9,7 +9,7 @@ import TabItem from "@theme/TabItem";
 
 This tutorial will walk you through declaring and applying intents to easily secure access to Kafka running inside a Kubernetes cluster, automating the management of [Kafka ACLs](https://docs.confluent.io/platform/current/kafka/authorization.html), and the generation and deployment of certificates for mTLS between Kafka and its clients using cert-manager as the certificate provider.
 
-If you prefer to generate certificates using Otterize Cloud, try [the tutorial for Otterize Cloud](/quickstart/access-control/k8s-kafka-mtls).
+If you prefer to generate certificates using Otterize Cloud, try [the tutorial for Otterize Cloud](/features/kafka/tutorials/k8s-kafka-mtls).
 
 In this tutorial, we will:
 

docs/features/kafka/tutorials/k8s-kafka-mtls.mdx

@@ -9,7 +9,7 @@ import TabItem from "@theme/TabItem";
 
 This tutorial will walk you through declaring and applying intents to easily secure access to Kafka running inside a Kubernetes cluster, automating the management of [Kafka ACLs](https://docs.confluent.io/platform/current/kafka/authorization.html), and the generation and deployment of certificates for mTLS between Kafka and its clients using Otterize Cloud as the certificate provider.
 
-If you prefer to generate certificates using [`cert-manager`](https://cert-manager.io), try [the tutorial for cert-manager](/quickstart/access-control/k8s-kafka-mtls-cert-manager).
+If you prefer to generate certificates using [`cert-manager`](https://cert-manager.io), try [the tutorial for cert-manager](/features/kafka/tutorials/k8s-kafka-mtls-cert-manager).
 
 In this tutorial, we will:
 

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

@@ -120,7 +120,7 @@ Here's the image generated by running `otterize network-mapper visualize -n otte
 `otterize network-mapper export [--format] [-n <namespace1>,<namespace2>,...] [-o <path>] [--output-type <output-type>]`
 
 Return the network map built by the network mapper since it started, or since it was reset,
-as YAML [client intents file(s)](/reference/intents-and-intents-files/#intents-file-formats) or as JSON file(s).
+as YAML [client intents file(s)](/overview/intent-based-access-control) or as JSON file(s).
 
 #### Options
 

docs/features/network-mapping-network-policies/tutorials/aws-eks-cni-mini.mdx

@@ -156,7 +156,7 @@ And you should see your access graph showing the service as protected:
 
 ### What's next
 
-Have a look at the [guide on how to deploy protection to a larger, more complex application one step at a time](/guides/protect-1-service-network-policies).
+Have a look at the [guide on how to deploy protection to a larger, more complex application one step at a time](/features/network-mapping-network-policies/tutorials/protect-1-service-network-policies).
 
 ## Teardown
 

docs/features/network-mapping-network-policies/tutorials/k8s-network-mapper.mdx

@@ -73,8 +73,8 @@ the intents files. We'll see more of that below.
 
 Where to go next?
 
-- If you haven't already, see the [automate network policies tutorial](/quickstart/access-control/k8s-network-policies).
-- Or go to the next tutorial to [automate secure access for Kafka](/quickstart/access-control/k8s-kafka-mtls).
+- If you haven't already, see the [automate network policies tutorial](/features/network-mapping-network-policies/tutorials/k8s-network-policies).
+- Or go to the next tutorial to [automate secure access for Kafka](/features/kafka/tutorials/k8s-kafka-mtls).
 
 ## Teardown
 

docs/features/network-mapping-network-policies/tutorials/k8s-network-policies.mdx

@@ -175,7 +175,7 @@ kubectl apply -f ${ABSOLUTE_URL}/code-examples/automate-network-policies/intents
 ```
 
 :::tip
-Client intents are the cornerstone of [intent-based access control (IBAC)](/intent-based-access-control).
+Client intents are the cornerstone of [intent-based access control (IBAC)](/overview/intent-based-access-control).
 ::: 2. You should quickly see in the **[client-other]** terminal that it times out when calling the server,
 as expected since it didn't declare its intents:
 
@@ -265,7 +265,7 @@ Otterize saved us from doing all this work by simply declaring the client's inte
 while the appropriate network policies were managed automatically behind the scenes.
 
 Further information about network policies and Otterize can be found
-[here](/reference/access-controls/network-policies).
+[here](/features/network-mapping-network-policies/reference/Network-Policies-Deep-Dive).
 
 </details>
 
@@ -275,8 +275,8 @@ Try to create an intents file yourself for **client-other**, and apply it to all
 
 ### What's next
 
-- Get started with the [Otterize network mapper](/quickstart/visualization/k8s-network-mapper) to help you bootstrap intents files
-  for use in [intent-based access control (IBAC)](/intent-based-access-control).
+- Get started with the [Otterize network mapper](/features/network-mapping-network-policies/tutorials/k8s-network-mapper) to help you bootstrap intents files
+  for use in [intent-based access control (IBAC)](/overview/intent-based-access-control).
 
 ## Teardown
 

docs/overview/intent-based-access-control.mdx

@@ -19,7 +19,6 @@ In other words, developers declare what their service intends to access, and tha
 
 Here’s an example of a client intents file (as a Kubernetes custom resource YAML) for a service named **client** that has network access to another service named **auth-server** and has access to **production-db’s** **metrics** database:
 ```yaml
-
 apiVersion: k8s.otterize.com/v1alpha2
 kind: ClientIntents
 metadata:

docs/overview/otterize-cloud/README.mdx

@@ -2,15 +2,15 @@
 title: Otterize Cloud
 ---
 
-Otterize Cloud provides a cloud-based control plane for deploying and managing [intents-based access control (IBAC)](/intent-based-access-control).
+Otterize Cloud provides a cloud-based control plane for deploying and managing [intents-based access control (IBAC)](/overview/intent-based-access-control).
 
 It currently supports IBAC within Kubernetes clusters, configuring access between pods and access to Kafka nodes using network policies and Kafka ACLs.
 Soon, Otterize Cloud will also support IBAC across clusters and non-Kubernetes services and resources (e.g. standalone and managed Kafka, RDS, etc.).
 This page is focused on the current capabilities of Otterize Cloud.
 
 ## What it does
 
-Otterize Cloud attaches to [Otterize OSS](/otterize-oss) operators (the intents operator, network mapper, and credentials operator) running in your Kubernetes clusters.
+Otterize Cloud attaches to [Otterize OSS](/overview/otterize-oss) operators (the intents operator, network mapper, and credentials operator) running in your Kubernetes clusters.
 While Otterize OSS does the heavy lifting — mapping pod-to-pod traffic, responding to intents files applied with `kubectl` and
 configuring network policies, Kafka ACLs, and Istio authorization policies — Otterize Cloud adds:
 - **Visibility**: visualize the network map of any connected cluster.

docs/overview/otterize-oss/README.mdx

@@ -24,9 +24,9 @@ This list will grow over time, as more capabilities are added, in particular sup
 
 The Otterize OSS code base and issues are managed [on GitHub](https://github.com/otterize).
 
-To get started with Otterize OSS, see the tutorials for [network policies](/quickstart/access-control/k8s-network-policies), [Kafka](/quickstart/access-control/k8s-kafka-mtls), [network mapping](/quickstart/visualization/k8s-network-mapper), and [Istio service mesh](/quickstart/access-control/k8s-istio-authorization-policies).
+To get started with Otterize OSS, see the tutorials for [network policies](/features/network-mapping-network-policies/tutorials/k8s-network-policies), [Kafka](/features/kafka/tutorials/k8s-kafka-mtls), [network mapping](/features/network-mapping-network-policies/tutorials/k8s-network-mapper), and [Istio service mesh](/features/istio/tutorials/k8s-istio-authorization-policies).
 
 ## Usage metrics
 
-Components in Otterize OSS collect usage information — counts of events like `INTENTS_APPLIED`, `NETWORK_POLICY_CREATED`, `KAFKA_ACL_DELETED`, etc. — and can report those back to the Otterize team. This is entirely optional and does not affect the functionality of Otterize OSS, but it does help the team at Otterize understand what the community finds useful and hence how to improve it. (Of course, direct feedback through the [Otterize Community Slack](https://joinslack.otterize.com/) is very much appreciated too.) For more information, including what is sent and how to turn it off or on, see [the usage telemetry documentation](/otterize-oss/usage-telemetry).
+Components in Otterize OSS collect usage information — counts of events like `INTENTS_APPLIED`, `NETWORK_POLICY_CREATED`, `KAFKA_ACL_DELETED`, etc. — and can report those back to the Otterize team. This is entirely optional and does not affect the functionality of Otterize OSS, but it does help the team at Otterize understand what the community finds useful and hence how to improve it. (Of course, direct feedback through the [Otterize Community Slack](https://joinslack.otterize.com/) is very much appreciated too.) For more information, including what is sent and how to turn it off or on, see [the usage telemetry documentation](/overview/otterize-oss/usage-telemetry).
 

docs/reference/cli/README.mdx

@@ -5,7 +5,7 @@ title: CLI
 
 The Otterize command line interface (CLI) offers the following capabilities:
 - [Interact with](#network-mapper) the [Otterize network mapper](/features/network-mapping-network-policies/tutorials/k8s-network-mapper) running in a Kubernetes cluster.
-- [Transform](#otterize-intents-convert--f-path) [intents files](/reference/intents-and-intents-files/#intents-file-formats) from plain YAML format to Kubernetes custom resource YAML format.
+- [Transform](#otterize-intents-convert--f-path) [intents files](/overview/intent-based-access-control) from plain YAML format to Kubernetes custom resource YAML format.
 - Interact with the Otterize Cloud, through its REST API.
 
 This CLI is open-source software. To see its source or build it yourself,
@@ -141,7 +141,7 @@ Here's the image generated by running `otterize network-mapper visualize -n otte
 ### `otterize network-mapper export [--format] [-n <namespace1>,<namespace2>,...] [-o <path>] [--output-type <output-type>]`
 
 Return the network map built by the network mapper since it started, or since it was reset,
-as YAML [client intents file(s)](/reference/intents-and-intents-files/#intents-file-formats) or as JSON file(s).
+as YAML [client intents file(s)](/overview/intent-based-access-control) or as JSON file(s).
 
 #### Options