diff --git a/docs/features/istio/tutorials/k8s-istio-authorization-policies.mdx b/docs/features/istio/tutorials/k8s-istio-authorization-policies.mdx index 15f1ea995..fb5dd90cf 100644 --- a/docs/features/istio/tutorials/k8s-istio-authorization-policies.mdx +++ b/docs/features/istio/tutorials/k8s-istio-authorization-policies.mdx @@ -258,7 +258,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 +- 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 diff --git a/docs/features/network-mapping-network-policies/reference/README.mdx b/docs/features/network-mapping-network-policies/reference/README.mdx index b81897009..18e9d5962 100644 --- a/docs/features/network-mapping-network-policies/reference/README.mdx +++ b/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 ,,...] [-o ] [--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 diff --git a/docs/features/network-mapping-network-policies/tutorials/aws-eks-cni-mini.mdx b/docs/features/network-mapping-network-policies/tutorials/aws-eks-cni-mini.mdx index e0858c5b8..ec3fc6a69 100644 --- a/docs/features/network-mapping-network-policies/tutorials/aws-eks-cni-mini.mdx +++ b/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 diff --git a/docs/features/network-mapping-network-policies/tutorials/k8s-network-policies.mdx b/docs/features/network-mapping-network-policies/tutorials/k8s-network-policies.mdx index 44676c294..c64833ee7 100644 --- a/docs/features/network-mapping-network-policies/tutorials/k8s-network-policies.mdx +++ b/docs/features/network-mapping-network-policies/tutorials/k8s-network-policies.mdx @@ -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). diff --git a/docs/overview/intent-based-access-control.mdx b/docs/overview/intent-based-access-control.mdx index 2bbdf41fc..e6a203c6f 100644 --- a/docs/overview/intent-based-access-control.mdx +++ b/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: diff --git a/docs/overview/otterize-cloud/README.mdx b/docs/overview/otterize-cloud/README.mdx index 6d94d3eb7..059c50cc9 100644 --- a/docs/overview/otterize-cloud/README.mdx +++ b/docs/overview/otterize-cloud/README.mdx @@ -10,7 +10,7 @@ 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. diff --git a/docs/overview/otterize-oss/README.mdx b/docs/overview/otterize-oss/README.mdx index ffbb9b654..3aceb68a4 100644 --- a/docs/overview/otterize-oss/README.mdx +++ b/docs/overview/otterize-oss/README.mdx @@ -28,5 +28,5 @@ To get started with Otterize OSS, see the tutorials for [network policies](/feat ## 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). diff --git a/docs/reference/cli/README.mdx b/docs/reference/cli/README.mdx index 2a4cc425a..0d1750666 100644 --- a/docs/reference/cli/README.mdx +++ b/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 ,,...] [-o ] [--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 diff --git a/docs/reference/configuration/intents-operator/README.mdx b/docs/reference/configuration/intents-operator/README.mdx index 9df828c7f..d39ae8fb9 100644 --- a/docs/reference/configuration/intents-operator/README.mdx +++ b/docs/reference/configuration/intents-operator/README.mdx @@ -38,7 +38,7 @@ You can override the service name the intents operator uses when it computes net ### Network policies The intents operator automatically creates, updates and deletes network policies, and automatically labels client and server pods, to reflect precisely the client-to-server calls declared in client intents files. -The intents operator can also be configured to process client intents *without* creating and managing network policies, to provide visibility on what would happen once enforcement via network policies is activated. More information can be found in the [shadow vs active enforcement documentation](/shadow-vs-active-enforcement). +The intents operator can also be configured to process client intents *without* creating and managing network policies, to provide visibility on what would happen once enforcement via network policies is activated. More information can be found in the [shadow vs active enforcement documentation](/reference/shadow-vs-active-enforcement). In the example above, the `checkoutservice` intends to call the `shippingservice`. When the CRD is applied through `kubectl apply`, the intents operator labels the `checkoutservice` and `shippingservice` pods, and creates a network policy for the ingress of the `shippingservice` that references these labels and allows calls to the `shippingservice` from the `checkoutservice`. @@ -50,7 +50,7 @@ label, `intents.otterize.com/access-server--`, is appl to access the server. This label is used as the selector to determine which client pods are allowed to access the server pod. -Learn more: [Network policies deep dive](/reference/access-controls/network-policies) +Learn more: [Network policies deep dive](/features/network-mapping-network-policies/reference/Network-Policies-Deep-Dive) #### Handling external traffic The intents operator has automatic behavior for allowing external traffic for pods which have indicated that they are supposed to accept external traffic, such as by creating a `Service` of type `NodePort` or `LoadBalancer`, or an `Ingress` resource. @@ -65,7 +65,7 @@ This behavior can be disabled using the Helm chart's values. ### Kafka mTLS & ACLs The intents operator automatically creates, updates, and deletes ACLs in Kafka clusters running within your Kubernetes cluster according to the declared intents. It does not modify other ACLs. It works together with the [Otterize credentials operator](/reference/configuration/credentials-operator) to easily enable secure access to Kafka from client pods, all in your Kubernetes cluster. -The intents operator can also be configured to process client intents *without* creating and managing Kafka ACLs, to provide visibility on what would happen once enforcement via Kafka ACLs is activated. More information can be found in the [shadow vs active enforcement documentation](/shadow-vs-active-enforcement). +The intents operator can also be configured to process client intents *without* creating and managing Kafka ACLs, to provide visibility on what would happen once enforcement via Kafka ACLs is activated. More information can be found in the [shadow vs active enforcement documentation](/reference/shadow-vs-active-enforcement). The Otterize credentials operator automatically registers client pods with the credentials service — either a SPIRE server, or the Otterize Cloud-managed credentials service — and writes the trusted credentials generated by that service into Kubernetes secrets for use by those pods. The intents operator takes `ClientIntents` with `type: kafka` and creates Kafka ACLs that grant the requested access to the cryptographic identities (SVIDs) created by the credentials operator. @@ -83,7 +83,7 @@ Try the [Just-in-time PostgreSQL users & access](/features/postgresql/tutorials/ ### Istio AuthorizationPolicy The intents operator automatically creates, updates and deletes Istio authorization policies, automatically looks up service accounts for client pods and labels server pods, to reflect precisely the client-to-server calls declared in client intents files. -The intents operator can also be configured to process client intents *without* creating and managing Istio authorization policies, to provide visibility on what would happen once enforcement via Istio authorization policy is activated. More information can be found in the [shadow vs active enforcement documentation](/shadow-vs-active-enforcement). +The intents operator can also be configured to process client intents *without* creating and managing Istio authorization policies, to provide visibility on what would happen once enforcement via Istio authorization policy is activated. More information can be found in the [shadow vs active enforcement documentation](/reference/shadow-vs-active-enforcement). In the example above, the `checkoutservice` intends to call the `shippingservice`. When the CRD is applied through `kubectl apply`, the intents operator labels the `shippingservice` pod, looks up `checkoutservice`'s service account, and creates an authorization policy for the ingress of the `shippingservice` that references the service account and allows calls to the `shippingservice` from the `checkoutservice`. diff --git a/docs/reference/shadow-vs-active-enforcement/README.mdx b/docs/reference/shadow-vs-active-enforcement/README.mdx index 0074255f1..879bca7c5 100644 --- a/docs/reference/shadow-vs-active-enforcement/README.mdx +++ b/docs/reference/shadow-vs-active-enforcement/README.mdx @@ -113,6 +113,6 @@ This will place a default-deny network policy on the server, and at the same tim ![Otterize Cloud - access graph - checkout service protected](/img/shadow-vs-active-enforcement/access-graph-protected-checkoutservice.png) -You can read more about the access graph in the [Otterize Cloud](/otterize-cloud) documentation. +You can read more about the access graph in the [Otterize Cloud](/overview/otterize-cloud) documentation. -And for a quick guide that shows how to use shadow enforcement to roll out IBAC gradually and controllably, see [Protecting one service with network policies](/guides/protect-1-service-network-policies). +And for a quick guide that shows how to use shadow enforcement to roll out IBAC gradually and controllably, see [Protecting one service with network policies](/features/network-mapping-network-policies/tutorials/protect-1-service-network-policies). diff --git a/docs/reference/terminology/README.mdx b/docs/reference/terminology/README.mdx index 1178da535..a4910ce20 100644 --- a/docs/reference/terminology/README.mdx +++ b/docs/reference/terminology/README.mdx @@ -15,7 +15,7 @@ An Otterize service is the logical "atom" of service-to-service authentication a The [Otterize CLI](/reference/cli) is a command-line utility used to control and interact with the Otterize network mapper, manipulate local Intents files, and (coming soon!) interact with Otterize Cloud. ### Intent (or client intent) -Otterize intents are a way to declare that one service intends to call another service. Otterize uses them to apply authorization rules to enable the calls to go through, and block any unintended calls. An *intent* refers to a client declaring a particular call to a server; *all* a given client's intents to the servers it intends to call are collected in a single *client intents file*. [Learn more about intents](/reference/intents-and-intents-files). +Otterize intents are a way to declare that one service intends to call another service. Otterize uses them to apply authorization rules to enable the calls to go through, and block any unintended calls. An *intent* refers to a client declaring a particular call to a server; *all* a given client's intents to the servers it intends to call are collected in a single *client intents file*. [Learn more about intents](/overview/intent-based-access-control). ### Integrations Otterize Cloud supports two types of integrations: Kubernetes integrations and generic integrations. Kubernetes integrations connect a Kubernetes cluster to Otterize Cloud, allowing communication with the Otterize operators. Generic integrations connect external systems to Otterize Cloud, providing API/CLI access credentials. These integrations are named based on their usage and must have unique names within an organization. @@ -55,7 +55,7 @@ to Kafka resources such as topics. ## Kubernetes ### Custom resource -A Kubernetes custom resource refers to a resource that is not present in the base distribution of Kubernetes (such as Deployment or Pod), but comes with an installed operator. The [Otterize ClientIntents](/reference/intents-and-intents-files/) are one such resource. [Read more about Kubernetes custom resources here](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). +A Kubernetes custom resource refers to a resource that is not present in the base distribution of Kubernetes (such as Deployment or Pod), but comes with an installed operator. The [Otterize ClientIntents](/overview/intent-based-access-control) are one such resource. [Read more about Kubernetes custom resources here](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). ### CNI (Container Network Interface) CNI is a CNCF project that provides libraries for implementing plugins for configuring network interfaces in Linux containers, and is used by Kubernetes to provide pods running in a cluster with network connectivity.