Defining proposal A for FreeBSD jail configuration #8
Conversation
|
I added a table showing the mapping from traditional jail config parameters to the runtime spec. |
|
FreeBSD-specific section and container configuration links not working |
This started as a branch in opencontainers/runtime-spec and I made the links relative. I have made them absolute for now - they can change back if this (or something like it) gets merged to runtime-spec. |
dfr
force-pushed
the
simple-jail
branch
5 times, most recently
from
d5315f6
to
adc1db4
Compare
|
Fixed lint |
|
|
||
| - **`parent`** _(string, OPTIONAL)_ - parent jail. | ||
| The value is the name of a jail which should be this container's parent (defaults to none). | ||
| - **`host`** _(string, OPTIONAL)_ - allow overriding hostname, domainname, hostuuid and hostid. |
There was a problem hiding this comment.
From a JSON perspective this is a string but it sounds like the valid values are effectively an enum: "new" and "inherit"?
| | name | see below | | ||
| | path | root.path | | ||
| | ip4.addr | freebsd.jail.ip4Addr | | ||
| | ip4.saddrsel | - | |
There was a problem hiding this comment.
We'd omit these fields with -?
|
|
||
| The `devfs_ruleset` parameter is only required for jails which create new `devfs` mounts - typically OCI runtimes will mount `devfs` on the host. | ||
|
|
||
| The `children.max` parameter is managed by the OCI runtime e.g when a new container is added to a pod. |
There was a problem hiding this comment.
The OCI runtime doesn't know about pods (that's a Kubernetes concept). Would you expect a runtime invocation processing a bundle that specifies the parent to go find the parent and mutate its children.max?
There was a problem hiding this comment.
I will reword this for clarity. In ocijail I do indeed adjust children.max automatically when adding a new child jail.
|
|
||
| The `children.max` parameter is managed by the OCI runtime e.g when a new container is added to a pod. | ||
|
|
||
| The `allow.mount.*` parameter set is extensible - this proposal suggests representing allowed mount types as an array. As with `devfs`, typically the OCI runtime will manage mounts for the container by performing mount operations on the host. |
There was a problem hiding this comment.
I'm having trouble visualizing exactly what you're proposing here; what would be the contents of the allow.mount parameter?
There was a problem hiding this comment.
I will clarify and perhaps add to the example config
Signed-off-by: Doug Rabson <dfr@rabson.org>
This is intended to be a one-to-one mapping from the runtime configuration to the kernel's jail parameters. This keeps the runtime as simple as possible, moving all policy decisions to the container engine (e.g. podman, containerd, cri-o).