+ Otterize makes it easy to create and visualize authorization for your Kubernetes clusters across a + variety of + services. Explore each below. +
+
-## What's next
+### What's next
The network mapper is a great way to bootstrap IBAC. It generates client intents files that reflect
the current topology of your services; those can then be used by each client team to grant them easy
@@ -125,7 +76,7 @@ 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).
-### Teardown
+## Teardown
To remove the deployed examples run:
diff --git a/docs/quickstart/access-control/k8s-network-policies.mdx b/docs/features/network-mapping-network-policies/tutorials/k8s-network-policies.mdx
similarity index 81%
rename from docs/quickstart/access-control/k8s-network-policies.mdx
rename to docs/features/network-mapping-network-policies/tutorials/k8s-network-policies.mdx
index 2117d5210..f76bbe470 100644
--- a/docs/quickstart/access-control/k8s-network-policies.mdx
+++ b/docs/features/network-mapping-network-policies/tutorials/k8s-network-policies.mdx
@@ -1,6 +1,6 @@
---
sidebar_position: 1
-title: NetworkPolicy automation
+title: NetworkPolicy Automation
image: /img/quick-tutorials/network-policies/social.png
---
@@ -23,45 +23,14 @@ In this tutorial, we will:
## Prerequisites
-
-## Choose one service to protect
+### Choose one service to protect
Now let's prepare to protect just one service, but remain in shadow mode: no actual network policies, yet. We'll verify no intended access would be blocked before turning on the network policy protection.
@@ -200,7 +174,7 @@ We see that:
-## Declare client intents
+### Declare client intents
The graph visually tells us we'll need to declare all 3 of those clients' intents:
1. `frontend` → `productcatalogservice`.
@@ -298,14 +272,14 @@ And you can verify the `productcatalogservice` would not block *any* of its disc
The server is still yellow because it's unprotected — let's fix that.
-## Protect the `productcatalogservice`
+### Protect the `productcatalogservice`
Now that we've verified no intended clients would be blocked, we can safely protect the server.
To do so, recall that we configured Otterize OSS to be in the `defaultShadow` mode: by default, it's in shadow mode for all services, not actually managing network policies for them. To protect a service is a simple matter of applying a `ProtectedService` YAML for it, overriding the default for it:
```yaml
-{@include: ../../static/code-examples/guides/protect-1-service-network-policies/protect-productcatalogservice.yaml}
+{@include: ../../../../static/code-examples/guides/protect-1-service-network-policies/protect-productcatalogservice.yaml}
```
Let's apply this file to our cluster:
@@ -326,22 +300,22 @@ Sure enough, the `productcatalogservice` is
-## Ready for production
+### Ready for production
-### Will load balancers, ingress, and other external traffic be affected?
+#### Will load balancers, ingress, and other external traffic be affected?
The intents operator automatically detects resources of kind `Service` (with type `LoadBalancer` or `NodePort`), or of kind `Ingress`, and creates network policies to allow external traffic to relevant pods.
You do not need to configure anything to get this to work. [Learn more here.](/reference/configuration/intents-operator#handling-external-traffic)
-### Will admission webhook controllers, e.g. policy validators like Kyverno, be affected?
+#### Will admission webhook controllers, e.g. policy validators like Kyverno, be affected?
Since you are not placing a global default-deny policy that would affect controllers in your cluster, only default-deny network policies on individual pods, Otterize will not affect calls to admission webhook controllers and they will continue functioning as before.
-### Working with Otterize in CI/CD
+#### Working with Otterize in CI/CD
We recommend placing the `ClientIntents` and `ProtectedService` resource YAMLs alongside the services that own them, in their respective Git repositories:
- The `ProtectedService` YAMLs alongside the servers they are protecting, e.g. in the Helm chart belonging to the server.
- `ClientIntents` YAMLs, whether they were generated from the network mapper or created and maintained by the client developer teams, alongside each client, e.g. in the Helm chart belonging to the client.
-## In summary
+### In summary
So what have we learned? You can gradually roll out IBAC and drive towards zero trust, service by service, in a safe, predictable, and quick way, by following 4 simple steps:
diff --git a/docs/features/postgresql/_category_.json b/docs/features/postgresql/_category_.json
new file mode 100644
index 000000000..94a4efd26
--- /dev/null
+++ b/docs/features/postgresql/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "PostgreSQL",
+ "position": 5,
+ "collapsed": true,
+ "customProps": {
+ "image": "/img/icons/postgresql-no-word-mark.svg"
+ }
+}
diff --git a/docs/features/postgresql/index.mdx b/docs/features/postgresql/index.mdx
new file mode 100644
index 000000000..38d87a00c
--- /dev/null
+++ b/docs/features/postgresql/index.mdx
@@ -0,0 +1,107 @@
+---
+sidebar_position: 1
+title: PostgreSQL | Overview
+hide_title: true
+---
+
+import DocsLinkCard from "@site/src/components/LinkCard";
+
+export const postgres_tutorials = [
+ {
+ title: 'Just-in-time PostgreSQL Access',
+ description: 'Learn how to manage just-in-time users and SQL GRANTs',
+ url: 'postgresql/tutorials/postgres'
+ },
+ {
+ title: 'Map PostgreSQL access',
+ description: 'Learn how to use PostgreSQL audit logs to map access to your database',
+ url: 'postgresql/tutorials/postgres-mapping'
+ }
+];
+
+# PostgreSQL
+
+Otterize is able to create just-in-time username-and-password pairs for your service, providing them as a Kubernetes Secret that can be mounted to file or mapped to environment variables, as well as `GRANT`ing access to databases and tables, based on `ClientIntents` ([Intents-Based Access Control](/overview/intent-based-access-control)) declarations.
+In addition, Otterize can map the access to your PostgreSQL database, showing you which service is accessing which database, table and which operation it's performing. This can be used to automatically generate the `ClientIntents` declarations.
+
+Unlike other access controls in Otterize, PostgreSQL support is exclusively available when using Otterize Cloud.
+
+### Tutorials
+
+To learn how to use the Intents Operator and Credentials Operator to enforce access using PostgreSQL GRANTs, or map access to your PostgreSQL database, try one of these quickstart tutorials.
+
+
+Otterize is a platform for automating workload IAM (access control) for workloads on Kubernetes.
+Each workload declares what it needs in order to function, and a Kubernetes operator figures out the policies that need to be created. This concept is called [Intent-Based Access Control (IBAC)](/overview/intent-based-access-control).
-### Otterize CLI
+For each kind of supported IAM mechanism (such as Kubernetes Network Policies, AWS IAM policies), Otterize can automatically learn the required ClientIntents.
-The [Otterize CLI](/reference/cli) is used to control the network mapper or output its data, convert non-Kubernetes client
-intents files (if needed) to Kubernetes custom resource YAMLs, interface with the Otterize Cloud.
+Otterize is composed of [three open-source and standalone components (the intents operator, credentials operator and network mapper)](/overview) you deploy on your cluster, as part of a single Helm chart, which handle enforcement, and Otterize Cloud, which supplements them with additional features.
-## Open source and Cloud
+Learn about how Otterize works by reading below, or jump into one of the tutorials below to see how it works hand-on.
+### Introduction
-### Otterize OSS
+