First, thanks for publishing this and making it available. I think the title pretty much says it all, but here's the error message in case it's helpful

<Error>
<Code>NoSuchKey</Code>
<Message>The specified key does not exist.</Message>
<Key>container-security-preview.pdf</Key>
<RequestId>2H5V5K3ZBMCW4PBT</RequestId>
...
</Error>

I realize this repo's not terribly active; I'll get the content from the markdown files, but it would be lovely to be able to get it in PDF.

This chapter or a section within the relevant chapter will cover the concept of container immutability. It will also dive into how immutability can be implemented using the tools available like seccomp-bpf and capabilities.

One thing that would likely fit well in Chapter 3 is some coverage of capabilities, as they're important to constraining privileged users inside containers, and aren't always well understood.

There's quite a few good resources on capabilities that could be used for research / source material, here's some I've found useful

• https://www.redhat.com/en/blog/secure-your-containers-one-weird-trick
• http://www.andy-pearce.com/blog/posts/2013/Mar/file-capabilities-in-linux/
• http://blog.siphos.be/2013/05/overview-of-linux-capabilities-part-3/
• https://s3hh.wordpress.com/2015/07/25/ambient-capabilities/
• https://people.redhat.com/sgrubb/libcap-ng/index.html

and a blog post I wrote a while back on the topic.

• https://raesene.github.io/blog/2017/08/27/Linux-capabilities-and-when-to-drop-all/

Within container basics, we need to include sections on open source components that run within a Docker process, and how this relates to the history around container runtimes (high-level and low-level), efficiencies and security issues (e.g. runc CVE).

I noticed we don't have a section on networking within the book. I can do a section or few on container networking, especially between nodes for orchestrators.

One concept that might be worth introducing in Chapter one is threat models, as a means of helping organizations prioritize their security controls.

So things like the threat model of a hard multi-tenancy Kubernetes cluster is quite different to one that has very few users and runs more trusted applications. Ultimately companies have limited resources, so threat modelling can be quite useful in helping them pick which controls to start with.

A simplified model that I tend to use for container security engagements is

1. External attackers. Pretty much everyone has to worry about them, and most of the controls that are important are around preventing unauthenticated attackers gaining access they shouldn't (so things like dashboard security, kubelet authentication etc)

2. Compromised containers. Where an attacker has already gained unauthorised access to a single container, controls move more to the container network and also include escalation to the node.

3. Malicious Users. If a container orchestration system has to worry about potentially malicious users (e.g in a hard multi-tenancy setup) then things like RBAC and PSP (in Kubernetes land) become much more important.

This may link to issue #2 - having an understanding of protective controls on host would help with isolation and mitigation techniques.

Perhaps this is a chapter dedicated to VMMs and isolation enforced through seccomp, chroot and other sandboxing controls using projects like firecracker, gVisor, Kata containers and others.