community
community copied to clipboard
Add proposal for image conversion service
@ktock Please see if the proposal makes sense for stargz
Could you elaborate how does end user map the converted image to the original one?
I assume the converted image can't be recognized by the scanner, and cannot be signed? How do we ensure the project level policies are enforced to converted images such that vulnerable ones are blocked?
IMO, this is more important than inter-op between Harbor and the ICS.
Could you elaborate how does end user map the converted image to the original one?
I assume the converted image can't be recognized by the scanner, and cannot be signed? How do we ensure the project level policies are enforced to converted images such that vulnerable ones are blocked?
IMO, this is more important than inter-op between Harbor and the ICS.
@reasonerjt We can configure the target_suffix or multi_platform option to specify what the reference of converted image will look like. The converted image is still OCI compatible and can be signed, but the scanner may not be able to unpack and scan the contents of converted image, should we assume that the converted image is trusted after the original image has been certified by the scanner?
We can configure the target_suffix or multi_platform option to specify what the reference of converted image will look like.
By reference do you mean tag?
should we assume that the converted image is trusted after the original image has been certified by the scanner?
I think if the relationship can be enforced then yes, using tag or something that can be easily modified is not very reliable.
@reasonerjt Yes, means tag in target_suffix. how about merging the original image and the converted image into a manifest index like this.
There may be race condition when 2 convertors try to modify the same index.json? Or do you mean each convertor will create one separate index.json? Since it's a converted image and it's an OCI artifact, how about adding it into manifest?
@reasonerjt Maybe we can design a workflow to avoid the race condition situation, for example, we can put the conversion job into a FIFO queue by repo level, the previous job will be canceled once has a new job be submitted in the same repo.
In addition, an annotation can be added to the converted image to record the digest of original image, which the ICS or user can check to decide whether to push or use the converted image.
I think if the relationship can be enforced then yes, using
tagor something that can be easily modified is not very reliable.
@reasonerjt
There is an on-going artifact pr 29 which adds a new artifact manifest, it represents two things, a) a new artifact, b) the relationship between the artifact and the existing image or artifact (via subjectManifest).
{
"schemaVersion": 3,
"mediaType": "application/vnd.oci.artifact.manifest.v1-rc1+json",
"referenceType": "cncf.nydus.v1-rc1",
"blobs": [
{
"mediaType": "application/vnd.cncf.nydus.bootstrap.v1.tar+gzip",
"digest": "sha256:f6bb0822fe567c98959bb87aa316a565eb1ae059c46fa8bba65b573b4489b44d",
"size": 32654
},
{
"mediaType": "application/vnd.cncf.nydus.blob.v1",
"digest": "sha256:d35808e58856ef91d07dedf94b93301b6efdfcc831477d3b1bb37e6c3e19cce6",
"size": 25851449
},
{
"mediaType": "application/vnd.cncf.nydus.blob.v1",
"digest": "sha256:dbad66bcfe29ef383157a3e122acbd08cd2ebd40f5658afa2ae62c52ffe26e9f",
"size": 226
}
],
"subjectManifest": {
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"digest": "sha256:73c803930ea3ba1e54bc25c2bdc53edd0284c62ed651fe7b00369da519a3c333",
"size": 16724
},
"annotations": {
"org.cncf.nydus.v1.author": "wabbit-networks.io"
}
}
There is an on-going artifact pr 29 which adds a new artifact manifest, it represents two things, a) a new artifact, b) the relationship between the artifact and the existing image or artifact (via subjectManifest).
@liubogithub @reasonerjt This also looks good. How to avoid inconsistency between the original and converted image is a good question, and I've added it to the end of the proposal. It'd be a pleasure for us to discuss this in the image acceleration working group.
We close for now, this proposal for now. Due to the current lack of interest from the community. However, this decision does not prevent the possibility of revisiting your proposal in the future, should the situation change.