Container runtimes provide different levels of isolation, from kernel
namespaces to hardware virtualization. When starting a specific
container, one may want to decide which level of isolation to use
depending on how much we trust the container workload. Fully verified
and signed containers may not need the hardware isolation layer but e.g.
CI jobs pulling packages from many untrusted sources should probably not
run only on a kernel namespace isolation layer.
Here we allow CRI-O users to define a container runtime for trusted
containers and another one for untrusted containers, and also to define
a general, default trust level. This anticipates future kubelet
implementations that would be able to tag containers as trusted or
untrusted. When missing a kubelet hint, containers are trusted by
default.
A container becomes untrusted if we get a hint in that direction from
kubelet or if the default trust level is set to "untrusted" and the
container is not privileged. In both cases CRI-O will try to use the
untrusted container runtime. For any other cases, it will switch to the
trusted one.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We use a SOCK_SEQPACKET socket for the attach unix domain socket, which
means the kernel will ensure that the reading side only ever get the
data from one write operation. We use this for frameing, where the
first byte is the pipe that the next bytes are for. We have to make sure
that all reads from the socket are using at least the same size of buffer
as the write side, because otherwise the extra data in the message
will be dropped.
This also adds a stdin pipe for the container, similar to the ones we
use for stdout/err, because we need a way for an attached client
to write to stdin, even if not using a tty.
This fixes https://github.com/kubernetes-incubator/cri-o/issues/569
Signed-off-by: Alexander Larsson <alexl@redhat.com>
By only handling create events, we are breaking plugins that don't
create and write atomically, like weave for example.
The Weave plugin creates the file first and later write to it. We are
missing the second part and never see the final CNI config file.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This is an optimization of our image pull code path. It's basically
how docker handles pulls as well. Let's be smart and check the image in
pull code path as well.
This also matches docker behavior which first checks whether we're
allowed to actually pull an image before looking into local storage.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Some runtimes like Clear Containers need to interpret the CRI-O
annotations, to distinguish the infra container from the regular one.
Here we export those annotations and use a more standard dotted
namespace for them.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The ocid project was renamed to CRI-O, months ago, it is time that we moved
all of the code to the new name. We want to elminate the name ocid from use.
Move fully to crio.
Also cric is being renamed to crioctl for the time being.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Remove some logic that messed with the names we assigned to just-pulled
images in the storage layer, since the image and storage libraries now
take care of that for us.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
If an image that we're pulling from a registry has a digest in its
reference, use that to construct the destination image's reference.
This should help us detect cases where the image has previously been
pulled.
When we have a filter to use when listing images, expand it into a
reference so that we can properly match against names of images that
we've previously stored using fully expanded references.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
`image` as a variable/field name becomes too redundant and difficult to
grep for. Switching to `imageServer` makes for more readable code.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
We need to support cases where InitCNI() is called before
any CNI configuration files have been installed. This is
for example happening when deploying a k8s cluster with kubeadm.
kubeadm will start the DNS pod and it is left to the caller to
pick a network overlay and create the corresponding pods, that
will typically install a CNI configuration file first.
Here we address that issue by doing 2 things:
- Not returning an error when the default CNI config files
directory is empty.
- If it is empty, we start a monitoring thread (fsnotify based)
that will synchronize the network configuration when a CNI
file is installed there.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
To be consistent with the rest of the CRI-O logs, and to be able
to set the ocicni verbosity, we convert it from glog to logrus.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When we pull an image, preserve the tag portion of the name that we were
asked to use for pulling it, instead of unconditionally replacing it
with "latest".
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
When looking for the image to use for creating a container, there's no
need to attempt parsing the ID a second time, and doing so can create
confusing error messages.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
kubelet sends a request to create a container with an image ID (as
opposed as an image name). That ID comes from the ImageStatus response.
This patch fixes that by setting the image ID as well as the image name
and fix the login to lookup for image ID as well.
Found while running `make test-e2e-node`.
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
The CRI doesn't expect us to implicitly pull an image if it isn't
already present before we're asked to use it to create a container, and
the tests no longer depend on us doing so, either.
Limit the logic which attempts to pull an image, if it isn't present, to
only pulling the configured "pause" image, since our use of that image
for running pod sandboxes is an implementation detail that our clients
can't be expected to know or care about. Include the name of the image
that we didn't pull in the error we return when we don't pull one.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Add an intermediate API layer that uses containers/storage, and a
containers/image that has been patched to use it, to manage images and
containers, storing the data that we need to know about containers and
pods in the metadata fields provided by containers/storage.
While ocid manages pods and containers as different types of items, with
disjoint sets of IDs and names, it remains true that every pod includes
at least one container. When a container's only purpose is to serve as
a home for namespaces that are shared with the other containers in the
pod, it is referred to as the pod's infrastructure container.
At the storage level, a pod is stored as its set of containers. We keep
track of both pod IDs and container IDs in the metadata field of
Container objects that the storage library manages for us. Containers
which bear the same pod ID are members of the pod which has that ID.
Other information about the pod, which ocid needs to remember in order
to answer requests for information about the pod, is also kept in the
metadata field of its member containers.
The container's runtime configuration should be stored in the
container's ContainerDirectory, and used as a template. Each time the
container is about to be started, its layer should be mounted, that
configuration template should be read, the template's rootfs location
should be replaced with the mountpoint for the container's layer, and
the result should be saved to the container's ContainerRunDirectory,
for use as the configuration for the container.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
