-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DDO-3719] Role Propagation #minor #575
Conversation
…stitute/sherlock into DDO-3719-propagation
What's Changed
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #575 +/- ##
==========================================
- Coverage 78.57% 77.53% -1.05%
==========================================
Files 191 202 +11
Lines 9102 9459 +357
==========================================
+ Hits 7152 7334 +182
- Misses 1322 1483 +161
- Partials 628 642 +14
|
Quality Gate passedIssues Measures |
This PR implements role propagation for [dev|qa|prod]FirecloudGroup and [dev|prod]AzureGroup. It's been tested for the dev variants in sherlock-dev. This code will remain dark in production; it's disabled by default.
Note
You may skip the overview below. It's written in case some people find that easier to digest than spoken explanations or documentation in-line.
Overview
This PR adds three new concepts to Sherlock. These concepts are entirely internal and don't show up in the API at all. They are "propagator", "propagationEngine", and "intermediaryUser." We'll go in reverse order.
An "intermediaryUser" is "how is a user represented in the remote cloud provider." It has an "identifier" that identifies the user and "fields" for anything else. Here's some examples:
An identifier is how we find a user, while the fields are just other information that Sherlock marionettes once we've found them.
A "propagationEngine" is a set of five primitives for combining some specific intermediaryUser with a specific cloud provider. It teaches Sherlock how to work with the cloud provider in an encapsulated way. The primitives are:
The idea -- and this is holding true so far -- is that these primitives just delegate to client libraries ("list users in group" for Google Groups, etc.). The idea of intermediaryUser means that we don't need to worry about a bunch of conversion logic or API calls. The Azure group engine "speaks" in UUIDs because that's just what's easiest for it.
A "propagator" combines a propagationEngine with configuration and points it at a specific field of a role. We have just a plain "Google Workspace Groups engine", but then we have a specific "dev Firecloud Group propagator" that looks at the dev Firecloud group field on a role. If we wanted to point Sherlock at prod Firecloud, we'd add a new propagator with another instance of the same engine.
Still To-Do
^ I'm pushing this to another PR, this one is big enough.
Testing
I think the testing that can be automated within Sherlock is all there. We could go to extensive effort to test the HTTP and gRPC behavior of the client libraries we're calling, but after talking to Mike I don't think that's worth it at this moment.
This has been fully deployed to dev and is confirmed to be working there.
Risk
Low.