diff --git a/docs/features/postgresql/tutorials/postgres.mdx b/docs/features/postgresql/tutorials/postgres.mdx index 6054de5d5..ddf7e2bee 100644 --- a/docs/features/postgresql/tutorials/postgres.mdx +++ b/docs/features/postgresql/tutorials/postgres.mdx @@ -80,15 +80,7 @@ kubectl apply -n otterize-tutorial-postgres -f ${ABSOLUTE_URL}/code-examples/pos ### Deploy a PostgreSQLServerConfig to allow Otterize DB access ```yaml -apiVersion: k8s.otterize.com/v1alpha3 -kind: PostgreSQLServerConfig -metadata: - name: postgres-tutorial-db -spec: - address: database.otterize-tutorial-postgres.svc.cluster.local:5432 - credentials: - username: otterize-tutorial - password: jeffdog523 +{@include: ../../../../static/code-examples/postgres/postgresqlserverconfig.yaml} ``` The above CRD tells Otterize how to access a database instance named `postgres-tutorial-db`, meaning that when intents are applied requesting access permissions to `postgres-tutorial-db`, Otterize operators will be able to configure @@ -102,7 +94,7 @@ The type PostgreSQLServerConfig should be considered as sensitive and require hi Let's apply the above `PostgreSQLServerConfig` so Otterize will know how to access our database instance. ```shell -kubectl apply -f pgserverconf.yaml +kubectl apply -n otterize-tutorial-postgres -f ${ABSOLUTE_URL}/code-examples/postgres/postgresqlserverconfig.yaml ``` ### View logs for the server @@ -127,32 +119,18 @@ Below is our `intents.yaml` file. As you can see, it is scoped to our database n 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: postgres-tutorial-db # Same name as our PostgreSQLServerConfig metadata.name - type: database - databaseResources: - - databaseName: otterize-tutorial - table: public.example - operations: - - SELECT - - INSERT +{@include: ../../../../static/code-examples/postgres/clientintents.yaml} ``` We can now apply our intents. Behind the scenes,the Otterize credentials-operator created the user for our `server` workload while the intents-operator ran `GRANT` queries on the database, making our `SELECT` and `INSERT` errors disappear. ```shell -kubectl apply -f intents.yaml +kubectl apply -n otterize-tutorial-postgres -f ${ABSOLUTE_URL}/code-examples/postgres/clientintents.yaml ``` -Example log: +### View logs for the server +We can now view the server logs once again. This time, we should see that the server has the appropriate access to the database: + Successfully INSERTED into our table diff --git a/static/code-examples/postgres/clientintents.yaml b/static/code-examples/postgres/clientintents.yaml new file mode 100644 index 000000000..04f0671e5 --- /dev/null +++ b/static/code-examples/postgres/clientintents.yaml @@ -0,0 +1,17 @@ +apiVersion: k8s.otterize.com/v1alpha3 +kind: ClientIntents +metadata: + name: client-intents-for-server + namespace: otterize-tutorial-postgres +spec: + service: + name: server + calls: + - name: postgres-tutorial-db # Same name as our PostgreSQLServerConfig metadata.name + type: database + databaseResources: + - databaseName: otterize-tutorial + table: public.example + operations: + - SELECT + - INSERT \ No newline at end of file diff --git a/static/code-examples/postgres/postgresqlserverconfig.yaml b/static/code-examples/postgres/postgresqlserverconfig.yaml new file mode 100644 index 000000000..c5852b78a --- /dev/null +++ b/static/code-examples/postgres/postgresqlserverconfig.yaml @@ -0,0 +1,9 @@ +apiVersion: k8s.otterize.com/v1alpha3 +kind: PostgreSQLServerConfig +metadata: + name: postgres-tutorial-db +spec: + address: database.otterize-tutorial-postgres.svc.cluster.local:5432 + credentials: + username: otterize-tutorial + password: jeffdog523