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 |
Signed-off-by: Doug Rabson <dfr@rabson.org>
|
|
||
| The jail name is set to the create command's `container-id` argument. | ||
|
|
||
| The `devfs_ruleset` parameter is only required for jails which create new `devfs` mounts - typically OCI runtimes will mount `devfs` on the host. |
There was a problem hiding this comment.
How would the ruleset itself be specified? Can that be defined through the config?
|
|
||
| Jail parameters to use for the container's jail. | ||
|
|
||
| **`jail`** _(object, OPTIONAL)_ jail parameters for this container. |
There was a problem hiding this comment.
Would there be anything directly in the freebsd object other than jail?
I'm imagining a structure based on this description like:
{
// standard platform-independent config
"freebsd": {
"jail": {
// fields defined below
}
}
}|
|
||
| - **`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"?
| - **`ip6Addr`** _(array of string, OPTIONAL)_ - list of IPv6 addresses usable by the jail | ||
| - **`vnet`** _(string, OPTIONAL)_ - control the vnet used for this jail. | ||
| The value can be "new" which causes a new vnet to be created for the jail or "inherit" which shares the vnet for the parent (or host if there is no parent). | ||
| - **`enforceStatfs`** _(integer, OPTIONAL)_ - control visibility of mounts in the jail. |
There was a problem hiding this comment.
Should we use magic numbers (0, 1, 2) or define some enums here?
| | 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?
|
|
||
| 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?
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).