2019-05-21 15:50:36 -07:00
< small > *[documentation ](/README.md#documentation ) / Writing Policies*</ small >
2019-05-21 14:44:04 -07:00
2019-05-21 11:06:03 -07:00
# Writing Policies
2019-05-21 14:44:04 -07:00
2019-11-13 14:18:28 -08:00
The following picture shows the structure of a Kyverno Policy:
2019-11-13 14:22:54 -08:00

2019-11-13 14:18:28 -08:00
Each Kyverno policy contains one or more rules. Each rule has a match clause, an optional excludes clause, and a mutate, validate, or generate clause.
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 the match and validate clauses.
2019-05-21 14:44:04 -07:00
````yaml
2019-11-13 13:55:27 -08:00
apiVersion : kyverno.io/v1
2019-09-03 14:51:51 -07:00
kind : ClusterPolicy
2019-05-21 14:44:04 -07:00
metadata :
name : policy
spec :
2019-09-06 10:18:45 -07:00
# '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
2019-05-21 14:44:04 -07:00
# Each policy has a list of rules applied in declaration order
rules:
2019-06-12 13:50:08 -07:00
# Rules must have a unique name
- name: "check-pod-controller-labels"
2019-08-21 14:18:44 -07:00
# Each rule matches specific resource described by "match" field.
match:
resources:
2019-08-21 15:49:34 -07:00
kinds: # Required, list of kinds
2019-08-21 14:18:44 -07:00
- Deployment
- StatefulSet
2019-08-21 15:49:34 -07:00
name: "mongo*" # Optional, a resource name is optional. Name supports wildcards * and ?
2019-09-12 17:11:55 -07:00
namespaces: # Optional, list of namespaces. Supports wilcards * and ?
- "dev*"
- test
2019-08-21 15:49:34 -07:00
selector: # Optional, a resource selector is optional. Selector values support wildcards * and ?
matchLabels:
app: mongodb
matchExpressions:
- {key: tier, operator: In, values: [database]}
2019-11-13 14:18:28 -08:00
# Optional, subjects to be matched
subjects:
2019-11-14 13:34:41 -08:00
- kind: User
2019-11-13 14:18:28 -08:00
name: mary@somecorp .com
# Optional, roles to be matched
roles:
# Optional, clusterroles to be matched
clusterroles:
2019-08-21 15:49:34 -07:00
# Resources that need to be excluded
exclude: # Optional, resources to be excluded from evaulation
resources:
kinds:
- Daemonsets
2019-08-21 14:18:44 -07:00
name: "*"
2019-08-21 15:49:34 -07:00
namespaces:
2019-09-12 17:11:55 -07:00
- prod
- "kube*"
2019-08-21 14:18:44 -07:00
selector:
matchLabels:
app: mongodb
matchExpressions:
- {key: tier, operator: In, values: [database]}
2019-11-13 14:18:28 -08:00
# Optional, subjects to be excluded
subjects:
# Optional, roles to be excluded
roles:
# Optional, clusterroles to be excluded
clusterroles:
- cluster-admin
- admin
2019-08-21 15:49:34 -07:00
2019-05-21 14:44:04 -07:00
# Each rule can contain a single validate, mutate, or generate directive
...
````
2019-05-22 18:14:10 +03:00
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.
2019-05-22 00:09:45 -07:00
2019-08-21 14:18:44 -07:00
2019-05-22 00:09:45 -07:00
---
2019-05-21 15:50:36 -07:00
< small > *Read Next >> [Validate ](/documentation/writing-policies-validate.md )*</ small >