Open skaven81 opened 1 month ago
oh, I met the same question: I use assign mutator to add iptable rules to pod in create phase. however for hostnetwork pod, the iptable rule in pod would take effect in node scope, thus leading to other pod in this node works uncorrectly.
I have faced similar troubles with adding an annotation to LoadBalancer services - https://github.com/orgs/open-policy-agent/discussions/457
I agree with @skaven81, there is a need to support pathMatch
to test the values of a field or match
resources to narrow down resources eligible for a mutation.
As far as I know, the two existing operators MustExist
and MustNotExist
are not capable enough to filter out Loadbalancer Services for applying mutations.
From #1548 by @maxsmythe , I understand that testing values of a field (assignIf
) was supported earlier but was removed later on due to concerns of circular mutations. But, in certain cases like these it would be a helpful feature to have.
I would love to discuss about how we can add such a feature while continuing to maintaining idempotent & linear mutations. Looking forward to hearing from the OPA Gatekeeper team.
Describe the solution you'd like It is currently not possible to limit the application of a Gatekeeper mutator to only instances of a resource that have certain attributes set. A prime example of this would be creating an
Assign
mutator that setsspec.allocateLoadBalancerNodePorts=false
for any LoadBalancer Services that are created. Thematch
spec can only be as granular as matchingv1.Service
resources, so it will apply to all of ClusterIP, NodePort, and LoadBalancer type Services. And unfortunately the Kubernetes API refuses to allowspec.allocateLoadBalancerNodePorts
to be present in the Service spec ifspec.type!=LoadBalancer
. Thus, we need apathTest
that can check forspec.type == LoadBalancer
to gate the application of the mutation. The existing functionality ofsubPath
withMustExist
orMustNotExist
does not work, asspec.type
is not a prefix ofspec.allocateLoadBalancerNodePorts
. And even ifsubPath
was possible to use in this case, the two existing operatorsMustExist
andMustNotExist
are insufficient to limit application to just LoadBalancer Services.One way this could be implemented is with an additional type of
pathTest
that can check for arbitrary values in the review object:Adding a new
pathMatch
behavior topathTests
would allow for gating the activation of the mutator. UnlikesubPath
behavior, thepath
designators inpathMatch
don't have to be prefixes of the target attribute path. The purpose ofpathMatch
is to check for specific attribute values, not the presence or absence of a path. They can be structured similarly tomatchExpressions
to make construction familiar, and would thus implement the sameIn
,NotIn
,Exists
andDoesNotExist
operators thatmatchExpressions
do.With this implementation in place, it would be possible to create the Assign mutator I need:
Anything else you would like to add:
I can see how implementing this functionality under
match
might be a better option, as the whole point is to determine whether or not the object under review is even eligible for mutation. I'd be equally happy with an implementation inmatch
orpathTests
.Environment:
kubectl version
): Client Version: v1.26.12 Kustomize Version: v4.5.7 Server Version: v1.26.8