mirror of
https://github.com/kyverno/kyverno.git
synced 2025-03-13 19:28:55 +00:00
update docs for https://github.com/nirmata/kyverno/issues/740 and https://github.com/nirmata/kyverno/issues/741
This commit is contained in:
Jim Bugwadia
parent
ca7792589a
commit
5b02542639
2 changed files with 96 additions and 53 deletions
93
documentation/writing-policies-match-exclude.md
Normal file
93
documentation/writing-policies-match-exclude.md
Normal file
|
|
@ -0,0 +1,93 @@
|
|||
<small>*[documentation](/README.md#documentation) / Writing Policies / Match & Exclude *</small>
|
||||
|
||||
# Match & Exclude
|
||||
|
||||
The `match` and `exclude` filters control which resources policies are applied to.
|
||||
|
||||
The match / exclude clauses have the same structure, and can each contain the following elements:
|
||||
* resources: select resources by name, namespaces, kinds, and label selectors.
|
||||
* subjects: select users, user groups, and service accounts
|
||||
* roles: select namespaced roles
|
||||
* clusterroles: select cluster wide roles
|
||||
|
||||
At least one element must be specified in a `match` block. The `kind` attribute is optional, but if it's not specified the policy rule will only be applicable to metatdata that is common across all resources kinds.
|
||||
|
||||
When Kyverno receives an admission controller request, i.e. a validation or mutation webhook, it first checks to see if the resource and user information matches or should be excluded from processing. If both checks pass, then the rule logic to mutate, validate, or generate resources is applied.
|
||||
|
||||
The following YAML provides an example for a match clause.
|
||||
|
||||
````yaml
|
||||
apiVersion : kyverno.io/v1
|
||||
kind : ClusterPolicy
|
||||
metadata :
|
||||
name : policy
|
||||
spec :
|
||||
# 'enforce' to block resource request if any rules fail
|
||||
# 'audit' to allow resource request on failure of rules, but create policy violations to report them
|
||||
validationFailureAction: enforce
|
||||
# Each policy has a list of rules applied in declaration order
|
||||
rules:
|
||||
# Rules must have a unique name
|
||||
- name: "check-pod-controller-labels"
|
||||
# Each rule matches specific resource described by "match" field.
|
||||
match:
|
||||
resources:
|
||||
kinds: # Required, list of kinds
|
||||
- Deployment
|
||||
- StatefulSet
|
||||
name: "mongo*" # Optional, a resource name is optional. Name supports wildcards (* and ?)
|
||||
namespaces: # Optional, list of namespaces. Supports wildcards (* and ?)
|
||||
- "dev*"
|
||||
- test
|
||||
selector: # Optional, a resource selector is optional. Values support wildcards (* and ?)
|
||||
matchLabels:
|
||||
app: mongodb
|
||||
matchExpressions:
|
||||
- {key: tier, operator: In, values: [database]}
|
||||
# Optional, subjects to be matched
|
||||
subjects:
|
||||
- kind: User
|
||||
name: mary@somecorp.com
|
||||
# Optional, roles to be matched
|
||||
roles:
|
||||
# Optional, clusterroles to be matched
|
||||
clusterroles: cluster-admin
|
||||
|
||||
...
|
||||
|
||||
````
|
||||
|
||||
All`match` and `exclude` element must be satisfied for the resource to be selected as a candidate for the policy rule. In other words, the match and exclude conditions are evaluated using a logical AND operation.
|
||||
|
||||
Here is an example of a rule that matches all pods, excluding pods created by using the `cluster-admin` cluster role.
|
||||
|
||||
````yaml
|
||||
spec:
|
||||
rules:
|
||||
name: "match-pods-except-admin"
|
||||
match:
|
||||
resources:
|
||||
kinds:
|
||||
- Pod
|
||||
exclude:
|
||||
clusterroles: cluster-admin
|
||||
````
|
||||
|
||||
This rule that matches all pods, excluding pods in the `kube-system` namespace.
|
||||
|
||||
````yaml
|
||||
spec:
|
||||
rules:
|
||||
name: "match-pods-except-admin"
|
||||
match:
|
||||
resources:
|
||||
kinds:
|
||||
- Pod
|
||||
exclude:
|
||||
namespaces:
|
||||
- "kube-system"
|
||||
````
|
||||
|
||||
|
||||
---
|
||||
<small>*Read Next >> [Validate Resources](/documentation/writing-policies-validate.md)*</small>
|
||||
|
|
@ -8,59 +8,9 @@ The following picture shows the structure of a Kyverno Policy:
|
|||
|
||||
Each Kyverno policy contains one or more rules. Each rule has a `match` clause, an optional `exclude` clause, and one of a `mutate`, `validate`, or `generate` clause.
|
||||
|
||||
The match / exclude clauses have the same structure, and can contain the following elements:
|
||||
* resources: select resources by name, namespaces, kinds, and label selectors.
|
||||
* subjects: select users, user groups, and service accounts
|
||||
* roles: select namespaced roles
|
||||
* clusterroles: select cluster wide roles
|
||||
|
||||
When Kyverno receives an admission controller request, i.e. a validation or mutation webhook, it first checks to see if the resource and user information matches or should be excluded from processing. If both checks pass, then the rule logic to mutate, validate, or generate resources is applied.
|
||||
|
||||
The following YAML provides an example for a match clause.
|
||||
|
||||
````yaml
|
||||
apiVersion : kyverno.io/v1
|
||||
kind : ClusterPolicy
|
||||
metadata :
|
||||
name : policy
|
||||
spec :
|
||||
# 'enforce' to block resource request if any rules fail
|
||||
# 'audit' to allow resource request on failure of rules, but create policy violations to report them
|
||||
validationFailureAction: enforce
|
||||
# Each policy has a list of rules applied in declaration order
|
||||
rules:
|
||||
# Rules must have a unique name
|
||||
- name: "check-pod-controller-labels"
|
||||
# Each rule matches specific resource described by "match" field.
|
||||
match:
|
||||
resources:
|
||||
kinds: # Required, list of kinds
|
||||
- Deployment
|
||||
- StatefulSet
|
||||
name: "mongo*" # Optional, a resource name is optional. Name supports wildcards (* and ?)
|
||||
namespaces: # Optional, list of namespaces. Supports wildcards (* and ?)
|
||||
- "dev*"
|
||||
- test
|
||||
selector: # Optional, a resource selector is optional. Values support wildcards (* and ?)
|
||||
matchLabels:
|
||||
app: mongodb
|
||||
matchExpressions:
|
||||
- {key: tier, operator: In, values: [database]}
|
||||
# Optional, subjects to be matched
|
||||
subjects:
|
||||
- kind: User
|
||||
name: mary@somecorp.com
|
||||
# Optional, roles to be matched
|
||||
roles:
|
||||
# Optional, clusterroles to be matched
|
||||
clusterroles: cluster-admin
|
||||
|
||||
...
|
||||
|
||||
````
|
||||
|
||||
Each rule can validate, mutate, or generate configurations of matching resources. A rule definition can contain only a single **mutate**, **validate**, or **generate** child node. These actions are applied to the resource in described order: mutation, validation and then generation.
|
||||
Each rule can validate, mutate, or generate configurations of matching resources. A rule definition can contain only a single **mutate**, **validate**, or **generate** child node.
|
||||
|
||||
These actions are applied to the resource in described order: mutation, validation and then generation.
|
||||
|
||||
---
|
||||
<small>*Read Next >> [Validate Resources](/documentation/writing-policies-validate.md)*</small>
|
||||
<small>*Read Next >> [Validate Resources](/documentation/writing-policies-match-exclude.md)*</small>
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue