-
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-3870] Azure account provisioning via propagation #minor #661
Conversation
What's Changed
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:stamp:
This reverts commit a4ddf07.
Quality Gate passedIssues Measures |
Ports broadinstitute/terra-privileged-user-sync into Sherlock.
The cronjob is responsible for basically four steps. In Sherlock each one is a separate propagation engine.
Splitting this across engines creates a few differences in behavior:
Despite using propagation engines, accounts will not be deleted when a Sherlock RoleAssignment is removed. Instead, the necessary engines will merely suspend the user and tolerate that going forward (so it won't keep trying to remove the same users over and over again).
Propagation also now supports per-propagator-instance dry-run, where mutation operations on the engine will be logged rather than called. This will help us roll out this capability while acceptably matching the existing cronjob's behavior.
Testing
Tests added where possible, but for propagation engines the actual behavior of the client libraries is something we only truly validate when running against the cloud. See below.
Risk
The risk in this PR comes from two places:
Point 2 is heavily mitigated by the dry-run feature, but point 1 is complicated by the fact that we don't have a destructible set of Azure tenants to let this feature loose on.
If we enable this feature in dev Sherlock pointed just at dev Azure... Sherlock's own source of truth in dev is miles away from what the cronjob is used to using. The diff will be large and unrealistic. It will want to ban a bunch of actual accounts that people use on a day-to-day basis (just because no one uses Sherlock dev). We can dry-run, but there's a last mile that I think we may choose not to enable from Sherlock dev.
I think this may be an instance where it makes sense to rely on Sherlock's error recovery and engine segmentation to just... turn this on in prod. More specifically, my proposal:
In other words, there's a
AzureAccountEngine.Remove(user)
method that I think we may not want to actually run from Sherlock dev -- because Sherlock dev will want to do it in an unrealistic and destructive way (because it, by nature, doesn't have prod's knowledge of DSPers). I think it's low risk for the first execution of that to be in prod, because even if it fails, none of the rest of Sherlock would be impacted.