Fix broken link validation

.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

@@ -259,7 +259,7 @@ 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).
+  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/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:
 
@@ -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/otterize-cloud/README.mdx

@@ -2,7 +2,7 @@
 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.).

docs/overview/otterize-oss/README.mdx

@@ -24,7 +24,7 @@ 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
 

docs/reference/configuration/intents-operator/README.mdx

@@ -4,7 +4,7 @@ title: Intents operator
 ---
 
 The Otterize intents operator is an open source Kubernetes operator for easily managing service-to-service authorization
-by declaring the calls each service needs to make, using [client intents files](/intent-based-access-control).
+by declaring the calls each service needs to make, using [client intents files](/overview/intent-based-access-control).
 The intents operator uses these files to configure network policies, Kafka ACLs, and other enforcement points (in the future) to allow just the intended calls.
 
 If credentials such as X.509 certificates are needed for authentication — for example,
@@ -22,7 +22,7 @@ To deploy the operator, [use the Helm chart](/reference/configuration/intents-op
 The intents operator pod exposes a Prometheus metrics endpoint on port 2112, on `/metrics`.
 
 ## Controlling access using the intents operator
-To learn how to use the intents operator to control access, consult the guides for [managing network policies using intents](/quickstart/access-control/k8s-network-policies), [Kafka ACLs using intents](/quickstart/access-control/k8s-kafka-mtls) and [Istio AuthorizationPolicy using intents](/quickstart/access-control/k8s-istio-authorization-policies).
+To learn how to use the intents operator to control access, consult the guides for [managing network policies using intents](/features/network-mapping-network-policies/tutorials/k8s-network-policies), [Kafka ACLs using intents](/features/kafka/tutorials/k8s-kafka-mtls) and [Istio AuthorizationPolicy using intents](/features/istio/tutorials/k8s-istio-authorization-policies).
 
 ## Pod annotations
 

docs/reference/configuration/network-mapper/README.mdx

@@ -6,9 +6,9 @@ title: Network mapper
 The Otterize network mapper creates a map of in-cluster traffic by (1) capturing DNS traffic and (2) inspecting active connections in the same manner `netstat` does, then resolving the IP addresses participating in connections to the Pods, and crawling up the ownership of the Pod until it reaches the root object. See [Service identities](/reference/service-identities) to learn more on how service name resolving happens. The network mapper continues building the network map as long as it's deployed.
 
 You can then use the Otterize CLI to list the traffic by client, reset the traffic the mapper remembers, or export it as JSON or YAML, which serves as ClientIntents Kubernetes resources). ClientIntents can be consumed by the [Otterize intents operator](/reference/configuration/intents-operator) to apply network policies
-or Kafka ACLs to your cluster, implementing [intent-based access control](/intent-based-access-control).
+or Kafka ACLs to your cluster, implementing [intent-based access control](/overview/intent-based-access-control).
 
-To get started, follow the [quick hands-on tutorial](/quickstart/visualization/k8s-network-mapper).
+To get started, follow the [quick hands-on tutorial](/features/network-mapping-network-policies/tutorials/k8s-network-mapper).
 
 The network mapper also supports exporting Grafana Tempo-style metrics, contributed by the community. See the [Helm chart documentation's OpenTelemetry section](/reference/configuration/network-mapper/helm-chart#opentelemetry-exporter-parameters) to learn how to enable this feature.
 

docs/reference/configuration/network-mapper/helm-chart.mdx

@@ -7,7 +7,7 @@ To deploy the network mapper, do the following:
 {@include: ../../../_common/install-otterize-network-mapper.md}
 
 :::tip
-Checkout the network mapper [tutorial](/quickstart/visualization/k8s-network-mapper) to see it in action.
+Checkout the network mapper [tutorial](/features/network-mapping-network-policies/tutorials/k8s-network-mapper) to see it in action.
 :::
 
 # Parameters

docs/reference/mtls/README.mdx

@@ -204,5 +204,5 @@ The certificate belongs to a chain of trust rooted at the SPIRE server.
 
 ## What's next
 
-- Configure secure access between pods and Kafka running within the same Kubernetes cluster with this [guide](/quickstart/access-control/k8s-kafka-mtls).
+- Configure secure access between pods and Kafka running within the same Kubernetes cluster with this [guide](/features/kafka/tutorials/k8s-kafka-mtls).
 - Read more about the [Otterize credentials operator](/reference/configuration/credentials-operator/)