-
Notifications
You must be signed in to change notification settings - Fork 577
Add Podman security self-assessment #1498
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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) | | ||
|
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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
|
|
||
| * **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. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When does verification happen? Why is this optional?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
|
|
||
| * **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. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. how is this done? What is surfaced to the user?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The container-selinux and container-libs project under the |
||
| - 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. | ||
|
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. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why typically? Why not always?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
There was a problem hiding this comment.
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-securityrepo. 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.There was a problem hiding this comment.
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
buildahandskopeoprojects as well. So, just wondering about the directory structure. Should it beprojects/podman-containers/[buildah,podman,skopeo]with each subdir having its own self-assessment or just have self-assessments rightunder the
podman-containersdir?We'll address the other comments in the new PR.
There was a problem hiding this comment.
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.