---
# System prepended metadata

title: podman in openshift 4.11

---

# podman in openshift 4.11

A [recent change](TODO) was made to [CRI-O](github.com/cri-o/cri-o) that applied a seccomp profile by default for all pods, as well as dropped the `unshare` syscall. Both of these are huge wins for security. Having a default seccomp profile that doesn't include `unshare` allows nodes to be protected against [privilege escalations that come from unshare](TODO). However, a consequence of that change is that it is now tricker to use podman in a container, because it requires `unshare`. 

If a user on a cluster would like to use podman in a container (and is not granted access to the privileged SCC), an admin must configure a special SCC for them:

```yaml
kind: SecurityContextConstraints
apiVersion: security.openshift.io/v1
metadata:
  name: podman
seccompProfiles:
  - "localhost/profiles/unshare.json"
runAsUser: # required for API validation
  type: MustRunAs
seLinuxContext: # required for API validation
  type: MustRunAs
```

This SCC mirrors the `restricted` SCC, aside from giving access to the `unshare.json` seccomp profile. This profile is the same as the one CRI-O ships by default, except it also adds `unshare`. Users who previously specified RuntimeDefault for their pods will recognize it as the default profile before 4.11.

Then, a user who would like to use podman only has to do:
```
apiVersion: v1
kind: Pod
metadata:
 name: no-priv
spec:
 containers:
   - name: no-priv
     image: quay.io/podman/stable
     args:
       - sleep
       - "1000000"
     securityContext:
       capabilities:
         add:
           - "SYS_ADMIN"
           - "MKNOD"
           - "SYS_CHROOT"
           - "SETFCAP"
       seccompProfile:
         type: Localhost
         localhostProfile: unshare.json
     resources:
       limits:
         github.com/fuse: 1
```

Note, this pod yaml was adapted from [this](https://www.redhat.com/sysadmin/podman-inside-kubernetes) article.