# Container and Cluster Hardening / Security resources

## Some links

As of this writing, much of this is stuff I know already, but as an attacker not a defender. I haven't yet had the chance to review each of these resources yet, but I do plan on doing so.

- [TwistLock Container Security Guide](https://www.twistlock.com/container-security-guide/?ads_cmpid=958177855&ads_adid=47094446309&ads_matchtype=b&ads_network=g&ads_creative=229133632237&utm_term=aqua%20container&ads_targetid=kwd-302794593511&utm_campaign=&utm_source=adwords&utm_medium=ppc&ttv=2&gclid=Cj0KCQjw2K3rBRDiARIsAOFSW_6NgJ2DKFuCzRnuoGZqB-tZ2U5dlx5TfuaG9RmokfMRdEb94f7CMyQaAp7MEALw_wcB)
- [NIST Application Container Security Guide](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf)
- [OWASP Container Security Verification Standar](https://www.owasp.org/index.php/OWASP_Container_Security_Verification_Standard_(CSVS))
- [Red-Hat Container Security](https://www.redhat.com/en/topics/security/container-security)
- [Docker Security](https://docs.docker.com/engine/security/security/)
- [Kubernetes Securing a Cluster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/)
- [Kubernetes Concepts Security](https://kubernetes.io/docs/concepts/security/)

## Some general notes

**TODO: expand upon these items further with concrete details**

*The following information is far from comprehensive and is lacking in detail. For now just use these as jumping off points to conduct your own research.*

#
Container security and cluster security can be pretty tough to get a grasp on. There was a misconception for a long time that containers were just somehow more secure, but as we've seen research have continued to prove that wrong. While the do offer a layer of isolation from other processes and services and all that jazz, they also add another layer of complexity ontop of trying to secure the apps and services that run within the containers. Fortunately a lot of the same concepts from other areas of info sec apply to these tools as well. As with anything that you're building and securing it's good to keep the following things in mind:

### Don't run more services than needed
A container should only have the binaries necessary for the application or service it houses to work. Nothing more. If I were to get command exec through your containerized app, don't make it easier for me to pivot to another container or setup a backdoor and otherwise just get a better foothold by having useful bins in the container. Remove all uncessesary networking tools, all package managers and so on.

### Mind what users have permissions to run things like Docker
Container tools are powerful. It's trivial as a low-priv user that is a part of the Docker group to elevate themselves to root with a few simple commands. Limit this access as much as possible.

### Limit access to container deployment and orchestration tools
If an actor can deploy a container to a cluster or whatever then they can start doing a lot of nasty things

### Avoid Docker bind mounts like the plague
Don't even allow these, just use volume mounts instead, this goes for any system that uses containers.

### Use things like apparmor profiles
For example you can install docker via snap on ubuntu systems, it comes with an apparmor profile that thwarts certain attacks out of the box such as running a container with the host root bind mounted and then modify or reading sensitive files. It will set the FS as read only.

### Use user namespace remapping
This remaps the user in the containers to a UID on the host that doesn't exist. So, in the event that somebody is able to try to do things to the host system that they shouldn't, like modify files through bind mounts, it will fail an ownership check.

- [Docker user namespace remapping](https://docs.docker.com/engine/security/userns-remap/)

### Keep your host systems kernel patched
Most container solutions share the kernel with the host and can leverage kernel vulnerabilites to do nefarious things