518 pod controller #573
518 pod controller #573
Conversation
…controller # Conflicts: # pkg/api/kyverno/v1/types.go # pkg/engine/mutation.go # pkg/engine/mutation_test.go # pkg/engine/validation.go # pkg/policy/existing.go
add anchors for omitempty tag
There was a problem hiding this comment.
Approving this for now due to time, as this is intermediate changes and will be re-worked soon.
In future will be better to decouple the logic from engine. As the engine api should not return different results fro policy-controller and admission control. But the behavior should be handed my the caller of the engine api.
Alos use background flag to identify if the policy is to be processed in background, but this is a user controlled flag.
| @@ -39,7 +48,7 @@ func Mutate(policyContext PolicyContext) (resp response.EngineResponse) { | |||
|
|
|||
| for _, rule := range policy.Spec.Rules { | |||
| //TODO: to be checked before calling the resources as well | |||
| if !rule.HasMutate() { | |||
| if !rule.HasMutate() && !strings.Contains(PodControllers, resource.GetKind()) { | |||
There was a problem hiding this comment.
Use slice of strings instead of comma-separated string of values.
There was a problem hiding this comment.
Any reason to change to a slice?
|
|
||
| if strings.Contains(PodControllers, resource.GetKind()) { | ||
| var ruleResponse response.RuleResponse | ||
| ruleResponse, patchedResource = processOverlay(ctx, podTemplateRule, patchedResource) |
There was a problem hiding this comment.
Would the annotation be also added for existing resources?
When policy-contoller is processing values in the background. For mutation, we don't apply patches to the resource.
With this, we will create a policy violation if the annotation is not present.
Shouldn't we add annotations in admission control only and not the policy-controller ?
There was a problem hiding this comment.
|
@shivdudhani |
|
@realshuting Also we skip some rules in background mode which does not depend on The intent to have a clear separation of logic in code. As we now have no control if the auto-generate rules as an update, we should capture the cases in an issue so that we can work on them in the future. |
|
Yes we should be able to handle the scenario when policy updates, track #586. And as you mentioned: ".. from policy engine API takes resource and policy as input .., .. we do checks for rules on pod-controllers inside the policy engine", the problem here is engine accepts A policy while annotation patches are generated PER rule, maybe later with the built-in policy, we should be able to express this condition(applies to incoming resource) in the rule definition. |
Fix #518, tested #572.