Hi,
We decided to go with a classic build for the first iterations of this snap because we cannot address all the issues we have with the strict build. The switch from strict to classic needs a manual review. OpenID transaction in progress
Many thanks, Konstantinos
Hi @kjackal
According to Process for reviewing classic confinement snaps , Classic requests should fall under at least one of the supported categories.
A discussion that might be relevant was started here, regarding the general request for container runtimes to be granted classic confinement.
@pedronis Is there any update in this regard?
Thanks!
Hi @kjackal,
We are happy to help trying to solve the issues if that’s possible. So feel free to share here the problems your team is experiencing so maybe there is a way to stay under strict confinement as well.
Thank you for the quick reply.
The main problem we have has its roots on our inability to predict the workloads the users would be running. We set the interfaces on the containerd runtime and they get inherited to the user workloads that are essentially the workloads the runtime spawns as containers. We can predict the permissions needed for workloads we ship (eg the CNI network, or an operator that would work on nvidia cards) but we cannot predict the permissions needed by all potential workloads the users may ask to run.
Hi @kjackal
Whilst k8s may not fit in any of the supported categories, process for reviewing classic confinement snaps specify that if the snap requires “access to resources not yet supported by snapd and where the requirement is clearly understood to be supportable by snapd. This may result in temporarily granting classic until snapd supports the use case in strict mode”.
After discussion with @alexmurray and @pedronis we agreed to grant k8s snap classic until snapd provides better support for this use case, in the same way as for microk8s. The publisher is already vetted.
Thus, granting use of classic. This is now live.
Thanks!
