From 67039eb2f63e60d5f82911d2a6197c86a3fa9545 Mon Sep 17 00:00:00 2001 From: Taylor Thomas Date: Fri, 18 Oct 2024 08:52:58 -0600 Subject: [PATCH 1/6] feat(assessments): Adds wasmCloud project self-assessment (#1389) Adds the completed TAG Security self-assessment Signed-off-by: Taylor Thomas --- .../projects/wasmcloud/self-assessment.md | 251 ++++++++++++++++++ 1 file changed, 251 insertions(+) create mode 100644 community/assessments/projects/wasmcloud/self-assessment.md diff --git a/community/assessments/projects/wasmcloud/self-assessment.md b/community/assessments/projects/wasmcloud/self-assessment.md new file mode 100644 index 000000000..3a1496c33 --- /dev/null +++ b/community/assessments/projects/wasmcloud/self-assessment.md @@ -0,0 +1,251 @@ +# wasmCloud Self-assessment + +## Table of contents + +- [wasmCloud Self-assessment](#wasmcloud-self-assessment) + - [Table of contents](#table-of-contents) + - [Metadata](#metadata) + - [Security links](#security-links) + - [Overview](#overview) + - [Background](#background) + - [Actors](#actors) + - [Actions](#actions) + - [Goals](#goals) + - [Non-goals](#non-goals) + - [Self-assessment use](#self-assessment-use) + - [Security functions and features](#security-functions-and-features) + - [Project compliance](#project-compliance) + - [Secure development practices](#secure-development-practices) + - [Security issue resolution](#security-issue-resolution) + - [Appendix](#appendix) + - [Related projects and vendors](#related-projects-and-vendors) + +## Metadata + +| | | +| ----------------- | ------------------------------------------------------ | +| Assessment Stage | In Progress | +| Software | https://github.com/wasmCloud/wasmCloud | +| Security Provider | No | +| Languages | Rust, Go, TypeScript, JavaScript, Shell | +| SBOM | wasmCloud does not currently generate SBOMs on release | + +### Security links + +| Document | URL | +| ------------- | ------------------------------------------------------------ | +| Security file | https://github.com/wasmCloud/wasmCloud/blob/main/SECURITY.md | + +## Overview + +wasmCloud is a platform for building and deploying distributed applications using WebAssembly +(Wasm). It is designed to provide a lightweight, highly secure and portable WebAssembly runtime with +WebAssembly-native orchestration for managing and scaling declarative applications – enabling +secure, portable, and composable cloud native applications. This allows developers to build scalable +systems using any programming language that compiles to WebAssembly, providing a universal runtime +for cloud, edge, and IoT environments. + + +### Background + +wasmCloud is an open-source technology enabling platform engineering and application development +teams to deliver distributed applications built using WebAssembly. + +WebAssembly offers several core benefits that make it an increasingly important and interesting +technology for cloud-native computing workloads: + +* **Portability**: WebAssembly is designed to be platform-agnostic, meaning code written in + WebAssembly can run across different environments—whether in browsers, servers, cloud, edge, or + IoT devices—without modification. + +* **Performance**: WebAssembly is compiled into a binary format that runs at near-native speed, + providing efficient execution compared to traditional interpreted languages, especially in + resource-constrained environments. + +* **Security**: WebAssembly operates in a secure, sandboxed environment, isolating applications from + the host system. Each sandboxed module gets access to only the set of capabilities that it is + explicitly granted and nothing more. + +* **Lightweight**: WebAssembly Components are small and fast to load, which makes them ideal for + resource-constrained environments like edge devices and embedded systems, while also reducing + startup times in the cloud. + +wasmCloud goes beyond core WebAssembly by targetting WebAssembly Components as the unit of +deployment, which themselves bring along the following additional benefits on top of what +WebAssembly already provides: + +* **Language-agnostic Composition**: WebAssembly Components allow code to be written in different + programming languages to be seamlessly integrated into a single application. This means developers + can leverage the strengths of multiple languages while maintaining a unified runtime, enhancing + both flexibility and collaboration. + +* **Modularity and Reusability**: With WebAssembly Components, individual functionality can be + encapsulated into reusable modules, which can be composed into larger applications. This + modularity simplifies development and maintenance by enabling code reuse and simplifying upgrades + or replacement of specific components without disrupting the entire system. + +* **Interoperability**: WebAssembly Components are designed to communicate with each other in a + standardized way, regardless of the programming languages they were built in. This ensures that + components can be shared and reused across projects or ecosystems, enabling faster development + cycles and more interoperable systems. + +* **Security Isolation**: As with core WebAssembly modules, components are run inside of their own + secure sandboxes. Each component is fully isolated from the others, and they can interact with one + another over typed interface definitions. + +Finally, wasmCloud provides the necessary tooling to cover the entire software lifecycle from local +development to running and operating in prouction. + +### Actors + +The following table describes all actors of the wasmCloud project. + + +| Actor | Description | +| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| wasmCloud Host | The wasmCloud host is the core executable for wasmCloud. It uses the wasmtime runtime to execute WebAssembly Components and also executes providers. It connects to NATS as its communication backbone and provides a low-level API for controlling various components of the system. Hosts are separated from other hosts using what is called a "lattice" (a namespace) | +| Wadm (wasmCloud Deployment Manager) | A reconcilation loop based system comparable to the Kubernetes API and scheduler. This actor takes desired state and translates it to commands that are sent to individual hosts. It has the ability to manage multiple lattices but must authenticate to the Host APIs in the same way as any other entity | +| WebAssembly Components | Possibly untrusted, user-provided code compiled to WebAssembly. This is often the business logic of an application. WebAssembly Components are entirely introspectable so the system can identify exactly what capabilies are being requested or provided. These are subject to all the security guarantees described in the [background](#background) section. | +| Capability Providers | Providers are the most privileged actor in the wasmCloud ecosystem and should be under the most scrutiny. As indicated by their name, these binaries provide specific functionality required by WebAssembly Components in the system. Examples of these include database connections, HTTP connections, ML/AI processing, access to blobstores, and so on. Generally there are many components, but few providers. A provider is often meant to be reused by many components. They are generally provided as trusted wasmCloud maintained providers or as custom providers created by the organization running wasmCloud | + + +### Actions + +| Action | Description | +| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Host API calls | All wasmCloud APIs are via topic spaces in NATS, so authorization and authentication are initially provided by NATS. The recommended pattern for authn/z is via [decentralized JWT authentication](https://docs.nats.io/running-a-nats-service/configuration/securing_nats/auth_intro/jwt). These tokens can be used to restrict access to specific lattices (i.e. namespaces) or specific API operations. Additionally, there is an optional and extensible [policy service](https://wasmcloud.com/docs/deployment/security/policy-service) that API calls are subject to if configured. This allows users to integrate with existing frameworks like OPA for authorization | +| Wadm API calls | Similarly to the Host API, the Wadm API uses NATS topics and authn/z for connections, along with the same power to restrict those tokens. Wadm API calls eventually get translated to Host API calls, using the permissions of Wadm and not the user. | +| Linking components | Although this is technically a subset of the Host API, it is important to call out from a security actions perspective. wasmCloud gives you the ability to link components to their requested capabilities at runtime. This is a privileged operation often restricted to platform teams for production deployments. These links can be removed at any time for instant denial of capabilities or to hot swap capabilities when rolling out critical security fixes | +| Secrets management | wasmCloud provides [secrets backend](https://wasmcloud.com/docs/deployment/security/secrets) with the ability to hook in a variety of secret stores. These are provided via encrypted data as described in the [wasmCloud documentation](https://wasmcloud.com/docs/concepts/secrets) | + +### Goals + +wasmCloud's goal is to be the way to run standard WebAssembly Components (i.e. no custom wasmCloud +SDKs needed) in a distributed manner. As such, the project goal is to ensure all of the security +guarantees of WebAssembly are reflected in wasmCloud itself. Only those with proper API permssions +and roles are able to start entities within the system and link those entities together. By default +nothing is linked together unless explictly configured to do so, maintaining the sandbox +environment. + +The security of communications between hosts is reliant on the configuration of NATS and the access +tokens used to connect to it. If the NATS cluster is properly configured with token authentication +and TLS, communications should be secure and encrypted. Misconfiguration of NATS can result in +unintentional exposure or connections. + +### Non-goals + +wasmCloud does not attempt to enforce or handle other security guarantees outside of those provided +by WebAssembly or other systems integrated via capability provider + +## Self-assessment use + +This self-assessment is created by the wasmCloud team to perform an internal analysis of the +project’s security. It is not intended to provide a security audit of wasmCloud, or function as an +independent assessment or attestation of wasmCloud’s security health. + +This document serves to provide wasmCloud users with an initial understanding of wasmCloud’s +security, where to find existing security documentation, wasmCloud plans for security, and general +overview of wasmCloud security practices, both for development of wasmCloud as well as security of +wasmCloud. + +This document provides the CNCF TAG-Security with an initial understanding of wasmCloud to assist in +a joint-assessment, necessary for projects under incubation. Taken together, this document and the +joint-assessment serve as a cornerstone for if and when wasmCloud seeks graduation and is preparing +for a security audit. + +## Security functions and features + +**Critical** + +- wasmCloud Host: The host embeds the [Wasmtime runtime](https://wasmtime.dev/) as it's WebAssembly + runtime, which is fuzzed regularly. The security of the underlying WebAssembly sandbox relies + completely on its security. The wasmCloud host itself validates that various entities are + correctly linked and allowed to communicate. + +**Security Relevant** + +- Capability Providers: Providers are the most privileged actor in the wasmCloud ecosystem and + should be under the most scrutiny and review before adding the use of a new provider. +- NATS Cluster: The NATS cluster used for wasmCloud should be properly secured and encrypted to + guarantee security of communications. It is highly recommended to use [decentralized JWT + authentication](https://docs.nats.io/running-a-nats-service/configuration/securing_nats/auth_intro/jwt) + to best restrict access to specific API topics +- Policy Service: If used, integration with policy engines should have testing in place for the + various rules + +## Project compliance + +The wasmCloud project does not comply with any specific security standard. However, various security +standards may be applied to related projects such as NATS or services to which capability providers +can connect. + +## Secure development practices + +**Development Pipeline** + +- All wasmCloud repos use Dependabot configured with regular scans for all projects, including + automatic update PRs +- The main wasmCloud host is also subject to `cargo audit` on all PRs. +- All PRs require reviews from the proper subject matter expert before merging + +**Communication Channels** + +Most communication happens on the wasmCloud Slack for both inbound/outbound communication from/to +the community as well as internal communication between project and org maintainers. There is also +the cncf-wasmCloud-maintainers@lists.cncf.io that can be used for asynchronous communication + +**Ecosystem** + +wasmCloud is deeply integrated into the cloud native ecosystem. The project uses CNCF incubating +project NATS for the messaging layer of its application. wasmCloud supports running its WebAssembly +binaries by downloading from OCI compliant registries, exporting traces, logs, and metrics to +OpenTelemetry compatible collectors, and defines its declarative application manifests using the +Open Application Model. + +Additionally, there are integrations with other technologies within the CNCF such as a Kubernetes +operator, policy engine support for OpenPolicyAgent, and many other extension points. + +## Security issue resolution + +The project's security disclosure and incident processes are thoroughly documented in the +[SECURITY.md](https://github.com/wasmCloud/wasmCloud/blob/main/SECURITY.md) doc in the main repo of +the project. + +An example of the resulting advisory can been seen +[here](https://github.com/wasmCloud/wasmcloud-otp/security/advisories/GHSA-2cmx-rr54-88g5) + +## Appendix + +- Known Issues Over Time: There has only been one recorded CVE. Details of that CVE can be found + [here](https://github.com/wasmCloud/wasmcloud-otp/security/advisories/GHSA-2cmx-rr54-88g5). + Anecdotally, various security bugs have been prevented from the project's testing pipelines +- The wasmCloud project has passed OpenSSF best practices: + https://www.bestpractices.dev/en/projects/6363 +- Various users have provided real-world case studies of using wasmCloud. Links to those case + studies and talks are provided for convenience below. More will also be available as the project + finishes adopter interviews for moving to incubating + - https://www.cncf.io/blog/2024/01/05/bringing-webassembly-to-telecoms-with-cncf-wasmcloud/ + - https://www.cncf.io/blog/2022/11/17/better-together-a-kubernetes-and-wasm-case-study/ + - https://www.cncf.io/blog/2024/08/23/wasmcloud-on-the-factory-floor-efficient-and-secure-processing-of-high-velocity-machine-data/ + - https://www.youtube.com/live/lUV49UjFAQM?si=oHxguYRRXFDHLdaF + - https://youtu.be/1sWQqgK-79c?si=m3g0UqH1qp2_qAUm + +Also of note is that the wasmCloud project has already complete and passed a security audit with +Trail of Bits. A summary of that audit can be found here: +https://ostif.org/ostif-has-completed-a-security-audit-of-wasmcloud/ + +### Related projects and vendors + +Within the WebAssembly space, wasmCloud is most often compared with Fermyon Spin or with WasmEdge. A +brief discussion of the differences are discussed below: + +- WasmEdge is a CNCF WebAssembly runtime with many batteries included. In many ways, WasmEdge is + more similar to Spin and other Serverless runtimes than wasmCloud. A key difference is that + wasmCloud is a distributed platform and not a runtime. wasmCloud embeds a runtime (Wasmtime), but + is designed for distributed workloads. WasmCloud includes a WebAssembly Components native + orchestrator that enables running components from the edge to the cloud. +- Fermyon’s Spin project is a FaaS style runtime (Wasmtime) with a heavy focus on a smooth developer + experience. Like WasmEdge, they have a batteries-included runtime and are built on the component + model, but require the use of their custom multi-language Spin developer SDKs. They have the most + polished developer experience but do not have many options for running in a distributed + environment outside of relying on Kubernetes to orchestrate and scale deployments. From fedbc1f5f8eeaa6442906e4736dbcf3ae68637f3 Mon Sep 17 00:00:00 2001 From: Vikas Agarwal <75295756+vikas-agarwal76@users.noreply.github.com> Date: Mon, 21 Oct 2024 22:44:02 +0530 Subject: [PATCH 2/6] Create folder for WG content (#1377) * Create readme.md Signed-off-by: Vikas Agarwal <75295756+vikas-agarwal76@users.noreply.github.com> * Update readme.md Signed-off-by: Vikas Agarwal <75295756+vikas-agarwal76@users.noreply.github.com> --------- Signed-off-by: Vikas Agarwal <75295756+vikas-agarwal76@users.noreply.github.com> --- community/working-groups/compliance/content/readme.md | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 community/working-groups/compliance/content/readme.md diff --git a/community/working-groups/compliance/content/readme.md b/community/working-groups/compliance/content/readme.md new file mode 100644 index 000000000..fcb97a300 --- /dev/null +++ b/community/working-groups/compliance/content/readme.md @@ -0,0 +1,3 @@ +# Folder for Compliance WG Content + +This folder contains content created by Compliance WG From 55b469e80c0214f7375da02b72b14e1ae2ed814c Mon Sep 17 00:00:00 2001 From: Matthew Flannery Date: Wed, 23 Oct 2024 06:41:21 +1100 Subject: [PATCH 3/6] Update README.md (#1388) The Members heading in the past documented all contributing members. This has since been removed due to the sheer growth of contributors, and has been left in the README as an empty placeholder. Thus, the "## Members" heading is redundant. Signed-off-by: Matthew Flannery Co-authored-by: Eddie Knight --- README.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/README.md b/README.md index 32a4badbe..4d7fa1aab 100644 --- a/README.md +++ b/README.md @@ -71,10 +71,6 @@ If you are new to the group, we encourage you to check out our Explore groups affiliated with or relevant to Security TAG [here](governance/related-groups/README.md) -## Members - - - ## Leadership Details about the TAG Chairs, Tech Leads, and TOC Liaisons can be found on the [CNCF Technical Advisory Groups (TAGs) information page](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md) From de38cebd7645ff0995b86306e38c5de29ec5fd6e Mon Sep 17 00:00:00 2001 From: Eddie Knight Date: Wed, 23 Oct 2024 07:55:24 -0500 Subject: [PATCH 4/6] Added charter for Cross-Foundation Alignment WG (previously Baseline) (#1373) * Added charter for Cross-Foundation Alignment WG (previously Baseline) Signed-off-by: Eddie Knight * Updated to use 'commons' name for WG Signed-off-by: Eddie Knight --------- Signed-off-by: Eddie Knight --- community/working-groups/commons/README.md | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 community/working-groups/commons/README.md diff --git a/community/working-groups/commons/README.md b/community/working-groups/commons/README.md new file mode 100644 index 000000000..5fca93264 --- /dev/null +++ b/community/working-groups/commons/README.md @@ -0,0 +1,28 @@ +# Commons Working Group + +## Goals + +- Create a bridge for knowledge sharing between the STAG and other bodies within the Linux Foundation +- Seek opportunities to mitigate duplication of security efforts between bodies within the Linux Foundation +- Ensure hygiene recommendations for CNCF projects align closely with corresponding OpenSSF recommendations + +## Scope + +- Coordinate discussion between contributors from STAG and OpenSSF +- Highlight opportunities for the STAG to contribute to codebases, standards, and publications that may benefit the CNCF and/or STAG goals + +## Deliverables + +1. Aid in the creation of a universal open source project security baseline. +1. Contribute to the development of evaluation probes that can be used to evaluate Linux Foundation (and CNCF) projects against the universal open source project security baseline. + +## Meeting Information + +- **Meeting:** Every 2 weeks on Wednesday at 10:30 ET ([Calendar Invite](https://zoom-lfx.platform.linuxfoundation.org/meeting/98902119803?password=089ce577-a05d-4d3c-9caa-73f8bfd90e5c)) +- **Meeting Notes:** [Google Docs](https://docs.google.com/document/d/14xJf4c4ugjwmSmk-V49-_xPNaqZe771zI9qn95TN7ws/edit) + +## Contact + +- **Lead:** Eddie Knight +- **STAG Rep:** Marco De Benedictis +- **Slack Channel:** [Link](https://cloud-native.slack.com/archives/C07EX4ZU15Y) From b9132a0515908ac639c385c4377e2240f57730ae Mon Sep 17 00:00:00 2001 From: Vivek Radhakrishnan Date: Wed, 23 Oct 2024 13:12:31 -0400 Subject: [PATCH 5/6] Containerd Project Security Self-Assessment - Security Pals (#1202) * Bump postcss and autoprefixer in /website/themes/docsy/userguide (#1118) Bumps [postcss](https://github.com/postcss/postcss) to 8.4.31 and updates ancestor dependency [autoprefixer](https://github.com/postcss/autoprefixer). These dependencies need to be updated together. Updates `postcss` from 7.0.39 to 8.4.31 - [Release notes](https://github.com/postcss/postcss/releases) - [Changelog](https://github.com/postcss/postcss/blob/main/CHANGELOG.md) - [Commits](https://github.com/postcss/postcss/compare/7.0.39...8.4.31) Updates `autoprefixer` from 9.5.0 to 10.4.16 - [Release notes](https://github.com/postcss/autoprefixer/releases) - [Changelog](https://github.com/postcss/autoprefixer/blob/main/CHANGELOG.md) - [Commits](https://github.com/postcss/autoprefixer/compare/9.5.0...10.4.16) --- updated-dependencies: - dependency-name: postcss dependency-type: indirect - dependency-name: autoprefixer dependency-type: direct:development ... Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Signed-off-by: Nate-Smithline * Bump postcss from 8.4.20 to 8.4.31 in /website (#1120) Signed-off-by: Nate-Smithline * Created Self-Assessment of Containerd Project Signed-off-by: Nate-Smithline Co-authored-by: Vivek Radhakrishnan Co-authored-by: Swati Baleri Co-authored-by: Sunny Li Signed-off-by: Nate-Smithline * Removed template text and added more information for related vendors Signed-off-by: nomnomninja <150766910+nomnomninja@users.noreply.github.com> Signed-off-by: Nate-Smithline * fixed first comment and added more details on who authored the doc Signed-off-by: Nate-Smithline * Re-added the changes in actor section Signed-off-by: Sunny Li <100388296+sunnnnyli@users.noreply.github.com> * Fixed all changes from Andrew, aka sublimino, thank you Signed-off-by: Nate-Smithline * Fixed all changes from Andrew, aka sublimino, thank you Signed-off-by: Nate-Smithline * Update Containerd/self-assessment.md Co-authored-by: torinvdb <65670557+torinvdb@users.noreply.github.com> Signed-off-by: Raga * Update Containerd/self-assessment.md Co-authored-by: torinvdb <65670557+torinvdb@users.noreply.github.com> Signed-off-by: Raga * Corrected file location Signed-off-by: Eddie Knight --------- Signed-off-by: dependabot[bot] Signed-off-by: Nate-Smithline Signed-off-by: nomnomninja <150766910+nomnomninja@users.noreply.github.com> Signed-off-by: Sunny Li <100388296+sunnnnyli@users.noreply.github.com> Signed-off-by: Raga Signed-off-by: Eddie Knight Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Nate-Smithline Co-authored-by: Swati Baleri Co-authored-by: Sunny Li Co-authored-by: nomnomninja <150766910+nomnomninja@users.noreply.github.com> Co-authored-by: Sunny Li <100388296+sunnnnyli@users.noreply.github.com> Co-authored-by: Raga Co-authored-by: torinvdb <65670557+torinvdb@users.noreply.github.com> Co-authored-by: Justin Cappos Co-authored-by: Eddie Knight --- .../projects/containerd/self-assessment.md | 329 ++++++++++++++++++ 1 file changed, 329 insertions(+) create mode 100644 community/assessments/projects/containerd/self-assessment.md diff --git a/community/assessments/projects/containerd/self-assessment.md b/community/assessments/projects/containerd/self-assessment.md new file mode 100644 index 000000000..d229961f5 --- /dev/null +++ b/community/assessments/projects/containerd/self-assessment.md @@ -0,0 +1,329 @@ +# Containerd Self-assessment + +This assessment was created by community members as part of the [Security Pals](https://github.com/cncf/tag-security/issues/1102) process and is currently pending changes from the maintainer team. + +## Table of contents + +* [Metadata](#metadata) + * [Security links](#security-links) +* [Overview](#overview) + * [Actors](#actors) + * [Actions](#actions) + * [Background](#background) + * [Goals](#goals) + * [Non-goals](#non-goals) +* [Self-assessment use](#self-assessment-use) +* [Security functions and features](#security-functions-and-features) +* [Project compliance](#project-compliance) +* [Secure development practices](#secure-development-practices) +* [Security issue resolution](#security-issue-resolution) +* [Appendix](#appendix) + +## Metadata + + +| | | +| -- | -- | +| Assessment Stage | Incomplete | +| Software | [containerd](https://github.com/containerd/containerd) | +| Security Provider | No | +| Languages | Go, C++ | +| SBOM | [Packages](https://github.com/containerd/containerd/tree/main/pkg) [Versions](https://github.com/containerd/containerd/tree/main/version) | +| | | + + +### Security links + + +| Doc | url | +| -- | -- | +| Security file | https://github.com/containerd/project/blob/main/SECURITY.md | +| Default and optional configs | https://github.com/containerd/containerd/blob/main/docs/man/containerd-config.toml.5.md https://github.com/containerd/containerd/blob/main/docs/cri/config.md https://github.com/containerd/containerd/blob/main/docs/hosts.md | + + +## Overview + +Containerd is a container runtime focused on providing the core functionalities for managing container lifecycles. Specifically architected to focus on modularity and compatibility, it provides a secure and minimal approach making it a great option for integrating into different container orchestrators. + +![Overview Image](https://github.com/containerd/containerd/blob/main/docs/historical/design/architecture.png) + +### Background + +Containerd, a fundamental tool in the realm of containerization, provides a dependable and standardized approach to managing containers. It is a lightweight yet powerful container runtime, ensuring a consistent and efficient experience. + +Originally developed by Docker, Inc. as an integral part of the Docker project, containerd has evolved with the dynamic container ecosystem. Docker's decision to separate container runtime functionality from the runc project led to containerd, an independent project dedicated to container management. + +#### Core Features: + +**- Image and Container Management:** + +Containerd oversees the entire lifecycle of containers, handling tasks such as image storage, transfer, execution, and supervision. Its capabilities also extend to other essential operations like pushing, pulling, and managing container images. + +**- Pluggable Architecture:** + +Containerd boasts a modular and adaptable architecture, allowing for the assembly and reassembly of independent components. This flexibility caters to the diverse requirements of container environments. + +**- Security:** + +With a strong emphasis on security, Containerd implements features like user namespaces and seccomp profiles. These measures enhance container isolation, ensuring a robust security posture. + +**- Compatibility:** + +Aligned with the Open Container Initiative (OCI) specifications, containerd ensures compatibility with other runtimes and tools adhering to the OCI standard. This compatibility facilitates easy transitions between container runtimes supporting OCI. + +**- CLI and APIs:** + +Containerd provides well-defined APIs for programmatic interaction with container runtimes. Additionally, its Command-Line Interface (CLI) allows manual management of containers and images. + +**- Production Ready:** + +Widely adopted in multiple container orchestration platforms and cloud-native environments, Containerd has proven itself as a production-ready solution. Its reliability is evidenced by its integration into various deployments of containerized applications. + +**- Community and Governance:** + +As an open-source project under the Cloud Native Computing Foundation (CNCF), Containerd benefits from a diverse community of contributors. This collaborative approach ensures transparent decision-making, promoting inclusiveness and continuous improvement. + +### Actors + +**- Containerd Core:** + +Role: The core container orchestration engine, managing the complete container lifecycle. +Functionality: Coordinates tasks such as image storage, transfer, execution, and supervision. Ensures a consistent and efficient containerized application experience. +Isolation: Adopts a modular design, separating concerns to prevent unauthorized access and actions. Implements access controls to reinforce security. + +**- Container Runtimes:** + +Role: Executes containers based on specifications provided by containerd, interacting directly with the underlying operating system. +Functionality: Translates container configurations into running instances, ensuring compatibility and adherence to standards. +Isolation: Operates within well-defined boundaries, utilizing namespaces and cgroups for robust process and resource isolation. + +**- Image Registries:** + +Role: Repositories for container images, providing storage and retrieval for containerd in tasks such as image pulling, pushing, and metadata management. +Functionality: Stores and facilitates the distribution of container images, supporting seamless integration with containerd for efficient image management. +Isolation: Maintains a separate identity to prevent unauthorized modifications. Implements access controls to secure image repositories. + +### Actions + +**- Container Lifecycle Management:** + +Description: Orchestrates the complete lifecycle of containers, covering creation, initialization, termination, and removal. +Significance: Acts as the backbone of container orchestration, ensuring the smooth execution of containerized applications throughout their lifecycle. + +**- Image Operations:** + +Description: Manages various image-related operations, including pulling images from repositories, pushing images to registries, and handling image metadata. +Significance: Central to image management within the container ecosystem, enabling efficient distribution and storage of container images. + +**- Resource Isolation and Management:** + +Description: Enforces robust resource isolation for individual containers, including CPU, memory, and network resources. +Significance: Optimizes resource utilization, preventing interference between containers and ensuring performance isolation. + +**- Network Configuration:** + +Description: Configures and manages network settings for containers, facilitating communication and maintaining network isolation. +Significance: Ensures effective container communication while safeguarding against security vulnerabilities through proper network segmentation. + +**- Security Implementation:** + +Description: Implements comprehensive security measures within containers, covering access controls, encrypted communication, and permission management. +Significance: Strengthens the overall security posture of containerized applications, mitigating potential vulnerabilities and ensuring secure execution. + +### Goals + +**- Component Independence:** + +Components should not have tight dependencies on each other, allowing them to be used independently while maintaining a natural flow when used together. + +**- Primitives over Abstractions:** + +Containerd should expose primitives to solve problems instead of building high-level abstractions in the API. This allows flexibility for higher-level implementations. + +**- Extensibility:** + +Containerd should provide defined extension points for various components, allowing alternative implementations to be swapped. For example, it uses runc as the default runtime but supports other runtimes conforming to the OCI Runtime specification. + +**- Defaults:** + +Containerd comes with default implementations for various components, chosen by maintainers. These defaults should only change if better technology emerges. + +**- Scope Clarity:** + +The project scope is clearly defined, and any changes require a 100% vote from all maintainers. The whitelist approach ensures that anything not mentioned in scope is considered out of scope. + +### Non-goals + +**- Component Tight Coupling:** + +Components should not have tight dependencies, promoting independence. + +**- High-Level Abstractions in API:** + +Avoid building high-level abstractions in the API, focus on exposing primitives. + +**- Acceptance of Additional Implementations:** + +Additional implementations for core components should not be accepted into the core repository and should be developed separately. + +**- Build as a First-Class API:** + +Building images is considered a higher-level feature and is out of scope. + +**- Volume Management:** + +Volume management for external data is out of scope. The API supports mounts, binds, etc., allowing different volume systems to be built on top. + +**- Logging Persistence:** + +Logging persistence is considered out of scope. Clients can handle and persist container STDIO as needed. + +## Self-assessment use + +This self-assessment was authored by Swati Baleri, Vivek Radhakrishnan, Sunny Li, and Nathan Smith with a format established by the Containerd maintainers. The purpose of this document is to perform an internal analysis of the project's security. It is not intended to provide a security audit of Containerd, or function as an independent assessment or attestation of Containerd's security health. + +This document serves to provide Containerd users with an initial understanding of Containerd's security, where to find existing security documentation, Containerd plans for security, and general overview of Containerd security practices, both for development of Containerd as well as security of Containerd. + +This document provides the CNCF TAG-Security with an initial understanding of Containerd to assist in a joint-assessment, necessary for projects under incubation. Taken together, this document and the joint-assessment serve as a cornerstone for if and when Containerd seeks graduation and is preparing for a security audit. + +## Security functions and features + +#### Critical + +**- Namespaces:** + +Namespaces creates more security and efficiency by allowing multiple consumers to use the same containerd without conflicts. It has the benefit of separation of containers and images, while sharing content. Addionally, it keeps the designs as simple as it needs to be. + +**- Capabilities:** + +Containerd pushes toward a least-privilege process for managing access. This limits kernel capabilities for processes. Other systems with less least-privilege could create vulnerabilities and increase their attack surfaces. + +**- Isolation:** + +With its capability systems and namespaces, containerd provides industry standard resource isolation, ensuring the resources remain isolated and secured. Resource isolation is crucial for namespaces to function as intended and vice versa. + +**- Modularity:** + +Containerd allows people to use different container systems. This gives users of containerd authority over runtimes, but if not properly handled, could lead to severe access. + +#### Security Relevant + +**- Plug-ins:** + +Containerd is built with a modular architecture so that other technologies can be integrated to enable new capabilities. The advantage with containerd is that these plugins can enhance the functionality of the system without needing to rebuild the containerd itself. + +Popular systems include metadata, container managers, filesystem differentiators, and GRPC APIs. While this is a strength of Containerd, this modularity has been the culprit of most of its previous problems. This is mostly up to others and containerd has many times not handled these plugins correctly, leading to information being unnecessary leaked. In a way, one of its greatest strengths is its greatest security vulnerability. + +**- Network Security:** + +Containerd allows for network isolation, helping lockdown containers with network changes. This prevents unauthorzed communication, but needs to be monitored properly. + +**- Trust:** + +Containerd only stores identical content once, reducing risk of storing multiple copies of vulnerable content, thereby reducing the attack surface. If more things are uploaded, this needs to be monitored as it has a big effect on the attack surface. + +## Project compliance + +Containerd is not documented as meeting any major security standards except for having bypassed a test in fuzzing. The testing done by Adacompliance deemed that the fuzzing prevention was strong and with further testing was incredibly robust for industry application. + +It is reasonable to suggest its minimal framework could support CIS Benchmarks on least privilege and access control policies in ISO. However, there is no public documentation with proof to having matched any of these requirements. + +## Secure development practices + +**Development pipeline:** + +- Containerd contributors must sign commits to ensure contributor identity and prevent unauthorized code changes. +- Containerd images are immutable and signed. Additionally, all images are signed with a GPG key, which helps to verify the authenticity of the image. +- Continuous integration and deployment pipelines automatically test all changes in Containerd, enabling prompt issue detection. +- The open-source code, hosted on GitHub, encourages transparency and community involvement in reviews, aiding in early issue detection. +- All pull requests to the containerd codebase must be reviewed by at least two reviewers before they can be merged. +- Compliant with industry standards, including NIST SP 800-190 and CIS Docker Benchmark, Containerd prioritizes security and reliability benchmarks. It integrates with image scanning tools (Clair, Synk, Trivy, etc.), promoting trusted image registries. +- Containerd employs privilege-dropping techniques, supports Seccomp profiles, and can operate in unprivileged user mode to minimize attack surfaces and limit security impact. +- Resource quotas and cgroups enforce fair resource allocation, preventing resource exhaustion attacks in Containerd. +- TLS encryption safeguards data exchange, and secure networking configurations and communication protocols protect against unauthorized access. +- The use of secure communication protocols, such as HTTPS, when communicating with external services to protect data from exposure is also promoted. +- Security audits occur regularly (CNCF fuzzing audit, community-driven audits, etc.) complemented by a responsible disclosure policy for discreetly reporting and addressing security issues before public disclosure. +- Containerd releases updates with security patches, performance enhancements, and bug fixes, while comprehensive [documentation](https://containerd.io/docs/) guides secure deployment. + +**Communication Channels:** + +- *Internal*: The Containerd team mostly communicates with each other through Slack, GitHub, or email lists internally. +- *Inbound*: Prospective and existing users can communicate with the Containerd team through GitHub issues, mailing lists, or the dedicated Slack channel. +- *Outbound*: The containerd team communicates with its users through the containerd blog, social media channels such as Twitter and GitHub, and through mailing lists. + +**Ecosystem:** + +Containerd plays a pivotal role in the cloud-native ecosystem due to its core functionality as a lightweight container runtime, its integration with various container orchestration platforms, and its active participation in open-source projects. This makes it an essential component for building, deploying, and managing scalable and reliable cloud-native applications. + + +## Security issue resolution + +**- Responsible Disclosures Process**: + +The responsible disclosure process for containerd is designed to manage the identification of security issues, incidents, or vulnerabilities, whether discovered internally or externally. If a security issue is found within the project team, it is reported using the same procedures as external reports. External discoveries are encouraged to follow a responsible disclosure process, which involves reporting the issue either on GitHub or via email. GitHub is the primary platform, allowing individuals to navigate to the security tab, access the Advisories tab, and use the "Report a vulnerability" option. Alternatively, an email can be sent to security@containerd.io, including details of the issue and steps to reproduce. Reporters should anticipate an acknowledgment within 24 hours and are advised to contact any committer directly if there's no response. + +**- Vulnerability Response Process**: + +The responsibility for responding to a reported vulnerability rests with the committers of containerd. Once a committer confirms the relevance of the reported vulnerability, a draft security advisory is created on GitHub. Reports can be submitted through GitHub or via email to security@containerd.io. Reporters interested in participating in the discussion can provide their GitHub usernames for an invitation. Alternatively, they can opt to receive updates via email. If the vulnerability is accepted, a timeline for developing a patch, public disclosure, and patch release is established. In cases where an embargo period precedes public disclosure, an announcement is sent to the security announce mailing list, detailing the vulnerability scope, patch release date, and public disclosure date. Reporters are expected to engage in the discussion of the timeline and adhere to agreed-upon dates for public disclosure. + +**- Incident Response**: + +Defined procedures are in place for triaging reported vulnerabilities, assessing their severity and relevance. The confirmation process involves validating the reported vulnerability to determine its authenticity and impact. If the vulnerability is confirmed, the involved parties, including the reporter(s), are notified. A timeline for developing a patch and making updates available is determined. Depending on the embargo period, the vulnerability and patch release details are publicly disclosed using the security announce mailing list. Reporters are expected to comply with agreed-upon dates for public disclosure, ensuring a responsible and coordinated release of information. This process ensures a systematic and transparent approach to handling security issues, promoting responsible disclosure, and achieving timely resolution. + +## Appendix + + +* Known Issues Over Time: + + There have been some problems in the past with the plugins that containerd has. Even though it is a feature, it has led to problems when the plugins are not correctly inputted. + - https://github.com/containerd/containerd/pull/7347 + - https://github.com/containerd/containerd/pull/8056 + + There is also a few issues with its ability to access resources. In attempt to keep least-privilege access, the dulling out when available can be problematic + - https://github.com/containerd/containerd/issues/3351 + - https://www.cvedetails.com/cve/CVE-2023-25153/ + - https://www.cvedetails.com/cve/CVE-2022-31030/ + - https://www.cvedetails.com/cve/CVE-2022-23471/ + - https://www.cvedetails.com/cve/CVE-2021-32760/ + + +* Record in catching issues in code review or automated testing: + + **Current Level: [![OpenSSF Best Practices](https://www.bestpractices.dev/projects/1271/badge)](https://www.bestpractices.dev/projects/1271)** + + The project achieved the following + - Basics: 13/13 passed + - Change Control: 9/9 passed + - Reporting: 8/8 passed + - Quality: 13/13 passed + - Security: 16/16 passed + - Analysis: 8/8 passed + + +* Case Studies: + + [Demonstrates how Red Hat OpenShift, integrated with containerd, streamlines containerization adoption and simplifies Kubernetes management.](https://swapnasagarpradhan.medium.com/install-a-kubernetes-cluster-on-rhel8-with-conatinerd-b48b9257877a) + + [Explores how containerd simplifies container management on Google Kubernetes Engine (GKE), Google Cloud's fully managed Kubernetes service.](https://cloud.google.com/kubernetes-engine) + + [Delves into the integration of containerd with Amazon Elastic Container Service (ECS), Amazon Web Services' container orchestration service](https://aws.amazon.com/blogs/containers/tag/containerd/) + + [Explores how containerd enables organizations to effectively manage containers on Azure Kubernetes Service (AKS), Microsoft Azure's managed Kubernetes service](https://azure.microsoft.com/en-us/updates/generally-available-containerd-support-for-windows-in-aks/) + +* Related Projects / Vendors: + + Docker uses Containerd for Container management, it offers complete container management service such as image building, user interface and a built-in runtime. + + https://www.docker.com/products/container-runtime/ + https://humalect.com/blog/containerd-vs-docker/ + https://www.wallarm.com/cloud-native-products-101/containerd-vs-docker-what-is-the-difference-between-the-tools/ + + Cri-o and containerd are both container runtimes, but they serve different purposes and have different relationships with Kubernetes. Cri-o is designed specifically for Kubernetes and has a smaller footprint, which is optimized for resource usage within Kubernetes. It leverages containerd's core functionalities for image management and execution, but adds Kubernetes-specific features and optimizations. + + https://cri-o.io/ + + + + + + From 9d1e5629535c0e42e84f0f417f1ab571b75f891a Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Mon, 28 Oct 2024 16:06:31 -0400 Subject: [PATCH 6/6] fix formatting (#1393) Signed-off-by: Marina Moore --- community/publications/paper-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/community/publications/paper-process.md b/community/publications/paper-process.md index 1f440b445..452f3a507 100644 --- a/community/publications/paper-process.md +++ b/community/publications/paper-process.md @@ -90,7 +90,7 @@ The paper lead creates a README.md with: - Original design decisions - Links to files in the repo -### Blog Publishing and Coordination +#### Blog Publishing and Coordination Coordinate with TAG leadership and CNCF for a blog post to increase visibility. Consider presenting at community events.