cloud-computing Containers Version: 1.0.2 On this page
Containers More than one container can run on the same host OS. Docker is the standard way of running containersContainers vs VMs Both reduces cost due to shared hardware.A single physical server can host multiple, concurrent VMs or applications A virtual machine virtualizes an operating systemA container sandboxes an applications Container threats Container threat model Container escape (system) Attacker needs to escape application and end up in container with shell access Attacker than uses host or kernel exploit to escape container Other containers via network Attacker needs to escape application and end up in container with shell access Attacker attacks other containers on network Attacking the orchestration tool via network Attacker needs to escape application and end up in container with shell access Attacker attacks on management interfaces or other attacks surfaces of the orchestration tool🤗 In 2018 almost every tool has had a weakness here which was a default open management interface Attacking the host via network Attacker needs to escape application and end up in container with shell access With shell access attacker opens a port from the host Attacking other resources via network Attacker needs to escape application and end up in container with shell access Attacks e.g. on shared network-based file system, LDAP/Active Directory, Jenkins..Can also install sniffer to read traffic of other containers Resource starvation Attacker causes a container eating up resources which could be CPU cycles, RAM, network or disk-I/O. 📝 Can cause problems affecting all other containers on same host Host compromise Either through another container or through the network. Integrity of images Each step in CD pipeline where container image is attack vector for the attacker. Attacker can inject malicious payloads to deploy. OWASP Docker Top 10 Secure user mapping Docker runs with root. Escape from application => root in container Patch management strategy Bugs on container/orchestration tools or OS images needs to be patched. Network segmentation and firewalling Design your network upfront providing network level protection formanagement interfaces from the orchestration too network services from the host Expose microservices to only legitimate consumers Secure defaults and hardening Ensure no unneeded components are installed or started. Ensure needed components are properly configured and locked down. Maintain security contexts Do not mix production containers on one host with other stages of less secure containers. Do not mix frontend with backend services on one host. Protect secrets Ensure passwords, tokens, private keys or certificates are protected. Resource protection Protect shared resources such as CPU, disks, memory and networks. Ensures one containers usage does not affect others. Container image integrity and origin Ensure OS in container is trustworthy until deployment. Ensure images are not tampered with during transfers. Follow immutable paradigm Start containers on read-only mode if no file access is needed Logging Log on application, container image and orchestration tool Both related events and API level Ensure logs are stored on remote with timestamps and are tamper proof Container attacks Attacks are generally not on the containers themselves, but on the applications running in them. Exploiting vulnerable images Exploiting bugs and vulnerabilities on unpatched DockerE.g. a bug caused compromised images to access the host OS that has been fixed. E.g. Windows Host Compute Service Shim library had remote code execution vulnerability E.g. a bug allowed root privilige escalation using docker command Creating malicious container on compromised host system Exploiting orchestration tool Container advantages over VM Often no SSH enabled into containers Often no user access expected No need for credentials or tools to support users Restricted ports by default Specific and limiting about which ports to connect Short-lived containers are unlikely bases for attackers Harder to compromise a service that only lives for a few seconds/minutes. Immutable designs make it difficult to inject malware As persistance is usually separated away from the container Automatic generation makes it faster to pick up and promote security patches Automated CI/CD pipelines make updating libraries/OS much quicker than manual Well-defined APIs enables easier anomaly detection Developers often create APIs to communicate with containers Makes it easy to create a reference model for what is normal inside an application, so anything outside of that is an anomaly. We can automatically detect any anomalies Container security countermeasures OWASP Docker Security Cheat Sheet Keep Host and Docker up to date Do not expose the Docker daemon socket (even to the containers) Set a user Limit capabilities (Grant only specific capabilities, needed by a container)¶ Add –no-new-privileges flag Disable inter-container communication (--icc=false) Use Linux Security Module (seccomp, AppArmor, or SELinux) Limit resources (memory, CPU, file descriptors, processes, restarts) Set filesystem and volumes to read-only Use static analysis tools Lint the Dockerfile at build time Pre-deploy sources and dependency validation Ensures containers are using valid and expected code paths. Pre-deploy authenticity validation Ensures that the code has not been tampered with. Pre-deploy image scanning for vulnerabilities Looking for signatures of compromised packages Active vulnerability scans of running containers Running automated scans after the container is deployed. Network routing that includes traffic inspection Create a function based service firewall. Integrated log capture Since there's no local storage, most container patterns are including central log capture and analysis External injection of trust and credentials Giving credentials just-in-time to running live instances rather than static code Always check running containers To ensure there's no malicious container running. Ensure container images are up-to-date Unupdated/stale images might be vulnerable Never-ever as root 