-
Notifications
You must be signed in to change notification settings - Fork 3
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: compliance inPepr ADR #1824
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Case Wylie <[email protected]>
Signed-off-by: Case Wylie <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1824 +/- ##
=======================================
Coverage 81.59% 81.59%
=======================================
Files 54 54
Lines 2239 2239
Branches 473 474 +1
=======================================
Hits 1827 1827
Misses 383 383
Partials 29 29 |
Signed-off-by: Case Wylie <[email protected]>
These repos are related to this ADR in that they house collections of admission policies. | ||
|
||
- [Kubernetes Validating Admission Policy Library](https://github.com/vap-library/vap-library) | ||
- [CEL Admission Library](https://github.com/kubescape/cel-admission-library) |
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.
A few missing bits that we discussed are:
- pepr should only provide the mechanism to run the validation, the validation rules can be bundled separately, potentially we'll create a default list of validation, but users can add their own;
- the report generation should be either on-demand, or on schedule.
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.
Thanks, I attempted to speak to this in the new ## Goals
section. I am not entirely sure that I understood the top point. Let me know how I can change it to account for you point if it does not meet it. I am guessing you are talking about a canned set of controls?
@brandtkeller I'd like your input on this one as well |
Signed-off-by: Case Wylie <[email protected]>
@brandtkeller Also interested on what the control type should look like. const securityContextControl:ControlType = [{
Control: "NIST-300",
Reason: "Prevents Pod Escalation",
}]
When(a.Pod)
.IsCreated()
.CompliesWith(securityContextControl)
.Mutate(po => // Assign sane defaults if they do not exist)
.Validate(po => // has sane defaults? approve/reject |
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 am curious about more of the why and this is helping establish some of the ambiguity. I added some questions regarding areas that still feel ambiguous.
adr/0016-compliance-in-pepr.md
Outdated
### Consequences ### | ||
|
||
- Extend the Capability class with a new function, such as `CompliesWith()`, that accepts a strongly typed control to associate it with a given binding. | ||
- Store compliance data in `PeprStore` in a new instance to prevent corruption of compliance data through Store API. |
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 may be worth annotating more granularly what is intended to be stored. Mappings of control
<> status
for each definition or an overall collective status. As well as potentially any evidence.
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.
Great point
adr/0016-compliance-in-pepr.md
Outdated
|
||
## Decision | ||
|
||
Extend the fluent API with a new keyword function that accepts a strongly typed control, allowing it to be associated with a given binding. This enables users to map compliance controls to Pepr’s bindings, facilitating the generation of compliance reports based on control status. |
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 the intent to stick to admission or provide a separate example/implementation?
I believe admission enables compliance - but is not indicative of compliance as a whole.
OnSchedule
I think has a lot of room for use here as the general baseline.
Not to say this mechanism couldn't be used on admission - considering the levels of fidelity in doing so is important though.
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.
The answer influences some questions I had below on if module authors need to update their modules or if this is outright a separate implementation.
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.
Good points, in this case, it is the module author that is writing the Pepr bindings that is responsible for enforcing the compliance. The job is Pepr Core is to enable reporting on the bindings and functions
Pending | ||
|
||
|
||
## Context |
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 get the feeling there is some context missing here with regards to the primary functions that pepr provides and the performance of compliance objectives. They are not innately the same and the need to generate reports for compliance feels like it is missing more background.
What does Pepr do today? What could pepr do to enable compliance?
I think it is more than reporting - Evidence Collection -> Evaluation -> Aggregation -> Storage -> Reporting
- Pepr to provide the mechanism to run the validation reports. | ||
- The report generation should be either on-demand or on schedule. | ||
|
||
## Non-Goals |
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.
Are there any intended boundaries as goals or non-goals? IE is this specifically for Kubernetes or would there be intent to support infrastructure and other endpoints?
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.
Great point, it is a goal to be able to report on non-Pepr governance/non-Kubernetes governance should the module author desire to
Description
Cons are more like questions here. This ADR attempts to plan how to add compliance into Pepr through binding keywords and generate reports on demand. Implementation detail is still at a rather high level because there are questions on the format of the output.
Related Issue
Fixes #1823
Relates to #
Type of change
Checklist before merging