[A2-833] Generalize project introspection #448
Conversation
| } | ||
|
|
||
| for desc, e := range engines { | ||
| t.Run(desc, func(t *testing.T) { | ||
|
|
||
| t.Run("no matching policies", func(t *testing.T) { | ||
| policy0 := map[string]interface{}{ | ||
| "members": engine.Subject(sub), | ||
| "members": engine.Subject("team:local:foo"), |
There was a problem hiding this comment.
Test now needs to fail to find matches on the subject only.
| actual_projects = authorized_project with data.policies.polid as { | ||
| "members": ["bob"], | ||
| "statements": { | ||
| # Allowed with single project |
There was a problem hiding this comment.
This complicated block is now more digestibly covered in the couple new tests.
We can safely ignore action/resource pairs when trying to answer the question of what projects a user has access to. The algorithm does not apply the same allow/deny rules. Denied statements can simply be ignored, because access to any bit of a project by some statement is sufficient to say a user can access a given project. Signed-off-by: michael sorens <[email protected]>
Signed-off-by: michael sorens <[email protected]>
Signed-off-by: michael sorens <[email protected]>
Signed-off-by: michael sorens <[email protected]>
Signed-off-by: michael sorens <[email protected]>
Signed-off-by: michael sorens <[email protected]>
msorens
force-pushed
the
a2-833/ms/generalize-project-introspection
branch
from
9574fd1 to
67fc036
Compare
| @@ -46,7 +46,8 @@ authorized_pair[pair] { | |||
|
|
|||
| allowed_project[project] { | |||
| project := policies[pol_id].statements[statement_id].projects[_] | |||
| match_pair[["allow", _, pol_id, statement_id]] | |||
| "allow" == policies[pol_id].statements[statement_id].effect | |||
| authz.has_member[pol_id] | |||
| not policies[pol_id].type == const_system_type | |||
There was a problem hiding this comment.
Is this still necessary? If it's a system policy allowing something, a why exclude it? (but I hadn't been around when this was introduced)
There was a problem hiding this comment.
Indeed it is: system policies have wildcard projects, which means a normal user will get literally all projects as their allowed list. This line prevents that from happening.
There was a problem hiding this comment.
Hmm we could exclude policies with wildcard projects then, rather, couldn't we? 😃
There was a problem hiding this comment.
No, we do not want to do that if it is not a system policy. The above effect should result in all projects if the user has that access.
🔩 Description
IntrospectAllProjects was evaluating a subset of endpoints in determining the set of allowed projects--not taking into account parameterized endpoints. It turns out that for determining projects we can safely ignore action/resource pairs, which makes the parameterized question moot to boot.
👍 Definition of Done
The global projects filter will populate with all allowed projects, irrespective of whether they are on parameterized endpoints or not.
👟 Demo Script / Repro Steps
(Above leverages sample repro steps on the jira card--thanks @bcmdarroch!)
With all that in place:
coolbeanand you will seeproject-p1as the one and only project in the global project filter.adminand you will see that plus(unassigned)plus any others you happen to have in your system.⛓️ Related Resources
✅ Checklist