-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Glossary
TODO:
- More networking terms.
- More
virt*
features.- Storage terms.
0-9 | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
A shared file system protocol, it is used to allow the Kata VM's access files on the host. This is not longer use by Kata due to it's performance profile and issues supporting the POSIX standard (see this issue).
Kata now uses Virtio-fs by default.
64-bit ARM hardware (chip) architecture. Informally knows as "ARM 64". One of the platforms that Kata Containers operates on.
ACRN hypervisor.
See:
The process running inside the VM that manages the containers.
A ttRPC based protocol used between the runtime and the agent.
The agent control tool is a command-line test and development tool used to interact with the agent.
An annotation refers to a key/value attribute of the OCI runtime specification. It allows container managers to pass arbitrary data to the runtime as part of the OCI configuration file.
The names of annotations are "namespaced" using a reverse domain
notation. All Kata Containers annotations are
prefixed by io.katacontainers.
which represents the website.
See this document for details of the available Kata annotations.
See the Kata Containers architecture document.
The document that lists community members and the parts of the system and community they are either expert on or have an interest in.
The set of Kata Containers packaged components including:
- The configuration file.
- The guest assets.
- The hypervisor.
- The runtime.
- The trace forwarder.
- The utility program.
The process to follow when a PR appears to have been abandoned.
A method used in cloud computing, whereby the amount of computational resources in a server farm, typically measured in terms of the number of active servers, which vary automatically based on the load on the farm.
See the Kata Containers backport guide.
Calico is a CNI network plugin.
Confidential Computing or Confidential Containers.
Kata currently use a Jenkins Continuous Integration system. The sources for this system are stored in the CI repository.
See controlling the CI.
The CI configuration files are kept in their own repository.
The repository used to store the configuration for the CI.
The set of shell scripts and configuration used to control the CI.
The main
repository
contains a small set of scripts in its ci/
directory
that "redirect" to the
real scripts in the tests repository.
A lightweight hypervisor written in rust.
See:
CNM stands for Container Network Model. It is the container networking model that Docker uses.
CNI stands for Container Network Interface. It is a networking standard used by Kubernetes for its network plugins.
See help and the community repository.
See the Kata Containers code PR advice document.
Protection of data in use by performing computation in a hardware-based Trusted Execution Environment (TEE).
Also referred to as Trusted Computing (TC).
An Open source project working to enable cloud native confidential computing by leveraging Trusted Execution Environments to protect containers and data.
See also the Confidential Containers Glossary.
Note:
Confidential Containers inverts the traditional Kata threat model.
See
See Linux container and Kata Container.
containerd is a container manager that can be used with Kata 1.x and Kata 2.x.
The name of the Kata 2.x runtime binary that supports the shim v2 protocol.
A program that is designed to manage -- but not create -- containers. Common examples are Docker and containerd.
The Kata runtime is loaded or run by the container manager, which then makes requests to the runtime to manipulate containers created by Kata.
The process of implementing security tools and policies that will give you the assurance that everything in your container is running as intended, and only as intended.
A standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.
A plugin interface which enables Kubelet to use a wide variety of container runtimes, without the need to recompile.
A container is a virtual runtime environment that runs on top of a single operating system (OS) kernel and emulates an operating system rather than the underlying hardware.
See the Kata Containers contributing guide.
See this document for information on how to control the CI.
The Kubernetes Container Runtime Interface is a standard or specification for containers similar to the OCI runtime specification. However, unlike the OCI specification, CRI defines a plugin API rather than a set of command line options that a runtime must provide.
CRI-O is an implementation of the CRI to enable using OCI compatible runtimes.
DAX is a Linux kernel feature used by Kata that allows page cache and VM subsystems to be bypassed for improved performance.
Enabling the
debug console
allows an administrator to enter the VM environment using the
Kata env
command.
See the Kata Containers design documentation
See the Kata Containers developer guide.
"Docker in Docker" refers to running a container manager such as Docker inside a Kata Container.
Note:
With the advent of Kata 2.x, the name is technically incorrect since it is not currently possible to run Kata with Docker. See Docker for further details.
DNM or do-not-merge
is the name of the label added to a PR to stop it from being merged.
Container manager that was compatible with Kata 1.x but which is not compatible with Kata 2.x since Docker does not support the shim v2 architecture.
See the issue below for further details:
See the Kata Containers documentation requirements guide.
See the Kata Containers documentation review process.
A Kubernetes writable ephemeral storage volume shared between all containers in a pod.
A private encrypted memory region which forms part of the host's RAM and which is used by SAX.
The only processes that can read or write the memory in an unencrypted form in the enclave are those processes inside the enclave. This means that even higher privileged users and the O/S itself are unable to do so.
Enclave Page Cache. A block of host RAM dedicated to SGX Enclaves.
Firecracker hypervisor.
See:
GitHub Actions. Declarative (YAML) based
CI system that is triggered automatically by YAML files in the
.github/workflows/
directory of a Git repository.
For details of how to use a Graphics Processing Unit (GPU) inside a Kata Container ("pass through" or "passthrough") see the GPU passthrough documentation.
A golang package that simplifies working with the QEMU hypervisor.
The environment created inside the VM. Distinct from the host environment.
See also:
The guest kernel and guest image.
Similar to OCI hooks but not part of the OCI specification, guest hooks are run inside the VM by the agent. Making use of guest hooks requires a custom guest image and enabling the guest hooks Kata configuration file option.
The image used to boot the VM.
The kernel used to boot the VM.
To get help see the various ways you can get in contact with the community.
The community members who participate in the issue and PR review rota.
See OCI hooks and guest hooks.
See the Kata Containers howto documentation.
Program that creates and manages VM's.
Examples: ACRN, CH, Firecracker, QEMU.
It is a VSOCK implementation where the host side of the VSOCK it is a Unix socket. The host kernel does not need VSOCK support.
Refers to either:
-
The container image
The image requested by the user when running the container manager (for example
busybox
,ubuntu
ornginx
). -
The guest image
This is the image based on a rootfs that is used by the runtime to create the VM that holds the Kata Container.
Note that Kata works with two types of guest images:
A structured and modern approach for supporting an organization and facilitating innovation within an enterprise.
An initrd image is a initramfs based image containing a rootfs.
See the Kata Containers installation documentation.
IPVLAN is a driver for a virtual network device that can be used in container environment to access the host network. IPVLAN exposes a single MAC address to the external network regardless the number of IPVLAN device created inside the host network.
Text based file format
used by the OCI configuration file and
optionally generated by the Kata env
command.
Jaeger is a distributed OpenTelemetry tracing system compatible with Kata tracing.
The kata-runtime check
command can by run by a user or
administrator to determine if the environment is suitable to run
Kata Containers. It can also be used to check for
newer versions of Kata Containers.
To see details of the checks performed (which include CPU, device and kernel checks), run the command in verbose mode:
$ sudo kata-runtime check --verbose
Kata Containers uses a TOML format configuration file.
Note:
Multiple configuration files are allowed: read the document above closely for further details.
The VM based container environment created by the Kata Containers runtime.
Kata Containers is an open source project delivering increased container security and Workload isolation through an implementation of lightweight VM's.
The repository storing the code for Kata Containers.
The program that creates a Kata Container . For Kata 2.x
onwards, this program is called containerd-shim-kata-v2
.
This binary is run by a shim v2 compatible container manager such as containerd.
Note:
Do not confuse this with the
kata-runtime
binary.
The
kata-collect-data.sh
is a script packaged along with the main Kata components. It can be
run by users and administrators to gather information about a system
experiencing issues. The output can be pasted directly into a GitHub
issue to help the community understand the problem.
kata-deploy
is a tool that can be used to install Kata Containers in a cloud
environment.
The kata-runtime env
command can by run by a user or
administrator to provide details about the Kata environment the user is attempting to run
Kata Containers in.
By default produces output in TOML format but can also generate output in JSON format.
The
kata-runtime exec
command
allows an administrator to enter the
VM root environment
where the agent is running.
See the developer guide for further details.
kata-manager
is a tool that can be used to install Kata Containers.
The
kata-monitor
is a daemon that is used to provide metrics data about the
system.
See also metrics.
The name of the Kata Containers 2.x utility program, not the Kata Containers runtime.
Note: In Kata Containers 1.x, the
kata-runtime
binary was the combined runtime and utility program. For Kata 2.x, the original binary name was retained for backwards compatibility.
A set of Linux kernel configuration options and tooling designed to make building guest kernels easier.
KVM is the Linux kernel module that provides an API for the creation and manipulation of VM's. It is used by most of the Kata hypervisors.
On Intel x86_64
systems, KVM makes use of VT-x.
"Looks Good to Me". A common acronym signaling approval for a PR.
See the Kata Containers limitations document.
A "traditional" Linux container is a software defined and software
enforced confined environment to provide isolation from the host
environment. It makes use of the cgroups(7)
and namespaces(7)
features of the Linux kernel to isolate a
workload from the surrounding environment.
A container may also include additional security layers provided by the Linux kernel such as:
- seccomp
- An LSM (Linux Security Module) to provide MAC (Mandatory Access Control) such as:
- SELinux
- AppArmor
A container that runs for more than the lifespan of a short lived container.
MACVLAN is a Linux network device driver. MACVLAN allows a single physical interface to have multiple mac and IP addresses using MACVLAN sub-interfaces.
MACVTAP is a Linux network device driver meant to simplify virtualized bridged networking. It replaces the combination of the TUN/TAP and bridge drivers with a single module based on the MACVLAN device driver. A MACVTAP endpoint is a character device that largely follows the TUN/TAP ioctl interface and can be used directly by KVM/QEMU and other hypervisors that support the TUN/TAP interface.
See the Kata Containers repository.
An indication of how many containers can be run on a particular host. More is better since it indicates each container consumes a smaller amount of memory, allowing more containers to be run.
Collecting statistics about Kata as part of the CI.
See:
- The metrics documentation.
- Kata monitor.
The Mini-OS or minimal operating system is an informal name for the guest image.
Not the programming language, but the Kata Containers mailing list.
Creating a VM inside an existing VM.
See: DinD.
Non-Uniform Memory Access.
Non-Volatile Dual In-line Memory Module device. See DAX.
The Open Container Initiative which creates standards for containers such as the OCI runtime specification.
An OCI bundle is an archive normally created by a container manager (such as containerd). It specifies all the information required by an OCI runtime (such as Kata Containers) to create an OCI container.
The name of the OCI config.json
configuration file.
This file is passed to the runtime and is usually
generated by the container manager.
As the name suggests, the format of this file is JSON.
The OCI (Open Containers Initiative) defines a set of container related standards including the OCI runtime specification
Kata Containers adheres to this standard when creating a container.
An optional set of binaries that can be called at various parts of the container lifecycle. These binaries are specified in the OCI configuration file. These hooks run in the context of the host and are called by the runtime.
See guest hooks.
This refers to the OCI designed runtime specification used by Kata Containers. The specification defines the command line options that an OCI runtime must provide, along with the expected behaviour for each option. It also defines the OCI configuration file format and the concept of a bundle.
Generally refers to the OCI runtime specification.
A tool used to build guest images.
A set of scripts and configuration files used to generate binary packages of Kata in various formats.
Persistent memory device. See DAX.
A group of one or more containers.
A Group of one or more containers, with shared storage/network, and a specification for how to run the containers.
64-bit IBM PowerPC hardware (chip) architecture. One of the platforms that Kata Containers operates on.
A computing model that offers a proprietary environment dedicated to a single business entity.
See the Kata containers PR review guide.
"Please Take a Look". A common acronym requesting someone to review a PR or issue.
Computing services offered by third-party providers over the public Internet, making them available to anyone who wants to use or purchase them.
Intel QuickAssist Technology (QAT) provides hardware acceleration for security (cryptography) and compression.
See the using QAT with Kata document for further details.
QEMU hypervisor.
See:
See the Kata Containers release document.
One of various filesystems used within the Kata Containers system. These are summarised in the table here:
See root filesystem.
Refers to running a hypervisor as a non-privileged user.
See also herders.
The program run by a container manager that is responsible for creating the container environment.
See: Kata Containers runtime.
Refers to "Linux on IBM Z". 64-bit IBM System/390 hardware (chip) architecture. One of the platforms that Kata Containers operates on.
An environment in which to run pods. In Kata, a sandbox equates to the VM.
System call filtering. The agent is able to disable specified system calls if these are specified in the OCI configuration file and the guest seccomp Kata configuration file option is enabled.
See the Linux specific configuration part of the OCI runtime specification for further details.
An architecture in which code is executed on-demand. Serverless workloads are typically in the cloud, but on-premises serverless platforms exist, too.
Intel Software Guard Extensions (SGX) is an Intel technology that, in the context of Kata Containers, allows the container workload access to the SGX enclave, which can allow the workload to operate on confidential data not accessible to the hypervisor or the host. This is achieved by making the EPC accessible inside the container environment.
See the using SXT and Kata document for further details.
An enhanced architecture better suited to VM based hypervisors compared to the original OCI runtime specification.
A container that only runs for a small amount of time. Although precise times cannot be given, this is generally accepted to mean a container whose lifespan is at most a few seconds.
A sidecar is a separate container that runs alongside an application container in a Kubernetes pod – a helper application of sorts.
A running container that is not using the latest assets. This can happen when a new Kata Containers installation is applied to the system. In this scenario, all running containers should be restarted to ensure they are using the latest assets.
See the stable branch document.
The static check script performs a number of static analysis checks on the files modified by a PR. It is run by the CI. If any checks fail, the PR cannot be merged.
Logging methodology using key/value pairs to enrich logs and make it possible to query them.
See:
Single Root I/O Virtualization (SR-IOV) enables splitting a physical device into virtual functions (VFs). Virtual functions enable direct passthrough to VM's or containers.
See the SR-IOV Kata documentation for further details.
A TAP device is a virtual Ethernet (Layer 2) device that is used to create a network bridge.
Traffic control, is a set mechanisms to manage packets. Kata uses TC filter rules to redirect traffic from the container network interface to a tap interface connected to the VM.
Intel Trust Domain Extensions (TDX) isolates the VM from the VMM / hypervisor.
The repository used to store all tests apart from unit tests which are stored in the main repository.
Identifying potential threats, their boundaries, and mitigations for all parts of a system. The traditional Kata Containers threat model treats the host as trusted and the guest as untrusted whereas Confidential Containers inverts this model:
Threat model | Host trusted? | Guest trusted? |
---|---|---|
standard | yes | no |
CC | no | yes |
See:
Human and machine readable text file format used for the Kata Containers configuration file.
Communications protocol similar to gRPC but lighter weight. ttRPC API's are designed by writing protocol buffer definitions. Used for the agent communication protocol.
See the tracing document for details of tracing Kata using OpenTelemetry.
A tool that must be run to obtain trace details from the agent.
A point where data changes its level of trust.
See the Kata Containers unit test advice guide.
See the Kata Containers use case documentation.
See kata-runtime
.
See the vendoring document.
One of two YAML files that the project uses to track dependencies:
- The main versions database.
- The test specific versions database.
These files are used by the CI to ensure a reproducible test and build environment.
A VETH device is a virtual ethernet device. Packets transmitted on one end of the VETH pair are immediately delivered to the other end. In the container ecosystem, a network plugin creates a VETH device to act as a tunnel between the network namespace created for a container and the host network namespace by placing one end of the VETH pair in the container network namespace while the other end would be placed in the host network namespace.
"Virtual Function I/O" is a Linux kernel framework which allows host devices to be "shared" into a VM ("device assignment").
virtcontainers
is a golang package that forms the core of the golang
runtime. It is used to abstract away the complexity of
handling different hypervisors, hardware architectures, container
standards and networking models behind a simple API.
It is a specification for a family of virtual devices. The purpose is that a guests can use efficient and standard devices with help of para virtualization.
A shared file system protocol,
used to allow the Kata VM's access files on the host. Required
a daemon (virtiofsd
) to be running on the host.
Successor to 9pfs.
Computer software, firmware or hardware that creates and runs virtual machines.
A software program or operating system that not only exhibits the behaviour of a separate computer, but is also capable of performing tasks such as running applications and programs like a separate computer.
A Virtual Machine created by a hypervisor that gives processes inside it the impression they are running on a real system (real hardware).
VMCache is a feature similar to VM templating which boosts performance for certain use-cases.
See the VM Caching document for further details.
See VM caching and VM templating.
The Vulnerability Disclosure Process. See the Vulnerability Management Process.
A performance feature that creates (or more strictly clones) a new VM to host a container from an existing pre-created "template VM".
See the VM Templating document for further details.
It is a type of socket that allows communication between VM's and the host they are running on without requiring a network.
VT-x is the set of Intel CPU features that allow the creation of VM's.
Linux uses VT-x on Intel systems via KVM to isolate the VM from the host environment.
The main Kata Containers web site is: https://katacontainers.io.
The program or application the user interacting with the container manager has requested to be run.
Intel 64-bit hardware (chip) architecture. One of the platforms that Kata Containers operates on.
Human and machine readable text file format used for the versions database.
0-9 | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z