AWS prescriptive-guidance documentation change
Summary
Updated image path, changed section headings from markdown headers to bold text, and adjusted code formatting to italics in several places.
Security assessment
Changes involve image path updates, formatting adjustments (headings to bold, code snippets to italics), and minor text edits. No security vulnerabilities, patches, or new security features are mentioned. The content remains focused on general OPA/ABAC implementation examples without addressing specific security flaws.
Diff
diff --git a/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/opa-abac-examples.md b/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/opa-abac-examples.md index 1af5fafb1..72bd3961a 100644 --- a//prescriptive-guidance/latest/saas-multitenant-api-access-authorization/opa-abac-examples.md +++ b//prescriptive-guidance/latest/saas-multitenant-api-access-authorization/opa-abac-examples.md @@ -7,2 +6,0 @@ -Basic OPA rules examplePartial rule using external dataPutting it all together - @@ -13 +11 @@ This section describes a scenario where OPA is used to make access decisions abo - + @@ -15 +13 @@ This section describes a scenario where OPA is used to make access decisions abo -## Basic OPA rules example +**Basic OPA rules example** @@ -40 +38 @@ OPA selects a policy or policies based on the query. In this case, the following -This policy denies access by default. It then evaluates the input in the query by binding it to the global variable `input`. The dot operator is used with this variable to access the variable's values. The Rego rule `allow` returns true if the expressions in the rule are also true. The Rego rule verifies that the `method` in the input is equal to GET. It then verifies that the first element in the list `path` is `getSalary` before assigning the second element in the list to the variable `user`. Lastly, it checks that the path being accessed is `/getSalary/bob` by checking that the `user` making the request, `input.user`, matches the `user` variable. The rule `allow` applies if-then logic to return a Boolean value, as shown in the output: +This policy denies access by default. It then evaluates the input in the query by binding it to the global variable `input`. The dot operator is used with this variable to access the variable's values. The Rego rule `allow` returns true if the expressions in the rule are also true. The Rego rule verifies that the `method` in the input is equal to GET. It then verifies that the first element in the list `path` is `getSalary` before assigning the second element in the list to the variable `user` _._ Lastly, it checks that the path being accessed is `/getSalary/bob` by checking that the `user` making the request, `input.user`, matches the _user_ variable. The rule _allow_ applies if-then logic to return a Boolean value, as shown in the output: @@ -47 +45 @@ This policy denies access by default. It then evaluates the input in the query b -## Partial rule using external data +**Partial rule using external data** @@ -68 +66 @@ You can generate an arbitrary JSON response by creating a partial rule in OPA, w -This rule returns a set of all users that report to the value of `input.user`, which, in this case, is `bob`. The `[_]` construct in the rule is used to iterate over the values of the set. This is the output of the rule: +This rule returns a set of all users that report to the value of _input.user_ , which, in this case, is bob. The [_] construct in the rule is used to iterate over the values of the set. This is the output of the rule: @@ -80 +78 @@ Retrieving this information can help determine whether a user is a direct report -## Putting it all together +**Putting it all together** @@ -104 +102 @@ To fulfill this requirement, you can use this Rego policy: -The first rule in the policy allows access for any user who tries to see their own salary information, as discussed previously. Having two rules with the same name, `allow`, functions as a logical **or** operator in Rego. The second rule retrieves the list of all direct reports associated with `input.user` (from the data in the previous diagram) and assigns this list to the `managers` variable. Lastly, the rule checks whether the user who is trying to see their salary is a direct report of `input.user` by verifying that their name is contained in the `managers` variable. +The first rule in the policy allows access for any user who tries to see their own salary information, as discussed previously. Having two rules with the same name, _allow,_ functions as a logical **or** operator in Rego. The second rule retrieves the list of all direct reports associated with _input.user_(from the data in the previous diagram) and assigns this list to the _managers_ variable. Lastly, the rule checks whether the user who is trying to see their salary is a direct report of _input.user_ by verifying that their name is contained in the _managers_ variable.