Supports wildcards (* and ?) 19 names : 20 - "mongo*" 21 - "postgres*" 22 # Optional list of namespaces. 12 match : 13 any : 14 - resources : 15 kinds : # Required, list of kinds 16 - Deployment 17 - StatefulSet 18 # Optional resource names.
In the below snippet, kinds and selector are peer/sibling elements, and so they are ANDed together.ġ spec : 2 # validationFailureAction controls admission control behaviors, 3 # when a policy rule fails: 4 # - use 'Enforce' to block resource creation or modification 5 # - use 'Audit' to allow resource updates and report policy violations 6 validationFailureAction : Enforce 7 # Each policy has a list of rules applied in declaration order 8 rules : 9 # Rules must have a unique name 10 - name : check-pod-controller-labels 11 # Each rule matches specific resource described by "match" field. Conditions inside clusterRoles, roles, and subjects are always evaluated using a logical OR operation, as each request can only have a single instance of these values. For example, if a rule match contains a list of kinds and a list of namespaces, the rule will be evaluated if the request contains any one (OR) of the kinds AND any one (OR) of the namespaces. This is an example that selects a Deployment OR a StatefulSet with a label app=critical.Ĭondition checks inside the resources block follow the logic “ AND across types but an OR within list types”. Match a Deployment or StatefulSet with a specific label
Here are some other examples of match statements. This type of matching should be used sparingly and carefully as it will instruct the API server to send every eligible resource type to Kyverno, greatly increasing the amount of processing performed by Kyverno. Typical uses for this type of wildcard matching are elements within the metadata object. WarningKeep in mind that when matching on all kinds ( *) the policy you write must be applicable across all of them. In this snippet, the match statement matches on all resources that EITHER have the kind Service with name “staging” OR have the kind Service and are being created in the “prod” Namespace. match statements also require an any or all expression allowing greater flexibility in treating multiple conditions. Variable substitution is not currently supported in match or exclude statements. The most common type of element in a match statement is one which filters on categories of Kubernetes resources, for example Pods, Deployments, Services, Namespaces, etc. Although the match statement can be complex having many different elements, there must be at least one. In every rule, there must be a single match statement to function as the filter to which the rule will apply. If both checks pass, then the rule logic to mutate, validate, or generate resources is applied. When Kyverno receives an AdmissionReview request (i.e., from a validation or mutation webhook), it first checks to see if the resource and user information matches or should be excluded from processing. Specifying a subresource in the format PodExecOptions is not supported. Use of a parent resource followed by its subresource is necessary to be explicit in the matching decision.
Due to this, matching on Scale may apply to resources like Deployment as well as ReplicationController since Scale is common between both. Some subresources are shared by multiple API resources, for example the Scale resource.
Wildcards are also supported when referencing subresources, for example */Node/status. They may be combined with previous naming as well, for example apps/v1/Deployment/scale or v1/Pod.eviction. For example, Pods/status or Pods.status will match on the /status subresource for a Pod. as a separator between parent and subresource. Subresources may be specified with either a / or.
0 kommentar(er)
