knowledge/sysadmin/podman.md

# Using Podman with SELinux
- SEL confines container processes to system_u:system_r:container_t:s0 domain
- File perms for volumes must be system_u:object_r:container_file_t:s0
- This can be done easily by appending `:z` to volume mappings during container creation
	- Example: `-v /opt/docker/vw-data:/vw-data/:z`

# Sources
https://blog.christophersmart.com/2021/01/31/podman-volumes-and-selinux/

---
# Book Notes: Podman In Action

## Definitions
- container orchestrator - orchestrate conatiners onto multiple machines or nodes; primary CO is Kubernetes; often interacts with a separate container engine
	- examples: Kubernetes, Docker Swarm, Apache Mesos
- container engine - contfigures containerized apps to run on a single node
	- examples: Podman, Docker, containerd, CRI-O, buildah
- Open Container Initiative container runtimes - configure parts of the linux kernel and launch the containerized app
	- examples: runc, crun, Kata, gVisor
- pod - multiple containers sharing the same namespaces and cgroups
- cgroups - control groups; linux kernel feature; allows processes to be put in hierarchical groups to limit and monitor resource usage
- namespaces - virtualized environments where different processes see different sets of resources
	- examples: network namespace, mount namespace, PID namespace
- skopeo - tool to inspect containers?
- container image - a committed container


## Podman 
- supports images in OCI, docker v2, and docker v1 formats
- supports all OCI runtimes
- supports rootless containers


## Containers 
- groups of processes running on a linux system; isolated from one another
- prevents processes from interfering with other processes
- prevents processes from dominating system resources
- allows installations to use specific shared libraries
- isolated using resource constraints, security constraints, namespaces
	- security constraints include SELinux, RO-access to filesystems, user namespaces, seccomp
- simplifies software distribution; correct dependencies are already there

## Container Image Format
1. Directory tree containing all software required to run the application
2. JSON file to describe the rootfs
	- laid out like it was the root of a linux filesystem
3. JSON file to link multiple images together to support different architectures

## Rootless Containers
- docker requires root; podman does not
	- command to gain root privileges if the user is in the docker group: `docker run -ti --name hacker --privileged -v /:/host ubi8  chroot /host`
	- command to erase evidence of activities: `docker rm hacker`
		- this includes logging if docker's default logging config is used
	- docker *can* be run rootless, but it's rare to do so due to the additional configuration required
- podman containers are owned by the user and have no addition privileges compared to that user
	- even on container escape, there are no additional privileges

## Fork/Exec Model
- docker is client/server model with multiple daemons
	- server runs setup steps, then acts as a communication layer back to client
	- docker daemon, containerd daemon, etc; if any fail, all containers stop

## Systemd Integration
- podman aims for integration with systemd
	- support systemd within containers
	- socket activation
	- systemd notifications
	- systemd management of cgroups

## Pods
- shared storage/network resources
- supports kubernetes YAML via `podman generate kube` and `podman play kube`
- allows multiple microservice containers to be combined into a larger service pod

## Podman Container Customizability
- allows container defaults to be overridden
- multiple configuration files (distibution-level, system-level, user-level)
- allows more or less security depending on need

## User-namespace Support
- allows multiple UIDs to be assigned to a user
- allows isolation between processes from the same user

# Podman Commands
(all commands should be prefixed with `podman`)
- `run <image>` - pull image and execute in the foreground until exit
- `run -ti <image> <command>` - run the command in the specified image in interactive mode
- `run --rm` - delete container upon exit
- `run -d` - detach from the container and run it in the background
- `run -p <host_port>:<container_port>` - publish the container's internal port to the external host
	- in rootless mode, only host ports below 1024 are usable
- `run --name <name>` provides a name for the container
	- if a name is not specified, a unique name is generated
- `run --user <username>` - run as a specific user in the image
- `create <image>` - pull the image and build it, but don't execute
	- has near-identical flags to `run`
- `start` - start a built image
- `inspect` - get information about a container/image/network/etc
	- most items have a specific `inspect` command for their type
		- `podman image inspect`
		- `podman container inspect`
		- etc
- `commit` - create new image from current container state
	- **should only be run while a container is stopped**
	- not the most common method compared to podman build
- `push` - push image to registry
- `login <registry>` - log in to a registry to do push/pull actions
	- by default, credentials are stored in /run/user/\<uid\>/containers/auth.json as a base64-encoded string
		- credentials are cleared on reboot
	- other options for storing passwords are available
- `image prune` - remove images without a tag
	- `image prune -a` - remove all images not in use by a container
- `image mount` - mount an images root filesystem as read-only
	- cannot be done in rootless mode
- `unshare` - enter user amd mount namespaces
- `build` - build a container using Dockerfile or Containerfile

## Container Images
- containers are not the same as images
- images are committed containers
- "images" usually refers to content stored in container storage or in a container registry
- stored as a series of layers

### Image Tagging
- allows adding additional names ot images

### Image Mounting
```
podman unshare
mnt=$(podman image mount <imagename>)
ls $mnt
podman image unmount <imagename>
exit
```

## Image Building; Containerfiles
- docker has Dockerfile; podman has Containerfile (and Dockerfile)
- Containerfiles contain two types of directives
	- adding content to the container image
	- describing and documenting image use

### Containerfile directives

```
# FROM specifies the container to base the image off of
# FROM scratch # start with no content at all
FROM registry.access.redhat.com/ubi8 # start from the ubi8 image

# COPY copies files, directories, or tarballs into the new rootfs
# ADD provides the same function, but supports remote URLs as well
# VOLUME will create a folder that is marked as holding externally-mounted volumes

# RUN runs a command on the image during building
# commonly used for package management tools
RUN yum -y update
RUN yum -y install procps-ng
RUN yum -y clean all
# install "ps" command and clean up cruft from yum

# CMD runs a command if a different command is not specified
# ENTRYPOINT allows container to run as an executable

# ENV defines environment variables

# EXPOSE announces ports that will be opened
# **but** it does not actually map or open any ports

# LABEL adds metadata
# MAINTAINER sets author of image

# STOPSIGNAL defines the signal to send to the container for exit

# USER defined the user name (and group name) for subsequent RUN/CMD/ENTRYPOINT directives
# WORKDIR sets the working directory for subsequent RUN/CMD/ENTRYPOINT/COPY directives

# ONBUILD adds a trigger to use if the image is being used as a base for another build
```

## Volumes
- `volume rm <name>` - remove volume
- `volume list` - list all volumes
- `volume export` - export contents of volume to TAR archive
- `volume import` - import TAR as volume

### Why volumes?
- separate applications from data
- have the same image in multiple environments
- reduce overhead of read/write performance
- share content via network storage

### Flags
- flags are placed after the volume mapping
	- `-v ./html:/var/www/html:ro`
- flags can be combined with commas
	- `-v ./html:/var/www/html:ro,z`
- `:ro` - mount as read-only
- `:z` - recursively relabel content for use by SELinux, allows multi-container access
- `:Z` - recursively relabel content for use by SELinux, disallows multi-container access
	- `--security-opt label=disable` can be used to run containers with an "unconfined" label, if needed (but not recommended)
- `:U` - change ownership of volume to match UID in container
- `:O` - mount as temporary storage, destroyed when finished executing


### Named Volumes
- `podman volume crate <name>`
- defaults to locally named volumes
	- creates a directory for named volumes
- can be used by multiple containers at once

## Pods
- comes from the Kubernetes project
- allows one or more containers to share namespaces and cgroups
- ensured shared SELinux labels

- all pods ahve a container called the *infra* or *pause* container to hold open namespaces/cgroups
- pods can optionally have *init* containers that run before the primary containers are executed
	- can run either once on pod creation, or every time the pod is started
- "sidecar containers" are just other containers in the pod
	

### conmon
- container monitoring process
- added to every container that is in a pod
- lightweight C executable that monitors pod until exit
- executes OCI runtime
- responsible for reporting error code back to Podman
- provides socket for STDOUT and STDERR


fdsafdsa