Skip to content
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

chore: check for CT generateVap intent before generating vapbinding #3479

Merged
merged 15 commits into from
Aug 9, 2024

Conversation

JaydipGabani
Copy link
Contributor

@JaydipGabani JaydipGabani commented Aug 8, 2024

What this PR does / why we need it:
While relying on labels for generation, we were inheriting generation behavior of VAPB from template by looking at generation-label on template. By that measure, we should check if generateVAP: true is set on template to inherit VAPB generation behavior.

Based on this comment #3478 (comment).

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
Fixes #

Special notes for your reviewer:

… binding

Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
@codecov-commenter
Copy link

codecov-commenter commented Aug 8, 2024

Codecov Report

Attention: Patch coverage is 24.00000% with 38 lines in your changes missing coverage. Please review.

Project coverage is 48.03%. Comparing base (3350319) to head (24dd83d).
Report is 119 commits behind head on master.

Files Patch % Lines
pkg/controller/constraint/constraint_controller.go 18.42% 30 Missing and 1 partial ⚠️
...onstrainttemplate/constrainttemplate_controller.go 41.66% 5 Missing and 2 partials ⚠️

❗ There is a different number of reports uploaded between BASE (3350319) and HEAD (24dd83d). Click for more details.

HEAD has 1 upload less than BASE
Flag BASE (3350319) HEAD (24dd83d)
unittests 2 1
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #3479      +/-   ##
==========================================
- Coverage   54.49%   48.03%   -6.47%     
==========================================
  Files         134      219      +85     
  Lines       12329    15167    +2838     
==========================================
+ Hits         6719     7285     +566     
- Misses       5116     7066    +1950     
- Partials      494      816     +322     
Flag Coverage Δ
unittests 48.03% <24.00%> (-6.47%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@maxsmythe
Copy link
Contributor

Can we add a description on the PR as to why this behavior change is being considered? What problem it is solving?

@maxsmythe
Copy link
Contributor

Is the bug that previously we were merely checking for the presence of CEL code, as opposed to whether that CEL code intended generation of VAP definitions (where the intent is signified by the generateVAP field value)?

@JaydipGabani
Copy link
Contributor Author

JaydipGabani commented Aug 8, 2024

Is the bug that previously we were merely checking for the presence of CEL code, as opposed to whether that CEL code intended generation of VAP definitions (where the intent is signified by the generateVAP field value)?

@maxsmythe The PR is making sure that we follow similar pattern as before. Earlier generation behavior for VAPB was inherited from looking at generation label on template. Similarly, we can check generateVAP: true on template for consistency.

PTAL at @ritazh's comment here - #3478 (comment).

@ritazh ritazh changed the title chore: checking for possibility of VAP existing in cluster before generating binding chore: check for CT generateVap intent before generating vapbinding Aug 8, 2024
Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
Copy link
Contributor

@maxsmythe maxsmythe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ritazh
Copy link
Member

ritazh commented Aug 8, 2024

Is the bug that previously we were merely checking for the presence of CEL code, as opposed to whether that CEL code intended generation of VAP definitions (where the intent is signified by the generateVAP field value)?

For completeness, this PR checks for the CT generateVap intent before generating vapbinding. Updated the PR title to reflect what is does :)

t.Run("VapBinding should be created with v1beta1", func(t *testing.T) {
suffix := "VapBindingShouldBeCreatedV1Beta1"
logger.Info("Running test: VapBinding should be created with v1beta1")
t.Run("VapBinding should not be created without VAP", func(t *testing.T) {
Copy link
Member

@ritazh ritazh Aug 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change all occurances where it says "without VAP" instead it should be "without generateVap intent in CT"

Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
generateVAPB = false
}
if !hasVAP {
r.log.V(1).Info("Warning: ConstraintTemplate will not create ValidatingAdmissionPolicy, cannot create VAPBinding")
Copy link
Member

@ritazh ritazh Aug 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
r.log.V(1).Info("Warning: ConstraintTemplate will not create ValidatingAdmissionPolicy, cannot create VAPBinding")
r.log.V(1).Info("Warning: Conditions are not satisfied to generate ValidatingAdmissionPolicyBinding")

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be part of status error? and is this also reported as part of constraint template status?

Copy link
Contributor Author

@JaydipGabani JaydipGabani Aug 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not specifically an error right? reporting it as error might be confusing.

IIRC We discussed following up with designing a shcema for VAP/VAPB related errors and warnings on constraints and constrainttemplates.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok lets leave it as a log for now for both constraint and constraint template. can you add this to the next meeting agenda so we can discuss?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added to the agenda for the next meeting.

Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
createErr := &v1beta1.CreateCRDError{Code: ErrCreateCode, Message: "ValidatingAdmissionPolicy API is not enabled, ValidatingAdmissionPolicy resource cannot be generated for ConstraintTemplate"}
status.Status.Errors = append(status.Status.Errors, createErr)
err := r.reportErrorOnCTStatus(ctx, ErrCreateCode, "Warning: ValidatingAdmissionPolicy resource cannot be generated for ConstraintTemplate", status, errors.New("ValidatingAdmissionPolicy API is not enabled"))
return reconcile.Result{}, err
Copy link
Member

@ritazh ritazh Aug 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should be consistent everywhere in terms of logs and status reporting for these. if api is not enabled and other conditions for generateVap are not met, should they be considered errors or warnings? constraint and CT status reporting currently only has errors. @maxsmythe @sozercan thoughts? depending on this decision, please make all logs and status reporting consistent

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's an error -- the user has signaled intent to trigger the generation pipeline but the pipeline is not generating.

If users don't care about the generation pipeline, they can interpret the severity of the error however they'd like.

If users would like to remove the error, they can change the expressed intent.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sgtm. then lets log error and report error as part of CT and Constraint status.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sgtm, I am updating the PR.

…ternt cannot be satisfied

Signed-off-by: Jaydip Gabani <gabanijaydip@gmail.com>
@JaydipGabani JaydipGabani requested a review from ritazh August 9, 2024 18:44
Copy link
Contributor

@maxsmythe maxsmythe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

currentVap, err := vapForVersion(groupVersion)
if err != nil {
logger.Error(err, "error getting vap object with respective groupVersion")
createErr := &v1beta1.CreateCRDError{Code: ErrCreateCode, Message: err.Error()}
status.Status.Errors = append(status.Status.Errors, createErr)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when you omit this, you are overriding existing status errors. please restore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we are not preserving statues errors here anyways - https://github.com/open-policy-agent/gatekeeper/blob/master/pkg/controller/constrainttemplate/constrainttemplate_controller.go#L404, this code I am removing isn't doing anything.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the code that we have wihtout appending to Status.Errors - https://github.com/open-policy-agent/gatekeeper/blob/master/pkg/controller/constrainttemplate/constrainttemplate_controller.go#L471 - before calling reportErrorOnCTStatus.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. ok then this has no impact on existing behavior.

Copy link
Member

@ritazh ritazh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@sozercan sozercan merged commit ed48135 into open-policy-agent:master Aug 9, 2024
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants