README.md: update BuildKit/img comparison (#642)

Latest BuildKit/img no longer necessarily requires procMount to be unmasked, by
 not unsharing PID namespaces.

The current drawback of BuildKit/img compared to kaniko is that BuildKit/img
requires seccomp and AppArmor to be disabled so as to create nested containers.

moby/buildkit#768
genuinetools/img#221

Signed-off-by: Akihiro Suda <[email protected]>

README.md

@@ -450,6 +450,7 @@ You may be able to achieve the same default seccomp profile that Docker uses in
 
 Similar tools include:
 
+- [BuildKit](https://github.com/moby/buildkit)
 - [img](https://github.com/genuinetools/img)
 - [orca-build](https://github.com/cyphar/orca-build)
 - [umoci](https://github.com/openSUSE/umoci)
@@ -459,10 +460,10 @@ Similar tools include:
 
 All of these tools build container images with different approaches.
 
-`img` can perform as a non root user from within a container, but requires that
-the `img` container has `RawProc` access to create nested containers.  `kaniko`
-does not actually create nested containers, so it does not require `RawProc`
-access.
+BuildKit (and `img`) can perform as a non root user from within a container, but requires
+seccomp and AppArmor to be disabled to create nested containers.  `kaniko`
+does not actually create nested containers, so it does not require seccomp and AppArmor
+to be disabled.
 
 `orca-build` depends on `runc` to build images from Dockerfiles, which can not
 run inside a container (for similar reasons to `img` above). `kaniko` doesn't