Issue Description

Background

The Proposal(Using Kyverno to support container runtime neutrally) was discussed at an community meeting on November 16, 2022. This proposal introduces Kubernetes Pod Policy and compares Pod Security Admission, Gatekeeper, and Kyverno, and finally determines that Kyverno can be used to implement image policy.

After the meeting, we also verified whether Kyverno supports k0s/k3s, it works well.

Implementation details

Kyverno dynamically adds Webhook by creating Policy, which can help us implement Image policy. So in fact, in terms of implementation details, we need to pay attention to two aspects:

1. Policy
2. Kyverno

About Policy

Format of policy configuration file

The picture above shows Kyverno’s Policy rules, we can use Namespaces, Resource Kinds and Resource Names to match the corresponding Pod.

We may need to build a user-friendly Policy configuration file, and the sealer can create a corresponding Policy based on this configuration file. And maybe through this configuration file, we can do the function of getting the mirror list together. @starnop

{
  "application-list":[
    {
      "resourceKind": "deployment",
      "resourceName": "nginx-deployment",
      "namespace": "default",
      "image": "nginx:1.14.2"
    },
    ...
  ]
}

How to get the information needed to create a policy

During the build phase, sealer will cache all container images required by the cluster in the local private registry.

We can extract the application list that needs to be matched by the image policy along the way during the build process.

Where to store policy configuration file

There are currently two options, @kakaZhou719:

1. basefs
2. imagespec

When is the Policy created?

Since the container at the K8s layer does not require webhook to intercept, it is sufficient to create a Policy before the container at the application layer is launched.

About Kyverno

Whether to install Kyverno

In a proprietary cloud delivery scenario, the cluster network is isolated from the outside world, so we need to cache container images to a local private repository during the build phase and pull images from the private repository uniformly when the cluster starts.

But in some case, users want to not save the container image during the build process. For example, when the cluster network is not isolated from the outside world.

So we could perhaps set up two different build modes (online and offline) during the build phase and install Kyverno in offline mode only.

When is the Kyverno installed

Based on the role Kyverno needs to play, an obvious choice would be to make it part of the base and activate it along with the base.

Type: feature request

Describe what feature you want

Additional context

taskList:

• Need to implement build mode to control whether container images are saved in the Sealer Image.
• Implementing the logic for parsing and saving the image list
• API definition, including determining whether a Sealer Image contains container images and getting the image list in the Sealer Image.
• Implementation of the management of the kyverno image policy according to the image list.