1
0
Fork 0
mirror of https://github.com/kyverno/kyverno.git synced 2024-12-15 17:51:20 +00:00
Cloud Native Policy Management
Find a file
2019-08-13 11:32:12 -07:00
.github add template for bug & feature request 2019-07-05 11:43:06 -07:00
cmd/kyverno change logger to glog 2019-06-03 17:54:19 -07:00
definitions update testing v1 2019-08-12 10:02:07 -07:00
documentation move pull request template file 2019-06-24 12:46:59 -07:00
examples test yamls 2019-08-08 15:30:44 -07:00
gh-pages update static page text 2019-06-16 21:34:57 -07:00
pkg add process existing for mutation & validation + come cleanup 2019-08-13 11:32:12 -07:00
scripts policyviolation, policy controller reconciliation 2019-08-07 16:14:33 -07:00
test cleanup example folder 2019-07-29 19:01:17 -07:00
vendor correct unit tests 2019-06-28 17:11:19 -07:00
.directory Implemented validation across same yaml 2019-06-20 18:21:55 +03:00
.gitignore 127: Implemented usage of result package in validation and mutation functions. 2019-06-05 13:43:07 +03:00
.travis.yml unit test after build & add travis_terminate 1 2019-06-07 13:13:11 -07:00
CODE_OF_CONDUCT.md add code of conduct & contributing section 2019-06-12 09:39:37 -07:00
CONTRIBUTING.md Create CONTRIBUTING.md 2019-06-22 14:44:37 -07:00
Dockerfile - add Makefile 2019-05-22 21:41:24 -07:00
Gopkg.toml Support Mutate from command line 2019-05-20 13:02:55 -07:00
init.go Allow user to run Kyverno in debug mode 2019-06-10 18:10:51 -07:00
LICENSE Create LICENSE 2019-06-05 23:00:32 -04:00
main.go increase resync time 2019-08-12 10:51:17 -07:00
Makefile initial targets for unit test and code coverage 2019-06-07 11:50:12 -07:00
README.md Update README.md 2019-07-23 12:25:54 -07:00

Kyverno - Kubernetes Native Policy Management

Build Status Go Report Card

logo

Kyverno is a policy engine designed for Kubernetes.

Kubernetes supports declarative management of objects using configurations written in YAML or JSON. Often, parts of the configuration will need to vary based on the runtime environment. For portability, and for separation of concerns, its best to maintain environment specific configurations separately from workload configurations.

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 runs as a dynamic admission controller 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) or as a JSON Patch. 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.

Examples

1. Validating resources

This policy requires that all pods have CPU and memory resource requests and limits:

apiVersion: kyverno.io/v1alpha1
kind: Policy
metadata:
  name: check-cpu-memory
spec:
  rules:
  - name: check-pod-resources
    resource:
      kinds:
      - Pod
    validate:
      message: "CPU and memory resource requests and limits are required"
      pattern:
        spec:
          containers:
          # 'name: *' selects all containers in the pod
          - name: "*"
            resources:
              limits:
                # '?' 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:
                memory: "?*"
                cpu: "?*"

2. Mutating resources

This policy sets the imagePullPolicy to Always if the image tag is latest:

apiVersion: kyverno.io/v1alpha1
kind: Policy
metadata:
  name: set-image-pull-policy
spec:
  rules:
  - name: set-image-pull-policy
    resource:
      kinds:
      - Deployment
    mutate:
      overlay:
        spec:
          template:
            spec:
              containers:
                # match images which end with :latest   
                - (image): "*:latest"
                  # set the imagePullPolicy to "Always"
                  imagePullPolicy: "Always"

3. Generating resources

This policy sets the Zookeeper and Kafka connection strings for all namespaces with a label key 'kafka'.

apiVersion: kyverno.io/v1alpha1
kind: Policy
metadata:
  name: "zk-kafka-address"
spec:
  rules:
  - name: "zk-kafka-address"
    resource:
      kinds:
        - Namespace
      selector:
        matchExpressions:
        - {key: kafka, operator: Exists}
    generate:
      kind: ConfigMap
      name: zk-kafka-address
      data:
        kind: ConfigMap
        data:
          ZK_ADDRESS: "192.168.10.10:2181,192.168.10.11:2181,192.168.10.12:2181"
          KAFKA_ADDRESS: "192.168.10.13:9092,192.168.10.14:9092,192.168.10.15:9092"

4. More examples

Additional examples are available in examples.

License

Apache License 2.0

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.

Alternatives

Open Policy Agent

Open Policy Agent (OPA) 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 a custom query language.

Polaris

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

Tools like 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.

Documentation

Roadmap

Here are some the major features we plan on completing before a 1.0 release:

Getting help

Contributing

Welcome to our community and thanks for contributing!

  • Please review and agree to abide with the Code of Conduct before contributing.
  • See the Wiki for developer documentation.
  • Browse through the open issues