AWS prescriptive-guidance documentation change
Summary
Formatting adjustments, image path update, and minor text clarifications in OPA RBAC examples documentation
Security assessment
Changes include italicizing technical terms, fixing punctuation, and updating image paths. No evidence of addressing security vulnerabilities or introducing new security features. The modifications improve clarity but don't alter security implications of the documented RBAC implementation.
Diff
diff --git a/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/opa-rbac-examples.md b/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/opa-rbac-examples.md index c04b3485b..d3ab285f8 100644 --- a//prescriptive-guidance/latest/saas-multitenant-api-access-authorization/opa-rbac-examples.md +++ b//prescriptive-guidance/latest/saas-multitenant-api-access-authorization/opa-rbac-examples.md @@ -9 +9 @@ -This example uses OPA and Rego to demonstrate how access control can be implemented on an API for a multi-tenant application with custom roles defined by tenant users. It also demonstrates how access can be restricted based on a tenant. This model shows how OPA can make granular permission decisions based on information that is provided in a high-level role. +This example uses OPA and Rego to demonstrate how access control can be implemented on an API for a multi-tenant application with custom roles defined by tenant users. It also demonstrates how access can be restricted based on a tenant. This model shows how OPA can make _granular permission decisions_ based on information that is provided in a high-level role. @@ -11 +11 @@ This example uses OPA and Rego to demonstrate how access control can be implemen - + @@ -52 +52 @@ To show how this rule will function, consider an OPA query that has the followin -An authorization decision for this API call is made as follows, by combining the _RBAC data_ , the _OPA policies_ , and the _OPA query input_ : +An authorization decision for this API call is made as follows, by combining the RBAC data, the OPA policies, and the OPA query input: @@ -54 +54 @@ An authorization decision for this API call is made as follows, by combining the - 1. A user from `Tenant A` makes an API call to `/viewData/tenant_a`. + 1. A user from `Tenant A` makes an API call to` /viewData/tenant_a` _._ @@ -60 +60 @@ An authorization decision for this API call is made as follows, by combining the - 1. Verifies that the method used to make the API call is `GET`. + 1. Verifies that the method used to make the API call is `GET` _._ @@ -62 +62 @@ An authorization decision for this API call is made as follows, by combining the - 2. Verifies that the path requested is `viewData`. + 2. Verifies that the path requested is `viewData` _._ @@ -66 +66 @@ An authorization decision for this API call is made as follows, by combining the - 4. Pulls a list of role permissions from the roles' external data and assigns them to the variable `role_permissions`. This list is retrieved by using the tenant-defined role that is associated with the user in `input.role.` + 4. Pulls a list of role permissions from the roles' external data and assigns them to the variable `role_permissions`. This list is retrieved by using the tenant-defined role that is associated with the user in `input.role` _._ @@ -68 +68 @@ An authorization decision for this API call is made as follows, by combining the - 5. Checks `role_permissions` to see whether it contains the permission `viewData.` + 5. Checks `role_permissions` to see whether it contains the permission `viewData` _._ @@ -90 +90 @@ This process shows how RBAC and tenant awareness can contribute to making an aut -This rule would return the same output as OPA query input although it is for a different tenant who has a different role. This is because this call is for `/tenant_b` and the `view_data_role` in RBAC data still has the `viewData` permission associated with it. To enforce the same type of access control for `/updateData`, you can use a similar OPA rule: +This rule would return the same output as _OPA query input_ although it is for a different tenant who has a different role. This is because this call is for _/tenant_b_ and the _view_data_role_ in _RBAC data_ still has the _viewData_ permission associated with it. To enforce the same type of access control for _/updateData_ , you can use a similar OPA rule: @@ -102 +102 @@ This rule would return the same output as OPA query input although it is for a d -This rule is functionally the same as the `allowViewData` rule, but it verifies a different path and input method. The rule still ensures tenant isolation and checks that the tenant-defined role grants the API caller permission. To see how this might be enforced, examine the following query input for an API call to `/updateData/tenant_b`: +This rule is functionally the same as the _allowViewData_ rule, but it verifies a different path and input method. The rule still ensures tenant isolation and checks that the tenant-defined role grants the API caller permission. To see how this might be enforced, examine the following query input for an API call to _/updateData/tenant_b_ : @@ -112 +112 @@ This rule is functionally the same as the `allowViewData` rule, but it verifies -This query input, when evaluated with the `allowUpdateData` rule, returns the following authorization decision: +This query input, when evaluated with the _allowUpdateData_ rule, returns the following authorization decision: @@ -119 +119 @@ This query input, when evaluated with the `allowUpdateData` rule, returns the fo -This call will not be authorized. Although the API caller is associated with the correct `tenant_id` and is calling the API by using an approved method, the `input.role` is the tenant-defined `view_data_role`. The `view_data_role` doesn't have the `updateData` permission; therefore, the call to `/updateData` is unauthorized. This call would have been successful for a `tenant_b` user who has the `update_data_role`. +This call will not be authorized. Although the API caller is associated with the correct _tenant_id_ and is calling the API by using an approved method, the _input.role_ is the tenant-defined _view_data_role_. The _view_data_role_ doesn't have the _updateData_ permission; therefore, the call to _/updateData_ is unauthorized. This call would have been successful for a _tenant_b_ user who has the _update_data_role_.