-
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-3868] Faster break-glass propagation #655
Conversation
What's Changed
|
This reverts commit 63704be.
…-faster-propagation
Quality Gate passedIssues Measures |
Three-pronged approach:
1. Composite/plural grants are now supported. More plainly, this means that the following now does what you'd expect:
This plural grant support is implemented for all existing propagated-grant fields just as comma separation (with whitespace trimming) so it's backwards compatible. This can potentially help propagation in that I think group nesting may take longer than direct group membership.
If we add Firecloud account creation or GitHub org membership in the future, plural grants might not make much sense (suppose the grant might just be indicated by a boolean, not a string). That's okay, we'd just configure the propagator like this:
2. Can now grant dev/qa/prod Firecloud accounts
roles/owner
on Google Cloud folders (new propagation engine + new role grant fields). More plainly, the following is now supported:The folders can be in any organization -- the reference to Firecloud just describes what accounts will be given the access. Sherlock's SA will need resourcemanager.folders.get/setIamPolicy on the folders.
When Sherlock targets a folder it assumes no other system will give user @firecloud.org accounts
roles/owner
. Service accounts, groups, users from other domains, or user @firecloud.org accounts with roles other thanroles/owner
will be unaffected. Identiteam has confirmed that no Terra system ever grants anyoneroles/owner
so we've got multiple layers between us and a conflict.3. Propagators now run in parallel for a given role. The sequencing and parallelization of different propagators is easily changed from the role propagation package's init function.
Right now, full parallelization is fine, but this design explicitly allows for sequential steps still so we can have any future Firecloud account creation or GitHub org membership propagator run first.
Testing
Tests written for all of this. For parts 1 and 3 especially the existing tests provide excellent regression coverage.
Part 2 can be enabled in dev before prod, and even in prod we can target it at dev or qa Firecloud before prod.
Risk
Moderate. 1 and 3 are under the hood changes that regression testing fully captures.
2 is risky as Sherlock will begin modifying IAM directly instead of indirectly. The overall design of the system isn't changing -- whereas Sherlock currently modifies IAM by adding people to a group that has an IAM grant, Sherlock will begin modifying IAM by adding people to it directly.
The code isn't zero risk but the vast majority of the logic is already inherited by the propagation system. I'd judge that the larger risk comes from the potential for super-admins setting incorrect configuration. Putting a folder grant on the wrong role would be bad... but it's entirely possible for someone to typo the group in a Google IAM panel too. Somewhere in the stack we have to have the danger button.