Skip to content
This repository was archived by the owner on Dec 18, 2025. It is now read-only.
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
273 changes: 273 additions & 0 deletions community/assessments/projects/podman/self-assessment.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,273 @@
<!-- cSpell:ignore Buildah crun Daemonless daemonless fedoraproject golangci libpod Skopeo -->
# Podman Self-assessment

## 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 | [https://github.com/containers/podman](https://github.com/containers/podman) | | Security Provider | No | | Languages | Go | | SBOM | [https://github.com/containers/podman/blob/main/go.mod](https://github.com/containers/podman/blob/main/go.mod) |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming this is intended to cover podman container tools and not podman desktop?

If so, I think this should go in https://github.com/cncf/toc/tree/main/projects/podman-containers or the like, rather than in the tag-security repo. We've been asked to concentrate project-related content under each project's directory there, rather than potentially scattering due diligence related content across multiple repos.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@evankanderson ack will do, so btw, we'll need to add similar self-assessments for the buildah and skopeo projects as well. So, just wondering about the directory structure. Should it be projects/podman-containers/[buildah,podman,skopeo] with each subdir having its own self-assessment or just have self-assessments right
under the podman-containers dir?

We'll address the other comments in the new PR.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the podman assessment, you should probably keep this at a level of abstraction where you don't need to recurse into these. Mentioning their properties at a higher level / abstracting them out into sections of this document makes sense.

However, both are standalone and it looks like skopeo is used outside of Podman, etc. So you can roughly scope them separately. If you wanted to do a separate assessment for each (which would be fine), we'd just treat them like different projects that have podman as a popular use case.

Feel free to reach out on Slack if this isn't clear and we can discuss.

Comment thread
lsm5 marked this conversation as resolved.
Outdated

### Security links

| Doc | url |
| :---- | :---- |
| Security file | [https://github.com/containers/podman/blob/main/SECURITY.md](https://github.com/containers/podman/blob/main/SECURITY.md) |

## Overview

Podman (the POD MANager) is a daemonless container engine for developing, managing, and running OCI containers and pods. Podman emphasizes security by enabling rootless containers, providing fine-grained security controls, and operating without a daemon process.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't see a reference here -- do you have a threat model? A threat model is not required for a self-assessment, but can be helpful in understanding what is "in" and "out" of bounds as a security vulnerability.

I'm guessing here that "kubelet runs a Pod which can escape container and control host via namespace mounts" is out of bounds (kubelet is trusted by design), whereas "local non-root user can manage a container started by another user" would be a vulnerability (user-level host isolation should be effective). That's my own guess, though -- if you already have a set of trusted / untrusted actors, that would be helpful for the joint assessment.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll be preparing a threat model document soon. For now, container escapes are our biggest concern. Another concern would be a user setting security options and those not being correctly applied. A user intentionally pulling and running a malicious container image is out of scope.

Can we defer this until the joint-assessment? I'd be happy to revise the language here (in the new PR) if need be.


### Background

Podman is a container management tool that provides a command-line interface for managing containers, images, and pods. Podman runs without a daemon and supports rootless containers, providing an additional layer of security for many use cases.

Key characteristics:

- **Daemonless**: No background daemon process, reducing attack surface
- **Rootless**: Containers can run without root privileges
- **Pod support**: Native support for Kubernetes-style pods
- **Security-focused**: Built with security as a primary concern
Comment on lines +47 to +50

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit more of marketing-speak and is not really qualitative in many cases. Can you more directly express the architecture, use cases, etc. as a way of saying the properties instead?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

revised in the TOC PR.


Podman is part of the containers ecosystem and integrates with other tools like Buildah, Skopeo, and CRI-O.

### Actors

* **Podman CLI**: The main command-line interface that users interact with. It parses commands and coordinates with other components.

* **libpod library**: The core library that provides container lifecycle management APIs. It handles container creation, execution, and management.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is libpod expected to be used by external components that want to interact with Podman, or is it common functionality for the components listed here, but not intended for external use?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

libpod isn't directly used by external components, the intended way to interact with Podman is the REST API exposed by podman system service. Let me know if this should be changed likewise.


* **Container runtime**: Interfaces with OCI-compliant runtimes (runc, crun) to actually run containers.

* **Image store**: Manages container images and their metadata. Images are stored in a local registry and can be verified for integrity.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When does verification happen? Why is this optional?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image verification happens without exception during an image pull from the registry. Once an image is in local storage, a user can also verify integrity using subcommands like podman inspect. I'll add the image pull part in the TOC PR. Does that help?


* **Container storage**: Manages container filesystems and layers.

* **Network configuration**: Handles container networking, including rootless networking and port forwarding.

* **Systemd integration**: Provides systemd services and pod management.

* **Rootless mode**: Podman can be run in rootless mode, protecting against possible attacks like container escapes allowing control of the entire system.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When would people run it rootless and when as root? What is the default? How do users decide?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rootless has some limitations, documented in https://github.com/containers/podman/blob/main/rootless.md . Will update the wording in the new PR.


### Actions

* **Container creation**:

- Validates container configuration and security options
- Sets up namespaces and cgroups for isolation
- Configures security policies (seccomp, SELinux, capabilities)
Comment on lines +77 to +78

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how is this done? What is surfaced to the user?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The container-selinux and container-libs project under the containers github org ship a default selinux policy and seccomp profile respectively, often packaged by the distro. These can be tuned further by the user via the --security-opt CLI option. Also capabilities can be modified using the --cap-add / --cap-drop CLI options.

- Creates rootless user namespace mapping

* **Image pulling**:

- Verifies image signatures and checksums
- Validates image layers and metadata
- Stores images in a secure local registry

* **Container execution**:

- Applies security policies (seccomp, SELinux, capabilities)
- Sets up proper user namespaces for rootless operation
- Monitors container process and resource usage

* **Pod management**:

- Creates shared network namespace for pod containers
- Manages pod-level security policies
- Coordinates container lifecycle within pods

* **Volume management**:

- Creates and mounts volumes with appropriate permissions
- Handles rootless volume mounting
- Applies SELinux labels to volumes

### Goals

* **Rootless operation**: Enable users to run containers without root privileges, reducing the attack surface and potential for privilege escalation.

* **Daemonless architecture**: Eliminate the daemon process to reduce attack surface and improve security posture.

* **Security by default**: Provide secure defaults for container execution, including appropriate seccomp profiles, SELinux policies, and capability restrictions.

* **OCI compliance**: Maintain compatibility with OCI specifications for containers and images to ensure interoperability.

* **Pod support**: Enable Kubernetes-style pod management with proper security isolation.

### Non-goals

* **Orchestration**: Podman does not provide cluster orchestration capabilities (that's handled by Kubernetes, OpenShift, etc.).

* **Image registry**: Podman does not operate as a centralized image registry, though it can interact with various registries.

* **Container runtime**: Podman does not implement the low-level container runtime (it uses crun, runc etc..).

* **Storage management**: Podman does not provide distributed storage solutions, only local container storage.

* **Security scanning**: While Podman can work with security scanning tools, it does not provide built-in vulnerability scanning.

## Self-assessment use

This self-assessment is created by the Podman team to perform an internal analysis of the project's security. It is not intended to provide a security audit of Podman, or function as an independent assessment or attestation of Podman's security health.

This document serves to provide Podman users with an initial understanding of Podman's security, where to find existing security documentation, Podman plans for security, and general overview of Podman security practices, both for development of Podman as well as security of Podman.

This document provides the CNCF TAG-Security with an initial understanding of Podman 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 Podman seeks graduation and is preparing for a security audit.
Comment thread
lsm5 marked this conversation as resolved.
Outdated

## Security functions and features

### Critical Security Components

* **Rootless containers**: Podman's core security feature that allows containers to run without root privileges, significantly reducing the attack surface and preventing privilege escalation attacks.

* **User namespaces**: Provides process isolation by mapping container user IDs to host user IDs, enabling secure rootless operation.

* **Seccomp profiles**: Default seccomp profiles restrict system calls available to containers, preventing many potential attack vectors.

* **SELinux integration**: Automatic SELinux labeling and enforcement for containers, volumes, and images to provide mandatory access control.

* **Capability dropping**: Removes unnecessary Linux capabilities from containers by default, following the principle of least privilege.

* **Daemonless architecture**: Eliminates the daemon process, reducing the attack surface and preventing daemon-based attacks.

### Security Relevant Components

* **Image signing and verification**: Support for container image signatures using GPG/Sequoia and other signing mechanisms.

* **Resource limits**: CPU, memory, and I/O limits to prevent resource exhaustion attacks.

* **Network policies**: Configurable network isolation and firewall rules for container networking.

* **Volume security**: Secure volume mounting with proper permissions and SELinux labels.

* **Pod security policies**: Pod-level security controls that apply to all containers within a pod.

## Project compliance

* **OCI Compliance**: Podman is fully compliant with the Open Container Initiative (OCI) specifications for containers and images.

* **CIS Docker Benchmark**: Podman provides security benchmarking tools that align with the Center for Internet Security (CIS) Docker Benchmark.

* **FIPS 140-2**: Podman supports FIPS 140-2 compliant cryptographic modules when running on FIPS-enabled systems.

* **SELinux**: Full integration with SELinux for mandatory access control compliance.

* **AppArmor**: Support for AppArmor profiles for additional access control.

## Secure development practices

### Development Pipeline

* **Code Review Process**: All code changes typically require review by two maintainers before merging. Critical security changes may require multiple reviews. The project uses GitHub pull requests for all contributions.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why typically? Why not always?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that was a mixup on my part. Code changes are always double-lgtm'd. It's only clean backports from main to release branches, auxiliary changes, trivial doc changes that aren't always double-lgtm'd, though if that needs to be enforced, that certainly could be done. I'll fix this in the new PR.


* **Automated Testing**: Comprehensive test suite including unit tests, integration tests, and security-focused tests that run on every pull request. A comprehensive e2e and system test suite is run in CI on every PR and also on a nightly basis.

* **Security Scanning**: Automated vulnerability scanning of dependencies using tools like Dependabot and GitHub Security Advisories. All medium and higher severity exploitable vulnerabilities are fixed in a timely way after they are confirmed.

* **Static Analysis**: Code quality and security analysis using golangci-lint which is run on every PR, ensuring testing is done prior to merge.

* **OpenSSF Best Practices Compliance**: Podman has achieved a [passing OpenSSF Best Practices badge](https://www.bestpractices.dev/projects/10499), demonstrating adherence to security best practices including proper licensing, contribution guidelines, and security processes.

### Communication Channels

* Podman user room: [\#podman:fedoraproject.org](https://matrix.to/#/#podman:fedoraproject.org)

* Podman dev room: [\#podman-dev:matrix.org](https://matrix.to/#/#podman-dev:matrix.org)

* **Inbound**:

- GitHub Issues for bug reports and feature requests
- GitHub Discussions for community questions
- Security issues via the security mailing list
- Mailing lists for formal discussions
- Clear contribution guidelines documented in [CONTRIBUTING.md](https://github.com/containers/podman/blob/main/CONTRIBUTING.md)

* **Outbound**:

- Release announcements via the [official Podman website](https://podman.io), GitHub releases, and the Podman mailing list
- Documentation updates and blog posts
- Conference presentations and talks
- Project website at [podman.io](https://podman.io) with comprehensive documentation

### Ecosystem

Podman is a critical component of the cloud-native ecosystem:

* **Container Ecosystem**: Integrates with Buildah for building containers, Skopeo for image and registry operations.

* **Development Tools**: Widely used in development environments as a secure alternative to Docker.

* **CI/CD Pipelines**: Used in CI/CD systems for testing containerized applications.

## Security issue resolution

### Responsible Disclosures Process

* **Reporting**: Security vulnerabilities should be reported by email as documented in the [SECURITY.md](https://github.com/containers/podman/blob/main/SECURITY.md) file.

* **Response Time**: The team commits to responding to vulnerability reports within 48 hours. All medium and higher severity exploitable vulnerabilities are prioritized as a matter of general practice.

* **Credit**: Security researchers who responsibly disclose vulnerabilities are credited in security advisories and release notes.

* **Public Disclosure**: Vulnerabilities are disclosed by the project maintainers with appropriate embargo periods for critical issues, following industry best practices for responsible disclosure.

### Vulnerability Response Process

* **Triage**: Security reports are triaged by the project maintainers and assigned severity levels (Critical, High, Medium, Low) using CVSS scoring where applicable.

* **Investigation**: The team investigates the vulnerability, determines impact, and develops fixes. All medium and higher severity exploitable vulnerabilities discovered through static or dynamic analysis are fixed in a timely way after they are confirmed.

* **Fix Development**: Security fixes for embargoed CVEs are developed in private repositories to prevent premature disclosure.

* **Disclosure**: Vulnerabilities are disclosed by the project maintainers with appropriate embargo periods for critical issues. The project follows industry best practices for coordinated vulnerability disclosure.

### Incident Response

* **Detection**: Tools like Renovate automatically update dependencies, including fixes for security issues.

* **Assessment**: The team assesses the severity and impact of security incidents using CVSS scoring and industry-standard severity classification.

* **Containment**: Immediate steps are taken to contain and mitigate the impact of security incidents. If the tests point out any issues in the development phase, those get fixed before any code is merged.

## Appendix

### Known Issues Over Time

* See [this NIST Vulnerability Database list](https://nvd.nist.gov/vuln/search#/nvd/home?vulnRevisionStatusList=published&offset=0&rowCount=50&keyword=podman&resultType=records) for CVEs to date. This includes issues in the Go toolchain and dependencies used by Podman.
(Four of the entries as of the date of this writing aren't directly related to Podman but contain Podman in the search terms.)

### OpenSSF Best Practices

* **Current Status**: Podman has achieved a [passing OpenSSF Best Practices badge](https://www.bestpractices.dev/projects/10499) (100% compliance), demonstrating adherence to security best practices.

* **Key Achievements**:

- Comprehensive project documentation and contribution guidelines
- Robust security testing and analysis processes
- Clear vulnerability disclosure and response procedures
- Strong development practices with code review and automated testing
- Proper licensing and project governance

### Case Studies

* List of companies and organizations using / shipping Podman [https://github.com/containers/podman/blob/main/ADOPTERS.md](https://github.com/containers/podman/blob/main/ADOPTERS.md)

### Related Projects / Vendors

* **Buildah**: A tool that facilitates building OCI container images.

* **Skopeo**: A command line utility to perform various operations on container images and image repositories like copying an image, inspecting a remote image, deleting an image from an image repository.