-
Notifications
You must be signed in to change notification settings - Fork 64
✨ Check known required permissions for install before installing with the helm applier #1858
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
✨ Check known required permissions for install before installing with the helm applier #1858
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
2991d5d
to
65ef8a2
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1858 +/- ##
==========================================
- Coverage 69.53% 65.98% -3.56%
==========================================
Files 68 70 +2
Lines 5350 6182 +832
==========================================
+ Hits 3720 4079 +359
- Misses 1398 1843 +445
- Partials 232 260 +28
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
I added some tests but they still need to be tweaked/finalized. I noticed while writing them up that due to the order of the logic where missing rules are checked before escalation, if bind/escalate are in play but we're missing the explicit permissions that bind/escalate would give us we end up with a result where there's no error but we do have missing rules. @joelanford is that what we would want? I would think if we can bind or escalate that we would not return that we're missing those rules since the SA can grant them. EDIT: This isn't a concern, I misunderstood the permissions logic here |
7a6a943
to
e974006
Compare
e974006
to
8f76fa8
Compare
…uirement The clusterextensions/finalizer requirement comes from the desire to support clusters where OwnerReferencesPermissionEnforcement plugin is enabled. This plugin requires "update", but not "patch" for the clusterextensions/finalizers permission. See: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement Signed-off-by: Joe Lanford <[email protected]>
@@ -322,10 +353,21 @@ func TestApply_InstallationWithPreflightPermissionsEnabled(t *testing.T) { | |||
} | |||
helmApplier := applier.Helm{ | |||
ActionClientGetter: mockAcg, | |||
PreAuthorizer: &noOpPreAuthorizer{}, |
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.
I might be missing it, but I didn't see any unit tests for what happens when PreAuthorize
returns missing rules and/or an error.
That feels like a gap that should be covered.
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.
We have tests for that in rbac_test.go, is that fine?
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.
I added one for when there's an error, there are tests in rbac_test.go for returning missing rules, do we need to have an additional one in the applier tests here?
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.
I know you've got the applier-level tests implemented now, so just an informational answer to your question:
We have tests for that in rbac_test.go, is that fine?
Those are good, but they don't cover how the Helm Applier handles various return values from PreAuthorize
. By adding tests in the helm applier, we're not testing our specific RBAC PreAuthorizer functionality. We are testing how our helm applier handles preauthorization.
We need tests at both levels.
desiredRel: &release.Release{ | ||
Info: &release.Info{Status: release.StatusDeployed}, | ||
Manifest: validManifest, | ||
}, |
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.
Is there something novel about this test that isn't covered in the non-preflight variant of this test. It seems like this test case is about "how does helm applier handle a failed installation?", which is the same in both cases.
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.
It seems like this test case should be "fails because of a pre-auth failure"
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.
I changed the test to be when there's an error returned by preauth
Signed-off-by: Tayler Geiger <[email protected]>
Signed-off-by: Brett Tofel <[email protected]>
Signed-off-by: Brett Tofel <[email protected]>
Signed-off-by: Tayler Geiger <[email protected]>
Signed-off-by: Tayler Geiger <[email protected]>
543f099
Description
This is a successor PR to #1716 and is primarily the contributions of @trgeiger and @joelanford .
Goal and title, remain the same. Approach is a bit modified:
Pulls in RBAC authorization code from
k8s.is/kubernetes
, uses that code to check GET and other verb permissions as prelude to and as response from a Helm dry-runTo pull in the RBAC auth code concisely, repeatably and with warnings if the used code changes, we add a maintenance utility that adds the needed
replace
directives for all related staging modules (e.g.,k8s.io/api
,k8s.io/apimachinery
, etc.) and they are automatically pinned to the corresponding published version.All this code is initially called at
in
internal/operator-controller/applier/helm.go
Reviewer Checklist