keyring configuration #754
Labels
Milestone
Comments
|
@cyphar do you think this is something we'd be safe to think/discuss about post-1.0? (it sounds like it's something that'd be fine to add in a 1.1, for example) |
|
Yeah, this would be post-1.0. As an aside, it looks like there's some (worrying) move to namespace these as well as a few other things in a pretty insane way. |
|
See proposal in #950 |
kailun-qin
added a commit
to kailun-qin/runtime-spec
that referenced
this issue
Aug 3, 2021
Currently, with `runc` we have a special cmdline flag `--no-new-keyring` for `runc run` that enables/disables the creation of a new kernel keyring. The main reason we have the option is that older kernels had issues with allocating a lot of keyrings (so in order to run containers on old kernels you need to disable the creation of a new keyring). This patch adds keyring support into part of the OCI spec which allows managers to drive this behavior in a runtime-agnostic way and helps make swapping in other runtimes easier. Fixes opencontainers#754 Fixes opencontainers#950 Signed-off-by: Kailun Qin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With runC we have a special flag for
runc runthat enables/disables the creation of a new kernel keyring. The main reason we have the option is that older kernels had issues with allocating a lot of keyrings (so in order to run containers on old kernels you need to disable the creation of a new keyring).However, while keyrings aren't containerised on Linux, maybe it makes sense for us to include some keyring information in
config-linux?The text was updated successfully, but these errors were encountered: