In some sample policies, background: false is specified even though it is not required. The following are some examples.

• https://github.com/kyverno/policies/blob/main/best-practices/restrict_image_registries/restrict_image_registries.yaml#L18
• https://github.com/kyverno/policies/blob/main/other/imagepullpolicy-always.yaml#L17
• https://github.com/kyverno/policies/blob/main/other/restrict_annotations.yaml#L18
• https://github.com/kyverno/policies/blob/main/other/restrict_controlplane_scheduling.yaml#L17
• https://github.com/kyverno/policies/blob/main/other/restrict_node_selection.yaml#L17

This is confusing and I think we should specify background: false only where necessary. Alternatively, we should explicitly specify whether the background attribute is true or false for all policies.

The Restricted profile in the Pod Security Standards requires that the Seccomp profile be specified, and does not allow it to be unspecified, but the kyverno's restrict-seccomp policy allows it to be unspecified.

See: kubernetes/kubernetes#76954

Explore options to block access to secrets within a namespace, in addition to disallowing exec (see: https://github.com/nirmata/kyverno/issues/1069).

Annotation for category is inconsistent. Some with "Best Practice" others with "Best Practices". Fix.

This policy and one of the examples, contains a resource element but not a kind attribute. Whereas it is mention in the documentation that while working with resource elements, the kind attribute is mandatory. So, I think policy needs to be updated with the kind attribute.
For confirmation, I applied this policy but it returns an error.

$ kubectl apply -f block-updates-delete.yaml
Error from server: error when creating "block-updates-delete.yaml": admission webhook "validate-policy.kyverno.svc" denied the request: At least one element must be specified in a kind block. The kind attribute is mandatory when working with the resources element

https://github.com/kyverno/policies/blob/main/other/disallow_secrets_from_env_vars.yaml

Needs rule addition to block envFrom statements.

We want to create a Kyverno policy that whitelists certain hostPath volume paths.

Therefore, we use:

    validate:
      pattern:
         =(spec):
            =(volumes):
              - (hostPath):
                =(path): "/test/path"

But, we also want to validate with this policy that all VolumeMounts that are mounted to the volumes with the /test/path path to be read-only. Is this possible in Kyverno?

Based on the documentation, it looks like this is not possible with the logic that is supported.

Whole examples used on the website could/should eventually be turned into policies and stored in this repo.

I just found out, to fulfill the policy drop-all-capabilities it is important to write ALL in upper case. all in lower case won't satisfy it.

Most documentation/blog posts (about dropping all capabilities) I googled, write:

capabilities:
  drop:
    - all

Therefore, it would be nice if either both all and ALL are valid or the message contains a corresponding hint that ALL in upper case has to be used.

Re-work to see if it can be simplified similar to the lookup here: kyverno/kyverno#2086

The precondition requires any of two opposite checks which will always be true:

any:
  - key: "{{ request.object.spec.rules[].host }}"
    operator: In
    value: "{{ hosts }}"
  - key: "{{ request.object.spec.rules[].host }}"
    operator: NotIn
    value: "{{ hosts }}"

As we have a deny rule here, the second condition is the one to be removed.

Software version numbers

Kubernetes: v1.20.8
Kyverno version: v1.4.2-rc3

Describe the bug
The resource which has multiple drop capabilities can not pass the drop-cap-net-raw policy.

To Reproduce

1. Apply drop-cap-net-raw policy

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: drop-cap-net-raw
  annotations:
    policies.kyverno.io/title: Drop CAP_NET_RAW
    policies.kyverno.io/category: Best Practices
    policies.kyverno.io/severity: medium
    policies.kyverno.io/subject: Pod
    policies.kyverno.io/description: >-
      Capabilities permit privileged actions without giving full root access. The
      CAP_NET_RAW capability, enabled by default, allows processes in a container to
      forge packets and bind to any interface potentially leading to MitM attacks.
      This policy ensures that all containers explicitly drop the CAP_NET_RAW
      ability.
spec:
  validationFailureAction: enforce
  rules:
  - name: drop-cap-net-raw
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "The capability CAP_NET_RAW must be explicitly dropped."
      pattern:
        spec:
          containers:
          - securityContext:
              capabilities:
                drop: ["NET_RAW"]
          =(initContainers):
          - securityContext:
              capabilities:
                drop: ["NET_RAW"]

2. Apply the following resource

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: test
    image: debian:9
    command: ["/bin/sh", "-c", "sleep infinity"]
    securityContext:
      capabilities:
        drop:
        - NET_RAW
        - SETUID

Expected behavior
Resource Pod/default/test created successfully.

Actual behavior
Resource Pod/default/test was blocked due to the drop-cap-net-raw policy.

It would be great if we could have configuration/policy files that were used in the lightning demo - https://www.youtube.com/watch?v=f3LBwIMk0Zs

This would enable folks to try out Kyverno with an HNC usecase.

While using https://kyverno.io/policies/other/block_updates_deletes/?policytypes=RBAC policy, getting this error.

error: error validating "kubernetes-infra/kyverno/policies/block-delete.yaml": error validating data: ValidationError(ClusterPolicy.spec.rules[0].match.resources): unknown field "kind" in io.kyverno.v1.ClusterPolicy.spec.rules.match.resources; if you choose to ignore these errors, turn validation off with --validate=false

Kyverno version: 1.4.2

In the current scenario, there are many sample policies which requires to add test.yaml and resource.yaml for each of them in a separate folder under other repo only.

https://neonmirrors.net/post/2021-01/kyverno-the-swiss-army-knife-of-kubernetes/#resource-padlock

https://neonmirrors.net/post/2021-01/kyverno-the-swiss-army-knife-of-kubernetes/#secret-copiersyncher

The policy pod-security/baseline/disallow-adding-capabilities contradicts best-practices/require_drop_all.

When I implement require_drop_all, which seems reasonable too, of course I must add the capabilities, that are still required, for example NET_BIND_SERVICE.

I've installed Kyverno via Helm Chart and actually I'd like to keep at least the baseline policies. However, the policy in this form is too strict. The rule should only trigger, if add does include capabilities, which are not part of the default set.

See also https://kubernetes.io/docs/concepts/security/pod-security-standards/

Adding additional capabilities beyond those listed below must be disallowed.
Allowed Values

Undefined/nil
AUDIT_WRITE
CHOWN
DAC_OVERRIDE
FOWNER
FSETID
KILL
MKNOD
NET_BIND_SERVICE
SETFCAP
SETGID
SETPCAP
SETUID
SYS_CHROOT

Additionally it seems the rule missed ephemeralContainers

Move remaining sample policies (from https://github.com/kyverno/kyverno/blob/main/samples/README.md) to new repo.

Any idea , where can we find the policies related/similar to the below rules:

1. Ensure that the cluster-admin role is only used where required
2. Minimize wildcards use in roles and clusterroles

I wanted to have a policy for 3. Minimize access to create pods , for which I could tweak this:
https://kyverno.io/policies/other/block_updates_deletes/

But could not find policies/related to 1 & 2. Any leads would be helpful.

Thanks in advance.

This was renamed at: https://kubernetes.io/docs/concepts/security/pod-security-standards/

The disallow-adding-capabilities policy uses null instead of "null". Because of this, it doesn't actually enforce disallowing adding capabilities and instead I was able to add NET_ADMIN like so:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: add-caps
spec:
  selector:
    matchLabels:
      app: add-caps
  template:
    metadata:
      labels:
        app: add-caps
    spec:
      containers:
      - name: add-caps
        image: redis
        securityContext:
          capabilities:
            add:
              - "NET_ADMIN"

Once I fixed the policy to "null" the property was correctly enforced.

When set to null and applied, you can note that the rendered pattern spec is:

spec:
  rules:
  - name: capabilities
    validate:
      ...
      pattern:
        spec:
          =(initContainers):
          - =(securityContext):
              =(capabilities): {}
          containers:
          - =(securityContext):
              =(capabilities): {}

See: https://twitter.com/mrgcastle/status/1396108915109101575

Per this discussion.

https://kyverno.io/policies/pod-security/restricted/require-non-root-groups/require-non-root-groups/

Policies using apiCall in their context might not work with every Kubernetes version, e.g. unique-ingress-host policy uses urlPath "/apis/networking.k8s.io/v1/ingresses" which is available since Kubernetes 1.19 and will not work for versions before.

A policy classification annotation would help to make this clear explicitly.

After upgrading from 1.3.6 to 1.4.2, this policy starts again firing alert for CronJobs / Jobs (pods created by them). Applied last CRDs, undeployed Kyverno, cleaned up all crds and policies, installed cleanly, still same issue.
Kubernetes EKS 1.21.

See example at: kyverno/kyverno#1750 (comment)

While working on kyverno/kyverno#1866 I noticed the following when Kyverno main repo runs the test subcommand:

Executing drop-all-capabilities...
applying 1 policy to 1 resource... 
│───│───────────────────────────────────────────────────────────────────│────────│
│ # │ TEST                                                              │ RESULT │
│───│───────────────────────────────────────────────────────────────────│────────│
│ 1 │ add-capabilities with drop-all-capabilities/check-init-containers │ Fail   │
│───│───────────────────────────────────────────────────────────────────│────────│

I do not know if this is an issue with the policy, policy test or with Kyverno.

See:

https://www.youtube.com/watch?v=6rMGRvcjvKc

The attack could have been prevented, if the node authorizer blocked all calls to Nodes resource on the K8s API. I don't see any reason to allow node delete/create, when updates to Node taints are being blocked.
It seems the security rules are setup conveniently for the demo scenario to work.

See: https://kubernetes.slack.com/archives/C8P1DRTJA/p1626520243195800

Anyone know of a mutating webhook that will inject default security contexts into a pod? Ie if you don't specify a runas it creates it for you? Something similar to how openshift mutates pods

A Kyverno policy can check of runAs and other securityContext attributes like runAsNonRoot are specified and automatically inject them if needed.

Policies are hit or miss with respect to explaining why it's useful. They explain what it does, but descriptions could do both to help users better.

The policy is not working as it suppose to work.
It's due to absence of conditional anchors in fields spec and volumes.

Create a sample policy covering a simple mutation example for adding a label to incoming objects. Although simple, this is a very common request in the community and is a nice introduction to mutations.

Create a sample policy that enforces all images should use checksums instead of tags.

See: https://www.reddit.com/r/kubernetes/comments/mtucy4/53_kyverno_policies_including_pod_security/

See: https://threatpost.com/azurescape-kubernetes-attack-container-cloud-compromise/169319/

Some ideas to explore:

1. Require BoundServiceAccountTokenVolume

2. Deploy policy enforcers to monitor and prevent suspicious activity within clusters, especially service accounts or nodes that query the SelfSubjectAccessReview or SelfSubjectRulesReview APIs for their permissions.

See: https://kubernetes.slack.com/archives/CLGR9BJU9/p1622749892231800?thread_ts=1622729028.223700&cid=CLGR9BJU9

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-secrets
spec:
  validationFailureAction: enforce
  rules:
  - name: check-for-image-pull-secrets
    match:
      resources:
        kinds:
        - Pod
    preconditions:
    - key: "{{ images.containers.*.registry }}"
      operator: NotIn
      value:
      - ghcr.io
      - quay.io
    validate:
      message: "The array `imagePullSecret` is required."
      pattern:
        spec:
          imagePullSecrets:
          - name: "?*"

would be good to allow multiple success and failure cases and automate execution.

Hi,

Do we really need the rule require-namespace in the policy https://github.com/kyverno/policies/blob/main/best-practices/disallow_default_namespace/disallow_default_namespace.yaml?

I expected the below pod to fail the rule but that is not the case.

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-namespace
  labels:
    app: myapp
spec: 
  containers:
  - name: nginx
    image: nginx

Is the rule indeed not working as expected or is my understanding wrong here?

Regards,
Shilpa

We need to update test.yaml to cover this change #57.

I'd like to have a policy that checks for a match between resource requests and limits. Since there doesn't appear to be any kind of == operator, I tried making use of variables like so:

            containers:
              - resources:
                  requests:
                    memory: "?*"
                  limits:
                    memory: "$(./../../requests/memory)"

To my surprise though, my newly created pod (with non-matching memory requests/limits) passed validation. I suspect the variable is not interpolating what was set for requests.memory and is just using "?*". Am I thinking about this correctly? Is there another method I can use to evaluate?

Hi!

In this example:
https://github.com/kyverno/policies/blob/main/pod-security/restricted/restrict-volume-types/restrict-volume-types.yaml
a huge list of NOT allowed volume types described.

I'm stuck trying to describe a list of ONLY allowed volume types using available anchors and operators of kyverno.
I need to write a rule that reads like:
"If a volume is defined then the type of it can ONLY be configMap or emptyDir or persistentVolumeClaim or ..."
This makes rule definition shorter and prevents of not wanted allow of newly added types in future.

Can anyone help?

see: https://kubernetes.slack.com/archives/CLGR9BJU9/p1628006140065200

Add the policy mentioned here in the sample policies and website as an example of regex_replace_all.

Need to standardize on how to write policies in the most simple and efficient manner possible. This is not only to reduce complexity but to be effective teaching aids for new users. The following are examples of how to do this:

• Remove double quotes from strings
• Remove name: "*" items from rules when not needed
• Minimize indentation of dictionary keys

See: https://twitter.com/Marcus_Noble_/status/1417007780888825856

Kubernetes v1.22 removes a number of deprecated APIs. The policy would check for those apiVersions and kinds and block / report their usage.

Kyverno version

• Kubernetes version: v1.18.6
• Kyverno version: v1.3.3

Describe the issue
Policy drop-all-capabilities would report violation on initContainer even initContainer not exist in the yaml

  - category: Best Practices
    message: 'validation error: All capabilities should be dropped with only those
      required added back. Rule autogen-check-init-containers failed at path /spec/template/spec/initContainers/'
    policy: drop-all-capabilities
    resources:
    - apiVersion: apps/v1
      kind: Deployment
      name: velero
      namespace: velero
      uid: 674e0e3c-a087-406b-a90c-12c45ffcd248
    rule: autogen-check-init-containers
    scored: true
    status: fail

Expected behavior
If initContainer is not configured, then no policy violation should be reported on that.

Additional context
Here's the velero deployment resource yaml. Only container but no initContainer in the resource.
Policy violation of same policy has reported on container as well, which is expected.

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2020-12-23T03:06:24Z"
  generation: 1
  labels:
    app.kubernetes.io/component: deployment.velero
    app.kubernetes.io/instance: velero-aws
    app.kubernetes.io/name: velero-aws
  name: velero
  namespace: velero
  resourceVersion: "922407"
  selfLink: /apis/apps/v1/namespaces/velero/deployments/velero
  uid: 674e0e3c-a087-406b-a90c-12c45ffcd248
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app.kubernetes.io/component: deployment.velero
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      annotations:
        prometheus.io/path: /metrics
        prometheus.io/port: "8085"
        prometheus.io/scrape: "true"
      creationTimestamp: null
      labels:
        app.kubernetes.io/component: deployment.velero
        app.kubernetes.io/instance: velero-aws
        app.kubernetes.io/name: velero-aws
        component: velero
        nirmata.io/application.addon.type: Other
        nirmata.io/application.type: cluster-addon
    spec:
      containers:
      - args:
        - server
        command:
        - /velero
        env:
        - name: AWS_SHARED_CREDENTIALS_FILE
          value: /credentials/cloud
        - name: VELERO_SCRATCH_DIR
          value: /scratch
        image: gcr.io/heptio-images/velero:v1.0.0
        imagePullPolicy: IfNotPresent
        name: velero
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /credentials
          name: cloud-credentials
        - mountPath: /plugins
          name: plugins
        - mountPath: /scratch
          name: scratch
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      serviceAccount: velero
      serviceAccountName: velero
      terminationGracePeriodSeconds: 30
      volumes:
      - name: cloud-credentials
        secret:
          defaultMode: 420
          secretName: cloud-credentials
      - emptyDir: {}
        name: plugins
      - emptyDir: {}
        name: scratch

https://kyverno.io/policies/other/restrict_controlplane_scheduling/

Additional taint (1.20+) should be node-role.kubernetes.io/control-plane

Need a GitHub action for this repo which:

1. Detects commits to kyverno/policies
2. Runs the render program on kyverno/website
3. Generates the new Markdown files
4. Pushes those to kyverno/website in /content/en/policies (should wipe contents first!)

Need to handle other files in /content/en/policies to account for tests and kustomize manifests.

Is your feature request related to a problem? Please describe current state:
The repository does not have a contributor appreciation automation.

Describe the solution you'd like:
Integrate the behaviour bot from Github Apps into the repository.

Describe alternatives you've considered:
No alternative for now.

Screenshots

Contributor Resources

• Contributing Guidelines