Add Podman security self-assessment #1498
Conversation
✅ Deploy Preview for tag-security ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
lsm5
force-pushed
the
podman-self-assessment
branch
2 times, most recently
from
55654d4 to
3d29a60
Compare
Signed-off-by: Lokesh Mandvekar <[email protected]>
lsm5
force-pushed
the
podman-self-assessment
branch
from
3d29a60 to
b0c67d5
Compare
JustinCappos
left a comment
JustinCappos
left a comment
There was a problem hiding this comment.
I've listed a few minor things you might want to clean up before getting this merged. Feel free to push back or discuss anything I mentioned with me.
| - **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 |
There was a problem hiding this comment.
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?
|
|
||
| * **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. |
There was a problem hiding this comment.
When does verification happen? Why is this optional?
There was a problem hiding this comment.
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?
|
|
||
| * **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. |
There was a problem hiding this comment.
When would people run it rootless and when as root? What is the default? How do users decide?
There was a problem hiding this comment.
rootless has some limitations, documented in https://github.com/containers/podman/blob/main/rootless.md . Will update the wording in the new PR.
| - Sets up namespaces and cgroups for isolation | ||
| - Configures security policies (seccomp, SELinux, capabilities) |
There was a problem hiding this comment.
how is this done? What is surfaced to the user?
There was a problem hiding this comment.
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.
|
|
||
| ### 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. |
There was a problem hiding this comment.
Why typically? Why not always?
There was a problem hiding this comment.
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.
evankanderson
left a comment
evankanderson
left a comment
There was a problem hiding this comment.
A few low-priority comments, and one higher-priority comment that this should probably be PR'ed to https://github.com/cncf/toc under the projects/ sub-directory. From a quick glance, this would be the first material from this project in that directory, so welcome to the (new way of doing things in) the CNCF!
|
|
||
| ## 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) | |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
|
|
||
| * **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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
|
|
||
| ## 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Evan Anderson <[email protected]> Signed-off-by: Lokesh Mandvekar <[email protected]>
Co-authored-by: Justin Cappos <[email protected]> Signed-off-by: Lokesh Mandvekar <[email protected]>
|
All comments should be addressed in cncf/toc#1953 . PTAL. I'll close this PR. Thanks for the reviews!! |
3 participants
No description provided.