<<<<<<< HEAD

Kata Containers

Welcome to Kata Containers!

This repository is the home of the Kata Containers code for the 2.0 and newer releases.

If you want to learn about Kata Containers, visit the main Kata Containers website.

Introduction

Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.

License

The code is licensed under the Apache 2.0 license. See the license file for further details.

Platform support

Kata Containers currently runs on 64-bit systems supporting the following technologies:

Architecture	Virtualization technology
x86_64, amd64	Intel VT-x, AMD SVM
aarch64 ("arm64")	ARM Hyp
ppc64le	IBM Power
s390x	IBM Z & LinuxONE SIE

Hardware requirements

The Kata Containers runtime provides a command to determine if your host system is capable of running and creating a Kata Container:

$ kata-runtime check

Notes:

• This command runs a number of checks including connecting to the network to determine if a newer release of Kata Containers is available on GitHub. If you do not wish this to check to run, add the --no-network-checks option.

• By default, only a brief success / failure message is printed. If more details are needed, the --verbose flag can be used to display the list of all the checks performed.

• If the command is run as the root user additional checks are run (including checking if another incompatible hypervisor is running). When running as root, network checks are automatically disabled.

Getting started

See the installation documentation.

Documentation

See the official documentation including:

• Installation guides
• Developer guide
• Design documents
  • Architecture overview
  • Architecture 3.0 overview

Configuration

Kata Containers uses a single configuration file which contains a number of sections for various parts of the Kata Containers system including the runtime, the agent and the hypervisor.

Hypervisors

See the hypervisors document and the Hypervisor specific configuration details.

Community

To learn more about the project, its community and governance, see the community repository. This is the first place to go if you wish to contribute to the project.

Getting help

See the community section for ways to contact us.

Raising issues

Please raise an issue in this repository.

Note: If you are reporting a security issue, please follow the vulnerability reporting process

Developers

See the developer guide.

Components

Main components

The table below lists the core parts of the project:

Component	Type	Description
runtime	core	Main component run by a container manager and providing a containerd shimv2 runtime implementation.
runtime-rs	core	The Rust version runtime.
agent	core	Management process running inside the virtual machine / POD that sets up the container environment.
dragonball	core	An optional built-in VMM brings out-of-the-box Kata Containers experience with optimizations on container workloads
documentation	documentation	Documentation common to all components (such as design and install documentation).
tests	tests	Excludes unit tests which live with the main code.

Additional components

The table below lists the remaining parts of the project:

Component	Type	Description
packaging	infrastructure	Scripts and metadata for producing packaged binaries (components, hypervisors, kernel and rootfs).
kernel	kernel	Linux kernel used by the hypervisor to boot the guest image. Patches are stored here.
osbuilder	infrastructure	Tool to create "mini O/S" rootfs and initrd images and kernel for the hypervisor.
kata-debug	infrastructure	Utility tool to gather Kata Containers debug information from Kubernetes clusters.
agent-ctl	utility	Tool that provides low-level access for testing the agent.
kata-ctl	utility	Tool that provides advanced commands and debug facilities.
trace-forwarder	utility	Agent tracing helper.
runk	utility	Standard OCI container runtime based on the agent.
ci	CI	Continuous Integration configuration files and scripts.
ocp-ci	CI	Continuous Integration configuration for the OpenShift pipelines.
katacontainers.io	Source for the katacontainers.io site.
Webhook	utility	Example of a simple admission controller webhook to annotate pods with the Kata runtime class

Packaging and releases

Kata Containers is now available natively for most distributions.

General tests

See the tests documentation.

Metrics tests

See the metrics documentation.

Glossary of Terms

See the glossary of terms related to Kata Containers.

• About Kata Containers
• Community
  • Join Us
  • Users
  • Contributors
  • Review Team
  • Resource Owners
• Governance
  • Developers
    • Contributor
    • Committer
    • Admin
    • Owner
  • Architecture Committee
    • Architecture Committee Meetings
• Vendoring code
• Vulnerability Handling
  • Reporting Vulnerabilities
  • Vulnerability Disclosure Process
• Week in Review template

About Kata Containers

Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.

The Kata Containers project is designed to be architecture agnostic, run on multiple hypervisors and be compatible with the OCI specification and Kubernetes.

Kata Containers combines technology from Intel® Clear Containers and Hyper runV. The code is hosted on GitHub under the Apache 2 license and the project is managed by the Open Infrastructure Foundation. To learn more about the project and organizations backing the launch, visit https://www.katacontainers.io.

Community

Kata Containers is working to build a global, diverse and collaborative community. Anyone who is interested in supporting the technology is welcome to participate. Learn how to contribute on the Community pages. We are seeking different expertise and skills, ranging from development, operations, documentation, marketing, community organization and product management.

Join Us

You can join our community on any of the following places:

• Join our mailing list.

• Use the irc.oftc.net IRC server to join the discussions:

  • General discussions channel: #kata-general.
  • Development discussions channel: #kata-dev.

• Get an invite to our Slack channel. and then join us on Slack.

• Follow us on Twitter or Facebook.

Users

See Kata Containers installation user guides for details on how to install Kata Containers for your preferred distribution.

Contributors

See the contributing guide for details on how to contribute to the project.

Review Team

See the rota documentation.

Resource Owners

Details of which Kata Containers project resources are owned, managed or controlled by whom are detailed on the Areas of Interest wiki page, under the Resource Owners section.

Governance

The Kata Containers project is governed according to the "four opens", which are open source, open design, open development, and open community. Technical decisions are made by technical contributors and a representative Architecture Committee. The community is committed to diversity, openness, and encouraging new contributors and leaders to rise up.

Developers

For Kata developers, there are several roles relevant to project governance:

Contributor

A Contributor to the Kata Containers project is someone who has had code merged within the last 12 months. Contributors are eligible to vote in the Architecture Committee elections. Contributors have read only access to the Kata Containers repos on GitHub.

Committer

Kata Containers Committers (as defined by the kata-containers-committer team) have the ability to merge code into the Kata Containers project. Committers are active Contributors and participants in the project. In order to become a Committer, you must be nominated by an established Committer and approved by quorum of the active Architecture Committee via an issue against the community repo e.g. https://github.com/kata-containers/community/issues/403. Committers have write access to the Kata Containers repos on GitHub, which gives the ability to approve PRs, trigger the CI and merge PRs.

One of the requirements to be a committer is that you are an active Contributor to the project as adjudged by the above criteria. Assessing the list of active Contributors happens twice a year, lining up with the Architecture Committee election cycle. At that time, people who are in the kata-containers-committer team will also be reviewed, and a list of people, who are on the team, but who haven't been an active Contributor in the last 12 months will be created and shared with the Architecture Committee and community. After a short review period, to allow time to check for any errors, inactive team members will be removed.

Note

See issue #413 for a potential change in how active contribution is assessed.

Admin

Kata Containers Admins (as defined by the kata-containers-admin team have admin access to the kata-containers repo, allowing them to do actions like, change the branch protection rules for repositories, delete a repository and manage the access of others. The Admin group is intentionally kept small, however, individuals can be granted temporary admin access to carry out tasks, like creating a secret that is used in a particular CI infrastructure. The Admin list is reviewed and updated after each Architecture Committee election and typically contains:

• The Architecture Committee
• Optionally, some specific people that the Architecture Committee agree on adding for a specific purpose (e.g. to manage the CI)

Owner

GitHub organization owners have complete admin access to the organization, and therefore this group is limited to a small number of individuals, for security reasons. The owners list is reviewed and updated after each Architecture Committee election and contains:

• The Community Manager and one, or more extra people from the OpenInfra Foundation for redundancy and vacation cover
• The Architecture Committee
• Optionally, some specific people that the Architecture Committee agree on adding for a specific purpose (e.g. to help with repo/CI migration)

Architecture Committee

The Architecture Committee is responsible for architectural decisions, including standardization, and making final decisions if Committers disagree. It is comprised of 7 members, who are elected by Contributors.

The current Architecture Committee members are:

• Anastassios Nanos (ananos), Nubificus Ltd.
• Aurelien Bombo (sprt), Microsoft.
• Fupan Li (lifupan), Ant Group.
• Greg Kurz (gkurz), Red Hat.
• Ruoqing He (RuoqingHe), ISCAS.
• Steve Horsman (stevenhorsman), IBM.
• Zvonko Kaiser (zvonkok), NVIDIA.

Architecture Committee elections take place in the Autumn (3 seats available) and in the Spring (4 seats available). Anyone who has made contributions to the project will be eligible to run, and anyone who has had code merged into the Kata Containers project in the 12 months (a Contributor) before the election will be eligible to vote. There are no term limits, but in order to encourage diversity, no more than 2 of the 7 seats can be filled by any one organization.

The exact size and model for the Architecture Committee may evolve over time based on the needs and growth of the project, but the governing body will always be committed to openness, diversity and the principle that technical decisions are made by technical Contributors.

See the elections documentation for further details.

Architecture Committee Meetings

The Architecture Committee meets every Thursday at 1300 UTC. Agenda & call info can be found here.

In order to efficiently organize the Architecture Committee (AC) meetings, maximize the benefits for the community, and be as inclusive as possible, the AC recommends following a set of guidelines for raising topics during the weekly meetings.

Vendoring code

See the vendoring documentation.

Vulnerability Handling

Vulnerabilities in Kata are handled by the Vulnerability Management Team (VMT). There are generally two phases:

• The reporting of a vulnerability to the VMT
• Handling and disclosure of the vulnerability by the VMT

Reporting Vulnerabilities

Vulnerabilities in Kata should be reported using the responsible disclosure model.

There are two methods available to report vulnerabilities to the Kata community:

1. Report via a private issue on the Kata Containers launchpad
2. Email any member of the Kata Containers architecture committee directly

When reporting a vulnerability via the launchpad:

• You will need to create a launchpad login account.
• Preferably, but at your discretion, create the report as "Private Security", so the VMT can assess and respond in a responsible manner. Only the VMT members will be able to view a "Private Security" tagged issue initially, until it is deemed OK to make it publicly visible.

Vulnerability Disclosure Process

Vulnerabilities in the Kata Container project are managed by the Kata Containers Vulnerability Management Team (VMT). Vulnerabilities are managed using a responsible disclosure model.

Details of how to report a vulnerability, the process and procedures used for vulnerability management, and responsibilities of the VMT members can be found in the VMT documentation.

Previous Kata Containers Security Advisories are listed on their own page.

Week in Review template

See the week in review report template.

6023dab06b