kubewarden / capabilities-psp-policy Goto Github PK

Update the policy from targeting Pod resource to target higher level objects like deployments. This is a better practice because we prevent the resources to be created instead of failing in the deployment phase when the pods are created.

We changed the way mutated objects are sent back to the policy-server. This breaks this policy's ability to mutate requests once a new version of the policy server is released.

A simple rebuild of the policy and release will fix it, but we have to wait for a new version of the policy-server to be tagged

Ephemeral containers also have a spec.securityContext, hence we can set capabilities for them (and an attacker can use it for privilege escalation). This policy predates their inclusion in Kubernetes, and this policy mirrors the analogous capabilities PSP, which also predates their inclusion in Kubernetes. The PSP was never updated because as it was deprecated instead.
This doesn't mean we shouldn't check ephemeral containers too.

Acceptance criteria

Validate ephemeral containers too.

Add workflow to test the policy in a actual cluster running Kubewarden.

This has been created to address the testing architecture RFC requirements

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Acceptance criteria

Add a new make e2e-tests that runs end-to-end tests for the policy locally, using already an present kwctl binary.
Write e2e tests for the "Examples" cases listed in the readme.
Come up with more e2e tests if needed.

Notes

Note that the e2e tests for the policy are not run against a real cluster, but run with kwctl run, which simulates what would happen in a cluster.

One needs the json requests of the operations against the cluster (e.g: a CREATE of a Pod). These requests are what the k8s admission & mutation controller would receive. Kubewarden controller is registered with a webhook into the admission & mutation, so Kubewarden controller receives those requests, passes them to the policy, and depending if the policy accepts, rejects or mutates the request, the Kubewarden controller will forward the request to the kubernetes API for it to be taken into effect (e.g: the creation of the pod).

Once one has those json requests, one can use kwctl run to run them locally and outside of the cluster. This is how the e2e tests get run.

For obtaining the json requests, one craft them manually (from other requests saved in other policy e2e tests for example). Another option is to run the Echo policy in a real cluster, and save the requests from its logs.

For examples and inspiration, see the end to end tests of other policies. Example:

• e2e.bats: https://github.com/kubewarden/verify-image-signatures/blob/main/e2e.bats
• test-data folder: https://github.com/kubewarden/verify-image-signatures/tree/main/test_data
• make e2e-tests: https://github.com/kubewarden/verify-image-signatures/blob/8226a65e23044b2a67b4829af7b529d653f4aab8/Makefile#L23-L25

The Wasm file containing the policy must be enriched with metadata.

This is just an example of the metadata.yaml file:

rules:
- apiGroups: [""]
  apiVersions: ["v1"]
  resources: ["pods"]
  operations: ["CREATE", "UPDATE"]
mutating: false
labels:
  production: false
annotations:
  name.castelli.hello: world
  io.kubewarden.policy.title: psp-apparmor
  io.kubewarden.policy.description: Replacement for the Kubernetes Pod Security Policy that controls the usage of AppArmor profiles
  io.kubewarden.policy.author: Flavio Castelli
  io.kubewarden.policy.url: https://github.com/kubewarden/psp-apparmor
  io.kubewarden.policy.source: https://github.com/kubewarden/psp-apparmor
  io.kubewarden.policy.license: Apache-2.0
  io.kubewarden.policy.usage: |
    This policy works by defining a whitelist of allowed AppArmor profiles. Pods are then inspected at creation and update time, to ensure only approved profiles are used.

    When no AppArmor profile is defined, Kubernetes will leave the final choice to the underlying container runtime. This will result in using the default AppArmor profile provided by Container Runtime. Because of that, the default behaviour of this policy is to accept workloads that do not have an AppArmor profile specified.

    The policy can be configured with the following data structure:
    ```yaml
    # list of allowed profiles
    allowed_profiles:
    - runtime/default
    - localhost/my-special-workload
    ```