productsubscription: service accounts with RBAC, instead of feature flags#60796
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @bobheadxi and the rest of your teammates on |
f667be3 to
4bfe7f4
Compare
8cdf436 to
9125390
Compare
4bfe7f4 to
d398418
Compare
9adbf60 to
0075927
Compare
19ba930 to
93561ac
Compare
02c7875 to
16ffae3
Compare
eseliger
left a comment
There was a problem hiding this comment.
seems fine, https://github.com/sourcegraph/sourcegraph/pull/60014 is probably gonna replace this once I get to it again :)
Or, you could augment this by expanding on the same permissions and roles? 😉 |
There was a problem hiding this comment.
The site-admin check is redundant. Every permission in a Sourcegraph instance is usually automaticallly applied to the SiteAdmin role.
So rbac.CheckCurrentUserHasPermission(ctx, db, rbac.ProductSubscriptionsWritePermission) will always return nil for site admins.
There was a problem hiding this comment.
Hm, I'm unable to get this behaviour in tests - test cases that call db.Users().SetIsSiteAdmin(ctx, test.user.ID, true) leads to an unauthorized response
There was a problem hiding this comment.
It's also kind of weird to make this work well in non-integration tests, where mocking permsStore.GetPermissionForUserFunc.SetDefaultHook means reimplementing this site admin behaviour
There was a problem hiding this comment.
I ended up keeping the explicit site-admin check in https://github.com/sourcegraph/sourcegraph/pull/60796/commits/a7e5dd1234bd871ae5c1f07fdace840f112a96d9 to cover those integration tests
There was a problem hiding this comment.
Yeah, that's because in test environment we don't assign the permissions to the SiteAdmin role implicitly, you'll have to manually add it to the database in the setup for your tests.
As discussed in Merge, a test helper will be helpful to avoid folks running into this gotcha.
There was a problem hiding this comment.
Would be neat if SetIsSiteAdmin assigned the role, but this is more a shortcoming of how we use DB directly so often leading to discrepancies like this, or maybe we should just get rid of site admin usage entirely
I think it's probably safer for this change to not change the nature of the checks too much, let's revisit this in a more concerted follow-up
There was a problem hiding this comment.
Yeah, unfortunately SetIsSiteAdmin is tied to role assignment while the problem here is with permissions assignment.
But you're right, let's revisit this later when #58114 is merged. That would be a good time for this improvement I guess.
Adds productsubscription RBAC roles (read and write), with the intent of replacing "cody gateway feature flag service account": https://github.com/sourcegraph/sourcegraph/pull/60796 This _could_ be used with Security team's "Entitler" service to help CEs manage subscriptions and licenses, at least until [RFC 885](https://docs.google.com/document/d/1tiaW1IVKm_YSSYhH-z7Q8sv4HSO_YJ_Uu6eYDjX7uU4/edit#heading=h.tdaxc5h34u7q) --------- Co-authored-by: Bolaji Olajide <25608335+BolajiOlajide@users.noreply.github.com>
f6737ec to
a7e5dd1
Compare
|
Rolled out the roles (roles now available via GraphQL after https://github.com/sourcegraph/sourcegraph/pull/60992): I will roll this out tomorrow |
…ith_RBAC_instead_of_feature_flags
Documents https://github.com/sourcegraph/sourcegraph/pull/60796 and https://github.com/sourcegraph/sourcegraph/pull/60795. I rolled this out yesterday without issue.

Removes the feature flag service account stuff, replacing it with "real RBAC" on permissions introduced in https://github.com/sourcegraph/sourcegraph/pull/60795. Cody Gateway SAs will need to use roles with these permissions.
This change does not migrate all product-subscriptions-related CRUD to check for the new roles - it only updates the helper used by Cody Gateway related functionality. This could be used with Security team's "Entitler" service to help CEs manage subscriptions and licenses if we expand the RBAC checks, at least until RFC 885, which is still some time away.
Rollout plan would be to deploy https://github.com/sourcegraph/sourcegraph/pull/60795, create the appropriate role and assign it to the service accounts we have today, and then roll this change out.
Test plan
Automated tests, and basic manual testing:
sg start dotcommutation { setRoles(user:"VXNlcjo0",roles:["Um9sZTo0"]) { __typename } }(must be done via API, as UI is currently disabled in dotcom mode)writepermission from the role