Modify security design document #6
Conversation
docs/ccv1_image_security_design.md
Outdated
| The container image signing mechanism used by the image-rs of confidential containers V1 | ||
| is consistent with the signing mechanism used in [containers/image](https://github.com/containers/image). | ||
| At present, the only supported cryptographic signature format in this mechanism is OpenPGP([RFC 4880](https://datatracker.ietf.org/doc/html/rfc4880#section-5.4)). | ||
| There are multiple image signing and verification protocols/solutions available now, |
There was a problem hiding this comment.
There are multiple image signing and verification protocols/solutions in the field, so an extensible modular architecture should be implemented to support them.
There was a problem hiding this comment.
Even if this doc doesn't list them all, is it worth collecting the solutions we're aware of and plan to recognise in an issue?
There was a problem hiding this comment.
I think this is a good idea. In the future we might want to expand this even beyond signature verification. In addition to verifying the container signature, maybe the guest owner wants to scan the container image or perform more complex checks before running the workload. Eventually we might provide a hook for any trusted verification process. For now I think supporting multiple signature schemes is a good idea. Pending a bit of cleanup and maybe a few examples I think this is good.
| introduced in the implementation of red hat simple signing in the [containers/image](https://github.com/containers/image) project. | ||
| This policy file can not only be used for red hat simple signing In the secret container design, | ||
| we will continue to customize and expand the content of the policy file as | ||
| a general signature verification configuration file compatible with different signature schemes. |
There was a problem hiding this comment.
Are we assuming that all signature schemes are going to have a policy file of some sort? Is there any reason to allow schemes to request additional files?
There was a problem hiding this comment.
Maybe it is a better idea to use a unified policy file format in image-rs. I think there are the following reasons:
-
The policy file is distributed by the owner from the attestation-agent, which is a good channel for image-rs to accept the owner's control and configuration. The use of a unified policy file format enables the owner to determine which image use which scheme for signature verification through the policy file. In addition, this is conducive to playing more roles of the policy file on the image-rs side in the future.
-
The policy file format we currently use provides a strong configuration mechanism and has flexible scalability. We can support different signature schemes by customizing the current policy file.
-
Using the unified policy file format can make the architecture of image-rs verification signature function not too loose. Maybe this will enable us to do more optimization in the future.
There was a problem hiding this comment.
Ok, I think it's fine to start with this assumption. We might need to revisit if we encounter a signature scheme with totally different parameters.
There are multiple image signing and verification protocols/solutions available now, and there’s no standardization work for image signing yet. So in the design of confidential containers, we should support different signature mechanisms with modular implementation. Signed-off-by: Jiale Zhang <[email protected]>
For the reason for adding this method and more details, please refer to this PR: #6 and this issue: #7 Signed-off-by: Jiale Zhang <[email protected]>
|
Can someone merge this? I don't have privs but it seems to have been sitting here approved for a long time... ;) |
There are multiple image signing and verification protocols/solutions available now, and there’s no standardization work for image signing yet. So in the design of confidential containers, we should support different signature mechanisms with modular implementation.