mirror of
https://github.com/kyverno/kyverno.git
synced 2025-03-31 03:45:17 +00:00
shuting
GitHub
commit
e6ef02e7d8
14 changed files with 479 additions and 67 deletions
67
README.md
67
README.md
|
|
@ -10,7 +10,7 @@ Kyverno allows cluster adminstrators to manage environment specific configuratio
|
|||
|
||||
Kyverno policies are Kubernetes resources that can be written in YAML or JSON. Kyverno policies can validate, mutate, and generate any Kubernetes resources.
|
||||
|
||||
Kyverno runs as a [dynamic admission controller](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) in a Kubernetes cluster. Kyverno receives validating and mutating admission webhook HTTP callbacks from the kube-apiserver and applies matching polcies to return results that enforce admission policies or reject requests.
|
||||
Kyverno runs as a [dynamic admission controller](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) in a Kubernetes cluster. Kyverno receives validating and mutating admission webhook HTTP callbacks from the kube-apiserver and applies matching policies to return results that enforce admission policies or reject requests.
|
||||
|
||||
Kyverno policies can match resources using the resource kind, name, and label selectors. Wildcards are supported in names.
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ Policy enforcement is captured using Kubernetes events. Kyverno also reports pol
|
|||
This policy requires that all pods have CPU and memory resource requests and limits:
|
||||
|
||||
````yaml
|
||||
apiVersion: policy.nirmata.io/v1alpha1
|
||||
apiVersion: kyverno.io/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: check-cpu-memory
|
||||
|
|
@ -33,7 +33,8 @@ spec:
|
|||
rules:
|
||||
- name: check-pod-resources
|
||||
resource:
|
||||
kind: Pod
|
||||
kinds:
|
||||
- Pod
|
||||
validate:
|
||||
message: "CPU and memory resource requests and limits are required"
|
||||
pattern:
|
||||
|
|
@ -43,12 +44,13 @@ spec:
|
|||
- name: "*"
|
||||
resources:
|
||||
limits:
|
||||
# '?' requires a value (at least 1 character)
|
||||
memory: "?"
|
||||
cpu: "?"
|
||||
# '?' requires 1 alphanumeric character and '*' means that there can be 0 or more characters.
|
||||
# Using them togther e.g. '?*' requires at least one character.
|
||||
memory: "?*"
|
||||
cpu: "?*"
|
||||
requests:
|
||||
memory: "?"
|
||||
cpu: "?"
|
||||
memory: "?*"
|
||||
cpu: "?*"
|
||||
````
|
||||
|
||||
### 2. Mutating resources
|
||||
|
|
@ -56,7 +58,7 @@ spec:
|
|||
This policy sets the imagePullPolicy to Always if the image tag is latest:
|
||||
|
||||
````yaml
|
||||
apiVersion: policy.nirmata.io/v1alpha1
|
||||
apiVersion: kyverno.io/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: set-image-pull-policy
|
||||
|
|
@ -64,15 +66,18 @@ spec:
|
|||
rules:
|
||||
- name: set-image-pull-policy
|
||||
resource:
|
||||
kind: Pod
|
||||
kinds:
|
||||
- Deployment
|
||||
mutate:
|
||||
overlay:
|
||||
spec:
|
||||
containers:
|
||||
# match images which end with :latest
|
||||
- image: "(*:latest)"
|
||||
# set the imagePullPolicy to "Always"
|
||||
imagePullPolicy: "Always"
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
# match images which end with :latest
|
||||
- (image): "*:latest"
|
||||
# set the imagePullPolicy to "Always"
|
||||
imagePullPolicy: "Always"
|
||||
````
|
||||
|
||||
### 3. Generating resources
|
||||
|
|
@ -80,7 +85,7 @@ spec:
|
|||
This policy sets the Zookeeper and Kafka connection strings for all namespaces with a label key 'kafka'.
|
||||
|
||||
````yaml
|
||||
apiVersion: policy.nirmata.io/v1alpha1
|
||||
apiVersion: kyverno.io/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: "zk-kafka-address"
|
||||
|
|
@ -88,7 +93,8 @@ spec:
|
|||
rules:
|
||||
- name: "zk-kafka-address"
|
||||
resource:
|
||||
kind : Namespace
|
||||
kinds:
|
||||
- Namespace
|
||||
selector:
|
||||
matchExpressions:
|
||||
- {key: kafka, operator: Exists}
|
||||
|
|
@ -104,6 +110,17 @@ spec:
|
|||
|
||||
Additional examples are available in [examples](/examples).
|
||||
|
||||
## Alternatives
|
||||
|
||||
### Open Policy Agent
|
||||
|
||||
[Open Policy Agent (OPA)](https://www.openpolicyagent.org/) is a general-purpose policy engine that can be used as a Kubernetes admission controller. It supports a large set of use cases. Policies are written using [Rego](https://www.openpolicyagent.org/docs/latest/how-do-i-write-policies#what-is-rego) a custom query language.
|
||||
|
||||
### External configuration management tools
|
||||
|
||||
Tools like [Kustomize](https://github.com/kubernetes-sigs/kustomize) can be used to manage variations in configurations outside of clusters. There are several advantages to this approach when used to produce variations of the same base configuration. However, such solutions cannot be used to validate or enforce configurations.
|
||||
|
||||
|
||||
## Status
|
||||
|
||||
*Kyverno is under active development and not ready for production use. Key components and policy definitions are likely to change as we complete core features.*
|
||||
|
|
@ -113,23 +130,23 @@ Additional examples are available in [examples](/examples).
|
|||
|
||||
* [Getting Started](documentation/installation.md)
|
||||
* [Writing Policies](documentation/writing-policies.md)
|
||||
* [Validate](documentation/writing-policies-validate.md)
|
||||
* [Mutate](documentation/writing-policies-mutate.md)
|
||||
* [Validate](documentation/writing-policies-validate.md)
|
||||
* [Generate](documentation/writing-policies-generate.md)
|
||||
* [Testing Policies](documentation/testing-policies.md)
|
||||
* [Using kubectl](documentation/testing-policies-kubectl.md)
|
||||
* [Using the Kyverno CLI](documentation/testing-policies-kyverno-cli.md)
|
||||
* [Using kubectl](documentation/testing-policies.md#Test-using-kubectl)
|
||||
* [Using the Kyverno CLI](documentation/testing-policies.md#Test-using-the-Kyverno-CLI)
|
||||
|
||||
|
||||
## Roadmap
|
||||
|
||||
Here are some the major features we plan on completing before a 1.0 release:
|
||||
|
||||
* Events
|
||||
* Policy Violations
|
||||
* Generate any resource
|
||||
* Conditionals on existing resources
|
||||
* Extend CLI to operate on cluster resources
|
||||
* [Events](https://github.com/nirmata/kyverno/issues/14)
|
||||
* [Policy Violations](https://github.com/nirmata/kyverno/issues/24)
|
||||
* [Generate any resource](https://github.com/nirmata/kyverno/issues/21)
|
||||
* [Conditionals on existing resources](https://github.com/nirmata/kyverno/issues/57)
|
||||
* [Extend CLI to operate on cluster resources ](https://github.com/nirmata/kyverno/issues/25)
|
||||
|
||||
## Getting help
|
||||
|
||||
|
|
|
|||
|
|
@ -1,23 +1,41 @@
|
|||
<small>*[documentation](/README.md#documentation) / Installation*</small>
|
||||
|
||||
# Installation
|
||||
|
||||
The controller can be installed and operated in two ways: **Outside the cluster** and **Inside the cluster**. The controller **outside** the cluster is much more convenient to debug and verify changes in its code, so we can call it 'debug mode'. The controller **inside** the cluster is designed for use in the real world, and the **QA testing** should be performed when controller operate in this mode.
|
||||
To install Kyverno in your cluster run the following command on a host with kubectl access:
|
||||
|
||||
````sh
|
||||
kubectl create -f https://github.com/nirmata/kyverno/raw/master/definitions/install.yaml
|
||||
````
|
||||
|
||||
## Inside the cluster (normal use)
|
||||
To check the Kyverno controller status, run the command:
|
||||
|
||||
Just execute the command for creating all necesarry resources:
|
||||
`kubectl create -f definitions/install.yaml`
|
||||
````sh
|
||||
kubectl get pods -n kyverno
|
||||
````
|
||||
|
||||
If the Kyverno controller is not running, you can check its status and logs for errors:
|
||||
|
||||
````sh
|
||||
kubectl describe pod <kyverno-pod-name> -n kyverno
|
||||
````
|
||||
|
||||
````sh
|
||||
kubectl logs <kyverno-pod-name> -n kyverno
|
||||
````
|
||||
|
||||
# Installing in a Development Environment
|
||||
|
||||
To build and run Kyverno in a development environment see: https://github.com/nirmata/kyverno/wiki/Building
|
||||
|
||||
In this mode controller will get TLS key/certificate pair and loads in-cluster config automatically on start.
|
||||
To check if the controller is working, find it in the list of kyverno pods:
|
||||
|
||||
`kubectl get pods -n kyverno`
|
||||
|
||||
The pod with controller contains **'kyverno'** in its name. The STATUS column will show the health state of the controller. If controller doesn't start, see its logs:
|
||||
# Try Kyverno without a Kubernetes cluster
|
||||
|
||||
`kubectl describe pod <kyverno-pod-name> -n kyverno`
|
||||
The [Kyverno CLI](documentation/testing-policies-cli.md) allows you to write and test policies without installing Kyverno in a Kubernetes cluster.
|
||||
|
||||
or
|
||||
|
||||
`kubectl logs <kyverno-pod-name> -n kyverno`
|
||||
|
||||
---
|
||||
<small>*Read Next >> [Writing Policies](/documentation/writing-policies.md)*</small>
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
# Kyverno CLI
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
# Testing using kubectl
|
||||
|
||||
|
|
@ -1 +1,60 @@
|
|||
<small>*[documentation](/README.md#documentation) / Testing Policies*</small>
|
||||
|
||||
|
||||
# Testing Policies
|
||||
The resources definitions for testing are located in [/test](/test) directory. Each test contains a pair of files: one is the resource definition, and the second is the kyverno policy for this definition.
|
||||
|
||||
## Test using kubectl
|
||||
To do this you should [install kyverno to the cluster](/documentation/installation.md).
|
||||
|
||||
For example, to test the simplest kyverno policy for ConfigMap, create the policy and then the resource itself via kubectl:
|
||||
````bash
|
||||
cd test/ConfigMap
|
||||
kubectl create -f policy-CM.yaml
|
||||
kubectl create -f CM.yaml
|
||||
````
|
||||
Then compare the original resource definition in CM.yaml with the actual one:
|
||||
````bash
|
||||
kubectl get -f CM.yaml -o yaml
|
||||
````
|
||||
|
||||
## Test using the Kyverno CLI
|
||||
|
||||
The Kyverno Command Line Interface (CLI) tool enables writing and testing policies without requiring Kubernetes clusters and without having to apply local policy changes to a cluster.
|
||||
|
||||
### Building the CLI
|
||||
|
||||
You will need a [Go environment](https://golang.org/doc/install) setup.
|
||||
|
||||
1. Clone the Kyverno repo
|
||||
|
||||
````bash
|
||||
git clone https://github.com/nirmata/kyverno/
|
||||
````
|
||||
|
||||
2. Build the CLI
|
||||
|
||||
````bash
|
||||
cd kyverno/cmd
|
||||
go build
|
||||
````
|
||||
|
||||
Or, you can directly build and install the CLI using `go get`:
|
||||
|
||||
````bash
|
||||
go get -u https://github.com/nirmata/kyverno/cmd
|
||||
````
|
||||
|
||||
### Using the CLI
|
||||
|
||||
To test a policy using the CLI type:
|
||||
|
||||
`kyverno <policy> <resource YAML file or folder>`
|
||||
|
||||
For example:
|
||||
|
||||
```bash
|
||||
kyverno ../examples/CLI/policy-deployment.yaml ../examples/CLI/resources
|
||||
```
|
||||
|
||||
In future releases, the CLI will support complete validation of policies and will allow testing policies against resources in Kubernetes clusters.
|
||||
|
|
|
|||
|
|
@ -1 +1,49 @@
|
|||
# Policies that Generate Configurations
|
||||
<small>*[documentation](/README.md#documentation) / [Writing Policies](/documentation/writing-policies.md) / Generate*</small>
|
||||
|
||||
# Generate Configurations
|
||||
|
||||
```generatate``` feature can be applied to created namespaces to create new resources in them. This feature is useful when every namespace in a cluster must contain some basic required resources. The feature is available for policy rules in which the resource kind is Namespace.
|
||||
|
||||
## Example
|
||||
|
||||
````yaml
|
||||
apiVersion : kyverno.io/v1alpha1
|
||||
kind : Policy
|
||||
metadata :
|
||||
name : basic-policy
|
||||
spec :
|
||||
rules:
|
||||
- name: "Basic confog generator for all namespaces"
|
||||
resource:
|
||||
kind: Namespace
|
||||
generate:
|
||||
# For now the next kinds are supported:
|
||||
# ConfigMap
|
||||
# Secret
|
||||
- kind: ConfigMap
|
||||
name: default-config
|
||||
copyFrom:
|
||||
namespace: default
|
||||
name: config-template
|
||||
data:
|
||||
DB_ENDPOINT: mongodb://mydomain.ua/db_stage:27017
|
||||
labels:
|
||||
purpose: mongo
|
||||
- kind: Secret
|
||||
name: mongo-creds
|
||||
data:
|
||||
DB_USER: YWJyYWthZGFicmE=
|
||||
DB_PASSWORD: YXBwc3dvcmQ=
|
||||
labels:
|
||||
purpose: mongo
|
||||
````
|
||||
|
||||
In this example, when this policy is applied, any new namespace will receive 2 new resources after its creation:
|
||||
* ConfigMap copied from default/config-template with added value DB_ENDPOINT.
|
||||
* Secret with values DB_USER and DB_PASSWORD.
|
||||
|
||||
Both resources will contain a label ```purpose: mongo```
|
||||
|
||||
---
|
||||
<small>*Read Next >> [Testing Policies](/documentation/testing-policies.md)*</small>
|
||||
|
||||
|
|
|
|||
|
|
@ -1 +1,139 @@
|
|||
# Policies that Mutate Configurations
|
||||
<small>*[documentation](/README.md#documentation) / [Writing Policies](/documentation/writing-policies.md) / Mutate*</small>
|
||||
|
||||
# Mutate Configurations
|
||||
|
||||
The ```mutate``` rule contains actions that should be applied to the resource before its creation. Mutation can be made using patches or overlay. Using ```patches``` in the JSONPatch format, you can make point changes to the created resource, and ```overlays``` are designed to bring the resource to the desired view according to a specific pattern.
|
||||
|
||||
Resource mutation occurs before validation, so the validation rules should not contradict the changes set in the mutation section.
|
||||
|
||||
## Patches
|
||||
|
||||
The patches are used to make direct changes in the created resource. In the next example the patch will be applied to all Deployments that contain a word "nirmata" in the name.
|
||||
|
||||
````yaml
|
||||
apiVersion : kyverno.io/v1alpha1
|
||||
kind : Policy
|
||||
metadata :
|
||||
name : policy-v1
|
||||
spec :
|
||||
rules:
|
||||
- name: "Deployment of *nirmata* images"
|
||||
resource:
|
||||
kind: Deployment
|
||||
# Name is optional. By default validation policy is applicable to any resource of supported kind.
|
||||
# Name supports wildcards * and ?
|
||||
name: "*nirmata*"
|
||||
mutate:
|
||||
patches:
|
||||
# This patch adds sidecar container to every deployment that matches this policy
|
||||
- path: "/spec/template/spec/containers/0/"
|
||||
op: add
|
||||
value:
|
||||
- image: "nirmata.io/sidecar:latest"
|
||||
imagePullPolicy: "Always"
|
||||
ports:
|
||||
- containerPort: 443
|
||||
````
|
||||
There is one patch in the rule, it will add the new image to the "containers" list with specified parameters. Patch is described in [JSONPatch](http://jsonpatch.com/) format and support the operations ('op' field):
|
||||
* **add**
|
||||
* **replace**
|
||||
* **remove**
|
||||
|
||||
Here is the example with of a patch which removes a label from the secret:
|
||||
````yaml
|
||||
apiVersion : kyverno.io/v1alpha1
|
||||
kind : Policy
|
||||
metadata :
|
||||
name : policy-remove-label
|
||||
spec :
|
||||
rules:
|
||||
- name: "Remove unwanted label"
|
||||
resource:
|
||||
# Will be applied to all secrets, because name and selector are not specified
|
||||
kind: Secret
|
||||
mutate:
|
||||
patches:
|
||||
- path: "/metadata/labels/purpose"
|
||||
op: remove
|
||||
````
|
||||
|
||||
Note, that if **remove** operation cannot be applied, then this **remove** operation will be skipped with no error.
|
||||
|
||||
## Overlay
|
||||
|
||||
The Mutation Overlay is the desired form of resource. The existing resource parameters are replaced with the parameters described in the overlay. If there are no such parameters in the target resource, they are copied to the resource from the overlay. The overlay is not used to delete the properties of a resource: use **patches** for this purpose.
|
||||
|
||||
The next overlay will add or change the hard limit for memory to 2 gigabytes in every ResourceQuota with label ```quota: low```:
|
||||
|
||||
````yaml
|
||||
apiVersion : kyverno.io/v1alpha1
|
||||
kind : Policy
|
||||
metadata :
|
||||
name : policy-change-memory-limit
|
||||
spec :
|
||||
rules:
|
||||
- name: "Set hard memory limit to 2Gi"
|
||||
resource:
|
||||
# Will be applied to all secrets, because name and selector are not specified
|
||||
kind: ResourceQuota
|
||||
selector:
|
||||
matchLabels:
|
||||
quota: low
|
||||
mutate:
|
||||
overlay:
|
||||
spec:
|
||||
hard:
|
||||
limits.memory: 2Gi
|
||||
````
|
||||
The ```overlay``` keyword under ```mutate``` feature describes the desired form of ResourceQuota.
|
||||
|
||||
### Working with lists
|
||||
|
||||
The application of an overlay to the list without additional settings is pretty straightforward: the new items will be added to the list exсept of those that totally equal to existent items. For example, the next overlay will add IP "192.168.10.172" to all addresses in all Endpoints:
|
||||
|
||||
````yaml
|
||||
apiVersion: policy.nirmata.io/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: policy-endpoints-
|
||||
spec:
|
||||
rules:
|
||||
- resource:
|
||||
# Applied to all endpoints
|
||||
kind : Endpoints
|
||||
mutate:
|
||||
overlay:
|
||||
subsets:
|
||||
- addresses:
|
||||
- ip: 192.168.10.172
|
||||
````
|
||||
|
||||
You can use overlays to merge objects inside lists using **anchor** items marked by parentheses. For example, this overlay will add/replace port to 6443 in all ports with name that start from the word "secure":
|
||||
````yaml
|
||||
apiVersion : policy.nirmata.io/v1alpha1
|
||||
kind : Policy
|
||||
metadata :
|
||||
name : policy-endpoints-should-be-more-secure
|
||||
spec :
|
||||
rules:
|
||||
- resource:
|
||||
# Applied to all endpoints
|
||||
kind : Endpoints
|
||||
mutate:
|
||||
overlay:
|
||||
subsets:
|
||||
- ports:
|
||||
- (name): "secure*"
|
||||
port: 6443
|
||||
````
|
||||
|
||||
The **anchors** marked in parentheses support **wildcards**:
|
||||
1. `*` - matches zero or more alphanumeric characters
|
||||
2. `?` - matches a single alphanumeric character
|
||||
|
||||
## Details
|
||||
|
||||
The behavior of overlays described more detailed in the project's wiki: [Mutation Overlay](https://github.com/nirmata/kyverno/wiki/Mutation-Overlay)
|
||||
|
||||
---
|
||||
<small>*Read Next >> [Validate](/documentation/writing-policies-validate.md)*</small>
|
||||
|
|
|
|||
|
|
@ -1 +1,71 @@
|
|||
# Policies that Validate Configurations
|
||||
<small>*[documentation](/README.md#documentation) / [Writing Policies](/documentation/writing-policies.md) / Validate*</small>
|
||||
|
||||
|
||||
# Validate Configurations
|
||||
|
||||
A validation rule is expressed as an overlay pattern that expresses the desired configuration. Resource configurations must match fields and expressions defined in the pattern to pass the validation rule. The following rules are followed when processing the overlay pattern:
|
||||
|
||||
1. Validation will fail if a field is defined in the pattern and if the field does not exist in the configuration.
|
||||
2. Undefined fields are treated as wildcards.
|
||||
3. A validation pattern field with the wildcard value '*' will match zero or more alphanumeric characters. Empty values or missing fields are matched.
|
||||
4. A validation pattern field with the wildcard value '?' will match any single alphanumeric character. Empty or missing fields are not matched.
|
||||
5. A validation pattern field with the wildcard value '?*' will match any alphanumeric characters and requires the field to be present with non-empty values.
|
||||
6. A validation pattern field with the value `null` or "" (empty string) requires that the field not be defined or has no value.
|
||||
7. The validation of siblings is performed only when one of the field values matches the value defined in the pattern. You can use the parenthesis operator to explictly specify a field value that must be matched. This allows writing rules like 'if fieldA equals X, then fieldB must equal Y'.
|
||||
8. Validation of child values is only performed if the parent matches the pattern.
|
||||
|
||||
## Patterns
|
||||
|
||||
### Wildcards
|
||||
1. `*` - matches zero or more alphanumeric characters
|
||||
2. `?` - matches a single alphanumeric character
|
||||
|
||||
### Operators
|
||||
|
||||
| Operator | Meaning |
|
||||
|------------|---------------------------|
|
||||
| `>` | greater than |
|
||||
| `<` | less than |
|
||||
| `>=` | greater than or equals to |
|
||||
| `<=` | less than or equals to |
|
||||
| `!` | not equals |
|
||||
| \| | logical or |
|
||||
|
||||
There is no operator for `equals` as providing a field value in the pattern requires equality to the value.
|
||||
|
||||
## Example
|
||||
The next rule prevents the creation of Deployment, StatefuleSet and DaemonSet resources without label 'app' in selector:
|
||||
````yaml
|
||||
|
||||
apiVersion : kyverno.io/v1alpha1
|
||||
kind : Policy
|
||||
metadata :
|
||||
name : validation-example
|
||||
spec :
|
||||
rules:
|
||||
- resource:
|
||||
# Kind specifies one or more resource types to match
|
||||
kinds:
|
||||
- Deployment
|
||||
- StatefuleSet
|
||||
- DaemonSet
|
||||
# Name is optional and can use wildcards
|
||||
name: *
|
||||
# Selector is optional
|
||||
selector:
|
||||
validate:
|
||||
# Message is optional
|
||||
message: "The label app is required"
|
||||
pattern:
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: "?*"
|
||||
|
||||
````
|
||||
|
||||
Additional examples are available in [examples](/examples/)
|
||||
|
||||
|
||||
---
|
||||
<small>*Read Next >> [Generate](/documentation/writing-policies-generate.md)*</small>
|
||||
|
|
|
|||
|
|
@ -1 +1,43 @@
|
|||
<small>*[documentation](/README.md#documentation) / Writing Policies*</small>
|
||||
|
||||
# Writing Policies
|
||||
|
||||
A Kyverno policy contains a set of rules. Each rule matches resources by kind, name, or selectors.
|
||||
|
||||
````yaml
|
||||
apiVersion : kyverno.io/v1alpha1
|
||||
kind : Policy
|
||||
metadata :
|
||||
name : policy
|
||||
spec :
|
||||
|
||||
# Each policy has a list of rules applied in declaration order
|
||||
rules:
|
||||
|
||||
# Rules must have a name
|
||||
- name: "check-pod-controller-labels"
|
||||
|
||||
# Each rule matches specific resource described by "resource" field.
|
||||
resource:
|
||||
kind: Deployment, StatefulSet, DaemonSet
|
||||
# Name is optional. By default validation policy is applicable to any resource of supported kinds.
|
||||
# Name supports wildcards * and ?
|
||||
name: "*"
|
||||
# Selector is optional and can be used to match specific resources
|
||||
# Selector values support wildcards * and ?
|
||||
selector:
|
||||
# A selector can use match
|
||||
matchLabels:
|
||||
app: mongodb
|
||||
matchExpressions:
|
||||
- {key: tier, operator: In, values: [database]}
|
||||
|
||||
|
||||
# Each rule can contain a single validate, mutate, or generate directive
|
||||
...
|
||||
````
|
||||
|
||||
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](/documentation/writing-policies-validate.md)*</small>
|
||||
|
|
@ -20,12 +20,12 @@ spec :
|
|||
op: replace
|
||||
value: "nginx_is_mutated"
|
||||
validate:
|
||||
message: "The imagePullPolicy shoud set to Always"
|
||||
message: "The imagePullPolicy must be Always when :latest is used as a tag"
|
||||
pattern:
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- (name): "*"
|
||||
- (name): "*:latest"
|
||||
imagePullPolicy: Always
|
||||
|
||||
|
|
|
|||
17
examples/Validate/check_not_root.yaml
Normal file
17
examples/Validate/check_not_root.yaml
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
apiVersion : kyverno.io/v1alpha1
|
||||
kind : Policy
|
||||
metadata :
|
||||
name : check-non-root
|
||||
spec :
|
||||
rules:
|
||||
- name: check-non-root
|
||||
resource:
|
||||
kind: Deployment, StatefuleSet, DaemonSet
|
||||
validate:
|
||||
message: "Root user is not allowed"
|
||||
pattern:
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
securityContext:
|
||||
runAsNotRoot: true
|
||||
|
|
@ -1,10 +1,15 @@
|
|||
# Examples
|
||||
Examples of policies and resources with which you can play to see the kyverno in action. There are definitions for each supported resource type and an example policy for the corresponding resource.
|
||||
## How to play
|
||||
First of all, **build and install the policy controller**: see README file in the project's root.
|
||||
Each folder contains a pair of files, one of which is the definition of the resource, and the second is the definition of the policy for this resource. Let's look at an example of the endpoints mutation. Endpoints are listed in file `examples/Endpoints/endpoints.yaml`:
|
||||
# Test samples
|
||||
|
||||
```apiVersion: v1
|
||||
This directory contains policies and resources for testing. There are definitions for each supported resource type and an sample policy for the corresponding resource.
|
||||
|
||||
## How to use
|
||||
|
||||
Currently, the testing is possible only via ```kubectl``` when kyverno is installed to the cluster. So, [build and install the policy controller](/documentation/installation.md) first.
|
||||
|
||||
Each folder contains a pair of files, one of which is the definition of the resource, and the second is the definition of the policy for this resource. Let's look at an example of the endpoints mutation. Endpoints are listed in file `test/Endpoints/endpoints.yaml`:
|
||||
|
||||
````yaml
|
||||
apiVersion: v1
|
||||
kind: Endpoints
|
||||
metadata:
|
||||
name: test-endpoint
|
||||
|
|
@ -17,25 +22,25 @@ subsets:
|
|||
- name: secure-connection
|
||||
port: 443
|
||||
protocol: TCP
|
||||
```
|
||||
````
|
||||
Create this resource:
|
||||
|
||||
```
|
||||
> kubectl create -f examples/Endpoints/endpoints.yaml
|
||||
````yaml
|
||||
> kubectl create -f test/Endpoints/endpoints.yaml
|
||||
endpoints/test-endpoint created
|
||||
> kubectl get -f examples/Endpoints/endpoints.yaml
|
||||
> kubectl get -f test/Endpoints/endpoints.yaml
|
||||
NAME ENDPOINTS AGE
|
||||
test-endpoint 192.168.10.171:443 6s
|
||||
```
|
||||
````
|
||||
We just created an endpoints resource and made sure that it was created without changes. Let's remove it now and try to create it again, but with an active policy for endpoints resources.
|
||||
```
|
||||
> kubectl delete -f test/endpoints.yaml
|
||||
````bash
|
||||
> kubectl delete -f test/Endpoints/endpoints.yaml
|
||||
endpoints "test-endpoint" deleted
|
||||
```
|
||||
We have this a policy for enpoints (`examples/Endpoints/policy-endpoint.yaml`):
|
||||
````
|
||||
We have this a policy for enpoints ([policy-endpoint.yaml](/test/Endpoints/policy-endpoint.yaml)):
|
||||
|
||||
```
|
||||
apiVersion : kubepolicy.nirmata.io/v1alpha1
|
||||
````yaml
|
||||
apiVersion : kyverno.io/v1alpha1
|
||||
kind : Policy
|
||||
metadata :
|
||||
name : policy-endpoints
|
||||
|
|
@ -43,7 +48,8 @@ spec :
|
|||
rules:
|
||||
- name:
|
||||
resource:
|
||||
kind : Endpoints
|
||||
kinds:
|
||||
- Endpoints
|
||||
selector:
|
||||
matchLabels:
|
||||
label : test
|
||||
|
|
@ -61,22 +67,22 @@ spec :
|
|||
- name: load-balancer-connection
|
||||
port: 80
|
||||
protocol: UDP
|
||||
```
|
||||
````
|
||||
This policy does 2 patches:
|
||||
|
||||
- **replaces** the first port of the first connection to 6443
|
||||
- **adds** new endpoint with IP 192.168.10.171 and port 80 (UDP)
|
||||
|
||||
Let's apply this policy and create the endpoints again to see the changes:
|
||||
```
|
||||
> kubectl create -f examples/Endpoints/policy-endpoints.yaml
|
||||
````bash
|
||||
> kubectl create -f test/Endpoints/policy-endpoints.yaml
|
||||
policy.policy.nirmata.io/policy-endpoints created
|
||||
> kubectl create -f examples/Endpoints/endpoints.yaml
|
||||
> kubectl create -f test/Endpoints/endpoints.yaml
|
||||
endpoints/test-endpoint created
|
||||
> kubectl get -f examples/Endpoints/endpoints.yaml
|
||||
> kubectl get -f test/Endpoints/endpoints.yaml
|
||||
NAME ENDPOINTS AGE
|
||||
test-endpoint 192.168.10.171:80,192.168.10.171:9663 30s
|
||||
```
|
||||
````
|
||||
As you can see, the endpoints resource was created with changes: a new port 80 was added, and port 443 was changed to 6443.
|
||||
|
||||
**Enjoy :)**
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue