Skip to content

Commit

Permalink
Merge branch 'main' of ssh://github.com/otterize/docs
Browse files Browse the repository at this point in the history
  • Loading branch information
orishoshan committed Feb 4, 2024
2 parents 9c23b91 + ac4a1ac commit 0022081
Show file tree
Hide file tree
Showing 17 changed files with 589 additions and 82 deletions.
8 changes: 4 additions & 4 deletions docs/_common/install-otterize-cli.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,15 +13,15 @@ brew install otterize/otterize/otterize-cli
<TabItem value="Apple Silicon" label="Apple Silicon">

```bash
curl -LJO https://get.otterize.com/otterize-cli/v1.0.2/otterize_macOS_arm64_notarized.zip
curl -LJO https://get.otterize.com/otterize-cli/v1.0.3/otterize_macOS_arm64_notarized.zip
tar xf otterize_macOS_arm64_notarized.zip
sudo cp otterize /usr/local/bin # optionally move to PATH
```
</TabItem>
<TabItem value="Intel 64-bit" label="Intel 64-bit">

```bash
curl -LJO https://get.otterize.com/otterize-cli/v1.0.2/otterize_macOS_x86_64_notarized.zip
curl -LJO https://get.otterize.com/otterize-cli/v1.0.3/otterize_macOS_x86_64_notarized.zip
tar xf otterize_macOS_x86_64_notarized.zip
sudo cp otterize /usr/local/bin # optionally move to PATH
```
Expand All @@ -42,7 +42,7 @@ scoop install otterize-cli
<TabItem value="64-bit" label="64-bit">

```PowerShell
Invoke-WebRequest -Uri https://get.otterize.com/otterize-cli/v1.0.2/otterize_windows_x86_64.zip -OutFile otterize_Windows_x86_64.zip
Invoke-WebRequest -Uri https://get.otterize.com/otterize-cli/v1.0.3/otterize_windows_x86_64.zip -OutFile otterize_Windows_x86_64.zip
Expand-Archive otterize_Windows_x86_64.zip -DestinationPath .
# optionally move to PATH
```
Expand All @@ -54,7 +54,7 @@ Expand-Archive otterize_Windows_x86_64.zip -DestinationPath .
<TabItem value="64-bit" label="64-bit">

```bash
wget https://get.otterize.com/otterize-cli/v1.0.2/otterize_linux_x86_64.tar.gz
wget https://get.otterize.com/otterize-cli/v1.0.3/otterize_linux_x86_64.tar.gz
tar xf otterize_linux_x86_64.tar.gz
sudo cp otterize /usr/local/bin # optionally move to PATH
```
Expand Down
5 changes: 3 additions & 2 deletions docs/quickstart/access-control/aws-iam-eks.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -95,8 +95,9 @@ To deploy Otterize, head over to [Otterize Cloud](https://app.otterize.com) and:

If you are using the cluster from the previous step, the cluster name is `otterize-iam-eks-tutorial` and the region is `us-west-2`.

Once the AWS integration is configured, you'll be presented with a dialog to launch a CloudFormation template to configure the IAM roles for the Otterize operators. This enables the operators to manage IAM for the pods in your cluster.
This setup is required once per-cluster, and configures AWS IRSA on your cluster, if it is not yet configured. [This template can be found on GitHub as well](https://github.com/otterize/setup/blob/main/aws-iam-operator-setup-template.yaml).
Once the AWS integration is configured, you'll be presented with a dialog to launch a CloudFormation template to configure the IAM roles for the Otterize operators.
This enables the operators to manage IAM for the pods in your cluster, and configures AWS IRSA on your cluster, if it is not yet configured.
This setup is required once per-cluster. [This template can be found on GitHub as well](https://github.com/otterize/setup/blob/main/aws-iam-operator-setup-template.yaml).

After CloudFormation has configured your cluster, click Next and you'll be presented with the configuration for deploying Otterize. Since you now have the AWS integration enabled, you need to redeploy Otterize with the credentials operator enabled, and with configuration telling the operators which AWS roles they will AssumeRole to in order to operate.

Expand Down
176 changes: 176 additions & 0 deletions docs/quickstart/access-control/postgres.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,176 @@
---
sidebar_position: 2
title: Just-in-time PostgreSQL access
image: /img/quick-tutorials/postgres/social.png
---

import CodeBlock from "@theme/CodeBlock";
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";

export const Terminal = ({children}) => (
<div
style={{
backgroundColor: '#eee',
borderRadius: '5px',
fontSize: '12px',
fontWeight: '600',
color: 'darkgreen',
padding: '1rem',
fontFamily: 'monospace, monospace'
}}>
{children}
</div>
);


# Overview
This tutorial will deploy an example cluster to highlight Otterize's PostgreSQL capabilities. Within that cluster is a client service that hits an endpoint on a server, which then connects to a database. The server runs two different database operations:
1. An `INSERT` operation to append a table within the database
2. A `SELECT` operation to validate the updates.

The server needs appropriate permissions to access the database. You could use one admin user for all services, which is insecure and is the cause for many security breaches. With Otterize, you can specify required access, and have Otterize create users and perform correctly scoped SQL GRANTs just in time, as the service spins up and down.

In this tutorial, we will:
* Deploy an example cluster
* Make our database accessible to Otterize Cloud
* Connect our cluster and database to Otterize Cloud
* Declare a ClientIntents resource for the server, specifying required access
* See that the required access has been granted

# Prerequisites

#### 1. Minikube Cluster
<details>
<summary>Prepare a Kubernetes cluster with Minikube</summary>

For this tutorial you'll need a local Kubernetes cluster. Having a cluster with a [CNI](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports [NetworkPolicies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) isn't required for this tutorial, but is recommended so that your cluster works with other tutorials.

If you don't have the Minikube CLI, first [install it](https://minikube.sigs.k8s.io/docs/start/).

Then start your Minikube cluster with Calico, in order to enforce network policies.

```shell
minikube start --cpus=4 --memory 4096 --disk-size 32g --cni=calico
```

</details>


#### 2. ngrok
We will be using it to create a proxy to connect our locally running database to Otterize Cloud, for the tutorial's purposes. Once you have a [ngrok account](https://dashboard.ngrok.com/signup), you’ll want to install it in your terminal using the instructions found here: [ngrok install](https://ngrok.com/download)

# Tutorial

### Deploy the cluster

This will set up the namespace we will use for our tutorial and deploy the cluster with our client, server, and database.

``` shell
kubectl create namespace otterize-tutorial-postgres
kubectl apply -n otterize-tutorial-postgres -f ${ABSOLUTE_URL}/code-examples/postgres/client-server-database.yaml
```

### Make the database accessible to Otterize Cloud

We need to allow Otterize Cloud to access the database server so Otterize Cloud can configure on-demand credentials for our server’s access. This tutorial will expose our database port to our local environment and then proxy it to Otterize Cloud using ngrok. We will need both of these processes up and running during the rest of this tutorial.

In a new terminal window, run the following command to forward our database port from our cluster into your local environment:
```shell
kubectl port-forward svc/database 5432:5432 -n otterize-tutorial-postgres
```

Now that your database port is accessible to your local environment, we are using ngrok to make that available to Otterize Cloud. For production uses, this can be done through firewall configurations.

In a new terminal window, run:
```shell
ngrok tcp 5432
```

Once ngrok is running, make note of the *Forwarding* host and port. Will need this for our next step.

### Integrate the database to Otterize Cloud

To add the database, we head over to the [Integrations page](https://app.otterize.com/integrations)

1. Click *Add Integration*
2. Select Integration Type: *Database*
3. Provide a name for the integration: *otterize-tutorial-postgres*
4. Leave the database type set to *PostgreSQL*
5. Copy your *Forwarding* host and port from ngrok in the *Address* Field. This will look something like `0.tcp.us-cal-1.ngrok.io:14192`. Be sure to remove the `tcp://` portion of the URL.
6. *Username*: otterize-tutorial, *Password*: jeffdog523
1. Note this is a superuser, which allows Otterize to create unique credentials for each service. For production, it is recommended to create a privileged user for Otterize’s exclusive use. This user should have the necessary permissions to GRANT access to any databases and tables you want it to manage.
7. Hit *Test Connection*, and you should see an “OK” status.
8. Hit the Add button to complete the integration

### Integrate the cluster to Otterize Cloud
Create a Kubernetes cluster on the [Clusters page](https://app.otterize.com/clusters), and follow the instructions.

After providing a cluster name and environment. For this tutorial, choose:

1. mTLS and Kafka Support: None
2. Enforcement mode: Enabled.
3. Copy and run the Helm upgrade command.
4. You should see the Connection status change.

### View logs for the server
After the client, server, and database are up and running, we can see that the server does not have the appropriate access to the database by inspecting the logs with the following command.

```shell
kubectl logs -f -n otterize-tutorial-postgres deploy/server
```


Example log:
<Terminal>
pq: password authentication failed for user "svc_9cigb2qemv_otterize_tutorial_postgres_server"
</Terminal>

### Define your ClientIntents

ClientIntents are Otterize’s way of defining access through unique relationships, which lead to perfectly scoped access. In this example, we provide our `server` service the ability to insert select records to allow it to access the database.

Below is our `intents.yaml` file. As you can see, it is scoped to our database named `otterize-tutorial` and our `public.example` table. We also have limited the access to just `SELECT` and `INSERT` operations. We could add more databases, tables, or operations if our service required more access.

Specifying the table and operations is optional. If you don't specify the table, access will be granted to all tables in the specified database. If you don't specify the operations, all operations will be allowed.
```yaml
apiVersion: k8s.otterize.com/v1alpha3
kind: ClientIntents
metadata:
name: client-intents-for-server
namespace: otterize-tutorial-postgres
spec:
service:
name: server
calls:
- name: otterize-tutorial-postgres # Same name as our integration
type: database
databaseResources:
- databaseName: otterize-tutorial
table: public.example
operations:
- SELECT
- INSERT
```
We can now apply our intents. Behind the scenes, Otterize Cloud runs `CREATE USER` and `GRANT` queries on the database, making our `SELECT` and `INSERT` errors disappear.

```shell
kubectl apply -f intents.yaml
```

Example log:
<Terminal>
Successfully INSERTED into our table
Successfully SELECTED, most recent value: 2024-01-22T18:48:43Z
</Terminal>

That’s it! If your service’s functionality changes, adding or removing access is as simple as updating your ClientIntents definitions. For fun, try altering the `operations` to just `SELECT` or `INSERT`.

# Teardown
To remove the deployed examples, run:
```shell
kubectl delete namespace otterize-tutorial-postgres
```

End the ngrok and port forwarding processes by closing the terminal windows or Ctrl-C the processes.
75 changes: 0 additions & 75 deletions docs/quickstart/access-control/postgresql.mdx

This file was deleted.

Loading

0 comments on commit 0022081

Please sign in to comment.