priteshbandi
commented
11 months ago Making notation just a thin cli wrapper for notation-go and then your server/service code can take dependency directly on notation-go to sign and verify signature. This way notation will run as part of your service process with cpu minimal footprint. We will need to investigate current state but it shouldn't be very far from ideal but I am expecting there would be some work required.
There is one more elephant in the room, notation plugin which run's as separate process. I think here we can refactor notation-go to allow registration of plugin as library/go-object (most of this work is there but we might need to polish the interface and iron out any quirks) and now if plugin code is opensource, you can directly use plugin as library and then plugin will also run as part of your service process.
TLDR; I recommend we refactor notation-go to allow consumers to take direct dependency and also, enable plugin as library instead of executable support.
cc:/ @shizhMSFT @patrickzheng200 @iamsamirzon
shizhMSFT
Is your feature request related to a problem?
One of the challenges we face in our enterprise scenarios is signing and verifying numerous artifacts from various container registries. This can become a CPU intensive operation when we run multiple Notation CLI commands in parallel.
This problem stems from the fact that each CLI command creates a new process, which consumes a significant amount of CPU and memory resources.
What solution do you propose?
My suggestion is to create a Notation service executable that can run as a background process and listen to a network port.
The caller can use http-based IPC to request signing and validating operations on artifacts.
This approach will reduce resource consumption, as there will be only one process handling all sign and verify requests.
What alternatives have you considered?
One possible solution is to package the Notation CLI executable on the host machine and invoke the CLI command from our service.
However, this solution has a scalability issue. According to my benchmark, it can consume all the CPU resources of the host machine when there are more than 50 notation sign and verify operations. Therefore, it is not suitable for handling a large number of artifacts.
Any additional context?
No response