mirrors/kyverno
mirrors/kyverno
1
0
Fork 0
mirror of https://github.com/kyverno/kyverno.git synced 2025-03-28 18:38:40 +00:00
Code Activity

Updated readme.md and user facing files

Browse source
This commit is contained in:
Anton Kostenko 2019-06-21 15:36:31 +03:00
parent 4cc4ef7cee
commit c70484090f
3 changed files with 34 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
README.md
View file

@ -10,13 +10,13 @@ Kubernetes supports declarative management of objects using configurations writt
Kyverno allows cluster adminstrators to manage environment specific configurations independently of workload configurations and enforce configuration best practices for their clusters.
Kyverno policies are Kubernetes resources that can be written in YAML or JSON. Kyverno policies can validate, mutate, and generate any Kubernetes resources.
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 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.
Mutating policies can be written as overlays (similar to [Kustomize](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#bases-and-overlays)) or as a [JSON Patch](http://jsonpatch.com/). Validating policies also use an overlay style syntax, with support for pattern matching and conditional (if-then-else) processing.
Mutating policies can be written as overlays (similar to [Kustomize](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#bases-and-overlays)) or as a [JSON Patch](http://jsonpatch.com/). Validating policies also use an overlay style syntax, with support for pattern matching and conditional (if-then-else) processing.
Policy enforcement is captured using Kubernetes events. Kyverno also reports policy violations for existing resources.
@ -46,8 +46,8 @@ spec:
- name: "*"
resources:
limits:
# '?' requires 1 alphanumeric character and '*' means that there can be 0 or more characters.
# Using them togther e.g. '?*' requires at least one character.
# '?' requires 1 alphanumeric character and '*' means that there can be 0 or more characters.
# Using them together e.g. '?*' requires at least one character.
memory: "?*"
cpu: "?*"
requests:
@ -100,7 +100,7 @@ spec:
selector:
matchExpressions:
- {key: kafka, operator: Exists}
generate:
generate:
kind: ConfigMap
name: zk-kafka-address
data:
@ -126,11 +126,11 @@ Additional examples are available in [examples](/examples).
### 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.
[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.
### Polaris
[Polaris](https://github.com/reactiveops/polaris) validates configurations for best practices. It includes several checks across health, networking, security, etc. Checks can be assigned a severity. A dashboard reports the overall score.
[Polaris](https://github.com/reactiveops/polaris) validates configurations for best practices. It includes several checks across health, networking, security, etc. Checks can be assigned a severity. A dashboard reports the overall score.
### External configuration management tools
@ -166,7 +166,6 @@ Here are some the major features we plan on completing before a 1.0 release:
Welcome to our community and thanks for contributing!
* Please review and agree to abide with the [Code of Conduct](/CODE_OF_CONDUCT.md) before contributing.
* Please review and agree to abide with the [Code of Conduct](/CODE_OF_CONDUCT.md) before contributing.
* See the [Wiki](https://github.com/nirmata/kyverno/wiki) for developer documentation.
* Browse through the [open issues](https://github.com/nirmata/kyverno/issues)

42
documentation/writing-policies-mutate.md
View file

@ -1,6 +1,6 @@
<small>*[documentation](/README.md#documentation) / [Writing Policies](/documentation/writing-policies.md) / Mutate*</small>
# Mutate Configurations
# Mutate Configurations
The ```mutate``` rule contains actions that will be applied to matching resource before their creation. A mutate rule can be written as a JSON Patch or as an overlay. By using a ```patch``` in the (JSONPatch - RFC 6902)[http://jsonpatch.com/] format, you can make precise changes to the resource being created. Using an ```overlay``` is convenient for describing the desired state of the resource.
@ -47,7 +47,8 @@ spec :
rules:
- name: "Remove unwanted label"
resource:
kind: Secret
kinds:
- Secret
mutate:
patches:
- path: "/metadata/labels/purpose"
@ -71,7 +72,8 @@ spec :
rules:
- name: "Set hard memory limit to 2Gi"
resource:
kind: Pod
kinds:
- Pod
selector:
matchLabels:
memory: high
@ -80,7 +82,7 @@ spec :
spec:
containers:
# the wildcard * will match all containers in the list
- name: *
- (name): "*"
resources:
requests:
memory: "10Gi"
@ -91,40 +93,44 @@ spec :
### Working with lists
Applying overlays to a list type without is fairly straightforward: new items will be added to the list, unless they already ecist. For example, the next overlay will add IP "192.168.10.172" to all addresses in all Endpoints:
Applying overlays to a list type without is fairly straightforward: new items will be added to the list, unless they already exist. For example, the next overlay will add IP "192.168.10.172" to all addresses in all Endpoints:
````yaml
apiVersion: policy.nirmata.io/v1alpha1
apiVersion: kyverno.io/v1alpha1
kind: Policy
metadata:
name: policy-endpoints
spec:
rules:
- resource:
kind : Endpoints
- name: "Add IP to subsets"
resource:
kinds :
- Endpoints
mutate:
overlay:
subsets:
- addresses:
- ip: 192.168.10.172
- ip: 192.168.42.172
````
### Conditional logic using anchors
An **anchor** field, marked by parentheses, allows conditional processing of configurations. Processing stops when the anchor value does not match. Once processing stops, any child elements or any remaining siblings in a list, will not be processed.
An **anchor** field, marked by parentheses, allows conditional processing of configurations. Processing stops when the anchor value does not match. Once processing stops, any child elements or any remaining siblings in a list, will not be processed.
For example, this overlay will add or replace the value 6443 for the port field, for all ports with a name value that starts with "secure":
````yaml
apiVersion : policy.nirmata.io/v1alpha1
apiVersion: kyverno.io/v1alpha1
kind : Policy
metadata :
name : policy-set-port
spec :
rules:
- resource:
kind : Endpoints
- name: "Set port"
resource:
kinds :
- Endpoints
mutate:
overlay:
subsets:
@ -145,18 +151,20 @@ A variation of an anchor, is to add a field value if it is not already defined.
For example, this overlay will set the port to 6443, if a port is not already defined:
````yaml
apiVersion : policy.nirmata.io/v1alpha1
apiVersion: kyverno.io/v1alpha1
kind : Policy
metadata :
name : policy-set-port
spec :
rules:
- resource:
kind : Endpoints
- name: "Set port"
resource:
kinds :
- Endpoints
mutate:
overlay:
subsets:
- ports:
- (ports):
+(port): 6443
````

2
test/README.md
View file

@ -46,7 +46,7 @@ metadata :
name : policy-endpoints
spec :
rules:
- name:
- name: ""
resource:
kinds:
- Endpoints