AWS prescriptive-guidance documentation change
Summary
Updated navigation link, added comma emphasis, removed backticks from runtime variable reference, fixed apostrophe formatting, and adjusted GitHub link phrasing
Security assessment
Changes are editorial improvements without modifying security content. Row-level security (RLS) documentation remains unchanged in substance; no new vulnerabilities or security features were addressed.
Diff
diff --git a/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/rls.md b/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/rls.md index 3cd8d0b7f..483d96add 100644 --- a//prescriptive-guidance/latest/saas-multitenant-managed-postgresql/rls.md +++ b//prescriptive-guidance/latest/saas-multitenant-managed-postgresql/rls.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Implementing managed PostgreSQL for multi-tenant SaaS applications on AWS](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Implementing managed PostgreSQL for multi-tenant SaaS applications on AWS](introduction.html) @@ -18 +18 @@ Row-level security (RLS) is required to maintain tenant data isolation in a pool -The second option is preferred, because the first option requires the creation of a new PostgreSQL user for each tenant. Instead, a SaaS application that uses PostgreSQL should be responsible for setting a tenant-specific context at runtime when it queries PostgreSQL. This will have the effect of enforcing RLS. You can also enable RLS on a table-by-table basis. As a best practice, you should enable RLS on all tables that contain tenant data. +The second option is preferred _,_ because the first option requires the creation of a new PostgreSQL user for each tenant. Instead, a SaaS application that uses PostgreSQL should be responsible for setting a tenant-specific context at runtime when it queries PostgreSQL. This will have the effect of enforcing RLS. You can also enable RLS on a table-by-table basis. As a best practice, you should enable RLS on all tables that contain tenant data. @@ -20 +20 @@ The second option is preferred, because the first option requires the creation o -The following example creates two tables and enables RLS. This example compares a column of data to the value of the runtime variable `app.current_tenant`. +The following example creates two tables and enables RLS. This example compares a column of data to the value of the runtime variable app.current_tenant. @@ -23 +23 @@ The following example creates two tables and enables RLS. This example compares - -- Create a table for our tenants with indexes on the primary key and the tenant’s name + -- Create a table for our tenants with indexes on the primary key and the tenant's name @@ -55,2 +55 @@ The following example creates two tables and enables RLS. This example compares - -For more information, see the blog post [Multi-tenant data isolation with PostgreSQL Row Level Security](https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/). The AWS SaaS Factory team also has [some examples in GitHub](https://github.com/aws-samples/aws-saas-factory-postgresql-rls) to assist in implementing RLS. +For more information, see the blog post [Multi-tenant data isolation with PostgreSQL Row Level Security](https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/). The AWS SaaS Factory team also [has some examples in GitHub](https://github.com/aws-samples/aws-saas-factory-postgresql-rls) to assist in implementing RLS.