: Sorry for the late reply.

nice job 👍

And there are some suggestions for your reference:

1. Cloud you please provide a diagram with a description to explain how to use kyvernno in the lifecycle of sealer, such as sealer build --type=app-installer will package the kyvernno, sealer run {{appImage}} will install the kyvernno if not exist, etc? It would help if you tried to answer these questions:

   1.0 the side effects of the sealer that the kyvernno will cause, such as how much the app's package size will increase
   1.1 how to store and read the image list, @kakaZhou719
   1.2when to package kyvernno and where the kyvernno will locate at
   1.3 when and how to install/uninstall kyvernno
   1.4 when to generate(add/update/delete) Kyverno’s Policy rules and where to store the policy rules
   1.5 when and how to policy the image
   1.6 ......

2. Maybe an image list is enough for generate Kyverno’s Policy rules, we can policy all images in the list to sealer registry domain in the offline mode. So the definition of a image list can be straightforward just like the following:

[
  {
    "image": "nginx:1.14.2"
  },
  {
    "image": "nginx:1.14.2"
    "appName": "app1",
  },
  {
    "image": "image:tag",
    "appName": "app1",
    "resourceKind": "deployment",
    "resourceName": "nginx-deployment",
    "namespace": "default"
  }
]

@YTGhost Any update?

1. These two diagram to explain how to use kyverno in the lifecycle of sealer:

2. Based on the previous description of Kyverno's Policy rules, I think that resourceKind, resourceName and namespace are the necessary information for kyverno to uniquely identify the resources to which the image policy needs to be applied. So the definition of a image list will just like this:

[
  {
    "image": "image:tag",
    "appName": "app1",
    "resourceKind": "deployment",
    "resourceName": "nginx-deployment",
    "namespace": "default"
  },
  ...
]

I think that resourceKind, resourceName and namespace are the necessary information for kyverno to uniquely identify the resources to which the image policy needs to be applied.

In fact, you only need to mutate the image for the pod resources

I think that resourceKind, resourceName and namespace are the necessary information for kyverno to uniquely identify the resources to which the image policy needs to be applied.

In fact, you only need to mutate the image for the pod resources

Yes, after some research, kyverno supports the use of regex in policies to replace them, as shown in this example: https://kyverno.io/policies/other/replace_image_registry/replace_image_registry/. So in the image list, we can replace the image according to its name

well done, and then cloud you please submit a to-do list so we progress to implementation in an orderly manner?

attention: We don't have the command "run app" anymore, and it is unified into the "run" command

I think the implementation of this feature can be split into the following subtasks, @starnop WDYT:

• sealer build support online and offline build modes. When using online build mode, sealer will not save the container image during the build process, and at this point kyverno does not need to be installed.
• Get the image list during the parse phase, and save it into basefs.
• During the build and package phase, kyverno is packaged as part of the base or another build-in app, which depends on the --type of sealer build.(Note: If the build mode is online, there is no need to package kyverno)
• sealer run support launch kyverno and create image policy(Note: If you are running ClusterImage built in online mode, you do not need to start Kyverno. If you are running an application image, you also need to pay attention to whether kyverno already exists in the environment)

great job! And I have a few minor suggestions.

1. In fact, especially when collaboration is required, the API of the partnership should be the first priority, so that each collaborator can work on the API in parallel. For the current problem, I think one important API should be the storage and retrieval of the image list of Sealer Image. That way, some people can just focus on that how to package kyverno and run kyverno and manage the kyverno image policy according to the image list, and others just need to focus on that make sure that API can get the correct image list of Sealer Image.
2. I am thinking of whether we need to deal with the issue of whether kyverno needs to be installed or not with build mode. This can be decided by the user who defines the app image. We only need to provide an app or a base Sealer Image and the corresponding guidance documents. After that, we just need to implement how to manage the kyverno image policy according to the image list.

BTW, the API related to the image list can be left to me to deal with.

Supplement:

Whether to save the container images through the build mode should be necessary. And the kyverno image policy management also depends on the API that whether the Sealer Image contains the containers images.