Skip to content

Cover built-in actors and identity-derived access in IAM role policy test#10550

Open
david-crespo wants to merge 1 commit into
iam-test-exemptedfrom
policy-test-builtins
Open

Cover built-in actors and identity-derived access in IAM role policy test#10550
david-crespo wants to merge 1 commit into
iam-test-exemptedfrom
policy-test-builtins

Conversation

@david-crespo

Copy link
Copy Markdown
Contributor

Built on top of #10549. I'm trying to get as much test coverage as possible for the existing authz setup to increase confidence in a conversion from Oso to Cedar I'm prototyping.

Prior to this change, test_iam_roles_behavior matrix only tests actors with roles, but there are a few cases where the Polar policy grants permissions based directly on the identity of the actor rather than based on a role. For example, a user can modify their own SSH keys just by virtue of being the owner of those keys. There are also three constant built-in actors (db-init, internal-api, external-authn), whose privileges come from fixed Polar rules and seeded fleet role assignments rather than per-resource roles.

This PR adds coverage for the role-less user and the three built-in actors to the big authz snapshot test. It definitely adds noise to the snapshot (+500 lines on top of 2200), but I think it's worth it.

Add the constant built-in actors (db-init, internal-api, external-authn) and a
roleless self-owner actor to the policy_test matrix, so it exercises the
fixed-Polar-rule and equals_silo_user self-access paths that role-grant actors
never reach.
@@ -399,12 +491,16 @@ resource: SiloUser "silo1-user"
silo1-collaborator ✘ ✔ ✔ ✔ ✘ ✘ ✘ ✘
silo1-limited-collaborator ✘ ✔ ✔ ✔ ✘ ✘ ✘ ✘
silo1-viewer ✘ ✔ ✔ ✔ ✘ ✘ ✘ ✘
silo1-user-self ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

User has all perms on self. Come to think of it, it's kind of weird that they can delete?

silo1-proj1-admin ✔ ✘ ✘ ✘ ✘ ✘ ✘ ✘
silo1-proj1-collaborator ✔ ✘ ✘ ✘ ✘ ✘ ✘ ✘
silo1-proj1-limited-collaborator ✔ ✘ ✘ ✘ ✘ ✘ ✘ ✘
silo1-proj1-viewer ✔ ✘ ✘ ✘ ✘ ✘ ✘ ✘
unauthenticated ! ! ! ! ! ! ! !
scim ✔ ✘ ✘ ✘ ✘ ✘ ✘ ✘
db-init ✔ ✘ ✘ ✘ ✔ ✔ ✘ ✔

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

db-init can init the DB!

Comment thread nexus/db-queries/tests/output/authz-roles.out
silo1-proj1-admin ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
silo1-proj1-collaborator ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
silo1-proj1-limited-collaborator ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
silo1-proj1-viewer ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
unauthenticated ! ! ! ! ! ! ! !
scim ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
db-init ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
internal-api ✘ ✔ ✔ ✔ ✔ ✔ ✔ ✔
external-authn ✘ ✔ ✘ ✔ ✔ ✔ ✘ ✔

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

external-authn makes sense here because it's creating sessions. And internal-api has the fleet admin role.

silo1-proj1-admin ✘ ✔ ✘ ✔ ✘ ✘ ✘ ✘
silo1-proj1-collaborator ✘ ✔ ✘ ✔ ✘ ✘ ✘ ✘
silo1-proj1-limited-collaborator ✘ ✔ ✘ ✔ ✘ ✘ ✘ ✘
silo1-proj1-viewer ✘ ✔ ✘ ✔ ✘ ✘ ✘ ✘
unauthenticated ! ! ! ! ! ! ! !
scim ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
db-init ✘ ✔ ✔ ✔ ✔ ✔ ✔ ✔
internal-api ✘ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition to getting fleet admin, internal-api also has silo admin on every silo. So this is probably the most interesting internal-api entry in the file.

# Allow the internal API admin permissions on all silos.
has_role(USER_INTERNAL_API: AuthenticatedActor, "admin", _silo: Silo);

silo1-proj1-admin ✘ ✔ ✔ ✔ ✘ ✘ ✘ ✘
silo1-proj1-collaborator ✘ ✔ ✔ ✔ ✘ ✘ ✘ ✘
silo1-proj1-limited-collaborator ✘ ✔ ✔ ✔ ✘ ✘ ✘ ✘
silo1-proj1-viewer ✘ ✔ ✔ ✔ ✘ ✘ ✘ ✘
unauthenticated ! ! ! ! ! ! ! !
scim ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
db-init ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
internal-api ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
external-authn ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘

@david-crespo david-crespo Jun 4, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It turns out MulticastGroup is weird in that its perms have nothing to do with roles. We just grant all authenticated users read and list children, and nobody else gets anything else. Looking into how these get created.

Edit: they get implicitly created when instance join/leave a group, and that is gated by instance modify.

# MulticastGroup is a fleet-level discovery resource.
# Join/leave authorization is gated by Instance::Modify, not the group itself.
resource MulticastGroup {
permissions = [ "read", "list_children" ];
relations = { parent_fleet: Fleet };
}
has_relation(fleet: Fleet, "parent_fleet", multicast_group: MulticastGroup)
if multicast_group.fleet = fleet;

silo1-proj1-admin ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
silo1-proj1-collaborator ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
silo1-proj1-limited-collaborator ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
silo1-proj1-viewer ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
unauthenticated ! ! ! ! ! ! ! !
scim ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
db-init ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
internal-api ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘
external-authn ✘ ✘ ✘ ✘ ✘ ✘ ✔ ✘

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Creating children of the session list (i.e., sessions) is the point of external-authn.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant