├── LICENSE └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Container Security Checklist: From the image to the workload 2 | 3 | ## Table Of Contents 4 | 5 | - [Cloud Native challenges](#cloud-native-challenges) 6 | - [Container Threat Model](#container-threat-model) 7 | - [Container Security Checklist](#container-security-checklist) 8 | - [Supply Chain Security](#supply-chain-security) 9 | - [Secure the Build](#secure-the-build) 10 | - [Secure Supply Chain](#secure-supply-chain) 11 | - [Hardening Code - Secure SDLC (Software Development Life Cycle)](#hardening-code---secure-sdlc-software-development-life-cycle) 12 | - [Secure the Image - Hardening](#secure-the-image---hardening) 13 | - [Image Scanning](#image-scanning) 14 | - [Image Signing](#image-signing) 15 | - [Secure the Container Registry](#secure-the-container-registry) 16 | - [Registry Resources](#registry-resources) 17 | - [Secure the Container Runtime](#secure-the-container-runtime) 18 | - [Why is important Runtime Security?](#why-is-important-runtime-security) 19 | - [Constraints](#constraints) 20 | - [Docker Security](#docker-security) 21 | - [Secure the Infrastructure](#secure-the-infrastructure) 22 | - [Secure the Data](#secure-the-data) 23 | - [Secrets Management Tools](#secrets-management-tools) 24 | - [Secure the Workloads... Running the containers](#secure-the-workloads-running-the-containers) 25 | - [Common Containers Attacks](#common-container-attacks) 26 | - [Container Security Guides](#container-security-guides) 27 | - [Further reading](#further-reading) 28 | - [Collaborate](#collaborate) 29 | 30 | 31 | --- 32 | 33 | ## Cloud Native challenges 34 | 35 | | Legacy apps | Cloud Native apps | Cloud Native Security | 36 | |----------|:-------------:|------:| 37 | | Discrete, infrequent releases | frequent releases, using CI/CD | Shifting left with automated testing | 38 | | Very little open source | Open source everywhere | SCA - Software composition analysis | 39 | | Proprietary software | Proprietary code, Open source, Third-party software | Software supply chain risk | 40 | | Persistent workloads | Ephemeral workloads. Ensure that your containers are stateless and immutable | Runtime controls that follow the workload | 41 | | Hypervisor or hardware isolation | Shared kernel, obscured OS | Enforce least privilege on each workload | 42 | | Permanent address | Orchestrated containers. Kubernetes creates DNS records for services and pods | Identity-based segmentation | 43 | | Vertical control of the stack | multi-cloud | Detecting cloud services misconfigurations (CSPM) | 44 | | Networking monitoring and threat detection tools were based on auditd, syslog, dead-disk forensics, and it used to get the full contents of network packets to disk "packet captures". Capturing packets sotes every packet in a network to disk and runs custom pattern matching on each packet to identify an attack. | Cloud native apps the traffic is encrypted. Packet captures are too costly and ineffective for cloud native environments. | Using eBPF programs, you collect the events in real time without disruption to the app. | 45 | 46 | 47 | > Table by Aqua Cloud Native Security Platform, more details [download here](https://f.hubspotusercontent40.net/hubfs/1665891/Buyers_Guide/Aqua_Buyers_Guide_Cloud_Native_Security_Platform.pdf) 48 | ## Container Threat Model 49 | 50 | [![thread-model](https://miro.medium.com/max/4800/0*PGj_8b4bt5F5F6LR)](https://medium.com/oreillymedia/container-security-threats-38649261fb4f) 51 | Figure by [Container Security by Liz Rice](https://www.oreilly.com/library/view/container-security/9781492056690/) 52 | 53 | - Insecure Host 54 | - Misconfiguration container 55 | - Vulnerable application 56 | - Supply chain attacks 57 | - Expose secrets 58 | - Insecure networking 59 | - Integrity and confidentiality of OS images 60 | - Container escape vulnerabilities 61 | 62 | ## Container Security Checklist 63 | 64 | Checklist to build and secure the images across the following phases: 65 | 66 | * [Secure the Build](#secure-the-build) 67 | * [Secure the Container Registry](#secure-the-container-registry) 68 | * [Secure the Container Runtime](#secure-the-container-runtime) 69 | * [Secure the Infrastructure](#secure-the-infrastructure) 70 | * [Secure the Data](#secure-the-data) 71 | * [Secure the Workloads](#secure-the-workloads-running-the-containers) 72 | 73 | ![Build](https://raw.githubusercontent.com/cncf/tag-security/main/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure3.png) 74 | Figure by [cncf/tag-security](https://github.com/cncf/sig-security/) 75 | 76 | --- 77 | 78 | ## Supply Chain Security 79 | 80 | - Enforce image trust with Image signing: Container Signing, Verification and Storage in an OCI registry. 81 | ### Image Signing 82 | 83 | Sign and verify images to mitigate a man in the middle (MITM) attack. Docker offers a Content Trust mechanism that allows you to cryptographically sign images using a private key. This guarantees the image, and its tags, have not been modified. 84 | 85 | - [Notary](https://github.com/notaryproject/notaryproject). Implementation of TUF specification. 86 | - [sigstore/Cosign](https://github.com/sigstore/cosign) 87 | - [Sigstore: A Solution to Software Supply Chain Security](https://itnext.io/sigstore-a-solution-to-software-supply-chain-security-35bc96bddad5) 88 | - [Zero-Trust supply chains with Sigstore and SPIFFE/SPIRE](https://github.com/sigstore/community/blob/main/docs/zero-trust-supply-chains.pdf) 89 | ## Secure the Build 90 | 91 | ### Hardening Code - Secure SDLC (Software Development Life Cycle) 92 | - [x] Do a static analysis of the code and libraries used by the code to surface any vulnerabilities in the code and its dependencies. 93 | - Improve the security and quality of their code. [OWASP Open Source Application Security tools](https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools): SAST, IAST. 94 | 95 | ### Secure the Image - Hardening 96 | 97 | You can build the container images using [Docker](https://docs.docker.com/engine/reference/commandline/build/), [Kaniko](https://github.com/GoogleContainerTools/kaniko). 98 | 99 | - *Reduce the attack surface* 100 | 101 | > Package a single application per container. Small container images. 102 | > Minimize the number of layers. 103 | 104 | - Use the minimal OS image: 105 | - [Alpine images](https://hub.docker.com/_/alpine) 106 | - [Scratch images](https://hub.docker.com/_/scratch) 107 | - [Distroless images](https://github.com/GoogleContainerTools/distroless) 108 | - Use OS optimized for running containers: 109 | - [Flatcar images](https://www.flatcar.org/docs/latest/installing/) 110 | - [CodeOS by Fedora](https://getfedora.org/coreos/) replaced the Project Atomic. 111 | - [Bottlerocket by Aws](https://aws.amazon.com/bottlerocket/) 112 | - [k3os by Rancher](https://github.com/rancher/k3os) 113 | - [Container-Optimized OS - COS by Google](https://cloud.google.com/container-optimized-os/docs/concepts/features-and-benefits), based on [Chromium-os](https://www.chromium.org/chromium-os/) used by Google 114 | 115 | > - [Do you use Alpine, distroless or vanilla images? ...](https://learnk8s.io/blog/smaller-docker-images) 116 | > - [7 Google best practices for building containers](https://cloud.google.com/blog/products/containers-kubernetes/7-best-practices-for-building-containers) 117 | 118 | - Multi-staged builds. 119 | 120 | > A well-designed multi-stage build contains only the minimal binary files and dependencies required for the final image, with no build tools or intermediate files. 121 | > Optimize cache. 122 | 123 | - [x] Use official base images. 124 | - Avoid unknown public images. 125 | - [x] Rootless. Run as a non-root user. Least privileged user 126 | - [x] Create a dedicated user and group on the image. 127 | 128 | > Do not use a UID below 10,000. For best security, always run your processes as a UID above 10,000. 129 | > Remove setuid and setgid permissions from the images 130 | 131 | - [x] Avoid privileged containers, which lets a container run as root on the local machine. 132 | - [x] Use only the necessary Privileged Capabilities. 133 | - Drop kernel modules, system time, trace processes (CAP_SYS_MODULE, CAP_SYS_TIME, CAP_SYS_PTRACE ). 134 | - [x] Enable the `--read-only` mode in docker, if it's possible. 135 | - [x] Don't leave sensitive information (secrets, tokens, keys, etc) in the image. 136 | - [x] Not mounting Host Path. 137 | - [x] Use Metadata Labels for Images, such as licensing information, sources, names of authors, and relation of containers to projects or components. 138 | - [x] Used fixed image tag for inmutability. 139 | - Tagging using semantic versioning. 140 | - Not use mutable tags(latest,staging,etc). Use Inmutable tags(SHA-256, commit). 141 | - [The challengue of uniquely identifying your images](https://blog.aquasec.com/docker-image-tags) 142 | 143 | ``` 144 | Pulling images by digest 145 | docker images --digests 146 | docker pull alpine@sha256:b7233dafbed64e3738630b69382a8b231726aa1014ccaabc1947c5308a8910a7 147 | ``` 148 | 149 | - [x] Enabled Security profiles: SELinux, AppArmor, Seccomp. 150 | 151 | - [x] Static code analysis tool for Dockerfile like a linter. **Detect misconfigurations** 152 | - [Hadolint](https://github.com/hadolint/hadolint) 153 | - Packers (including encrypters), and downloaders are all able to evade static scanning by, for example, encrypting binary code that is only executed in memory, making the malware active only in runtime. 154 | - Trivy detect missconfigurations 155 | 156 | ### Image Scanning 157 | 158 | - [x] Scan image for Common Vulnerabilities and Exposures (CVE) 159 | - [x] Check image for secrets 160 | - [x] Prevent attacks using the Supply Chain Attack 161 | - [x] Used dynamic analysis techniques for containers to prevent runtime bad behaviours. 162 | 163 | **Container Security Scanners** 164 | 165 | - [Trivy by AquaSecurity](https://github.com/aquasecurity/trivy) 166 | - [Clair by Quay](https://github.com/quay/clair) 167 | - [Anchore](https://anchore.com/opensource/) 168 | - [Dagda](https://github.com/eliasgranderubio/dagda/) 169 | - [GitGuardian Shield](https://github.com/GitGuardian/ggshield/) 170 | 171 | Comparing the container scanners results: 172 | - [Container Vulnerability Scanning Fun by Rory](https://raesene.github.io/blog/2020/06/21/Container_Vulnerability_Scanning_Fun/) 173 | - [Comparison – Anchore Engine vs Clair vs Trivy by Alfredo Pardo](https://www.a10o.net/devsecops/docker-image-security-static-analysis-tool-comparison-anchore-engine-vs-clair-vs-trivy/) 174 | 175 | 176 | **More Material about build containers** 177 | - [Azure best practices for build containers](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-best-practices) 178 | - [Docker best practices for build containers](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) 179 | - [Google best practices for build containers](https://cloud.google.com/solutions/best-practices-for-building-containers) 180 | 181 | ## Secure the Container Registry 182 | 183 | Best configurations with ECR, ACR, Harbor, etc. Best practices. 184 | - [x] Lock down access to the image registry (who can push/pull) to restrict which users can upload and download images from it. Uses Role Based Access Control (RBAC) 185 | 186 | > There is no guarantee that the image you are pulling from the registry is trusted. 187 | > It may unintentionally contain security vulnerabilities, or may have intentionally been replaced with an image compromised by attackers. 188 | 189 | - [x] Use a private registry deployed behind firewall, to reduce the risk of tampering. 190 | 191 | ### Registry Resources 192 | - [Azure ACR](https://docs.microsoft.com/en-us/azure/container-registry/security-controls-policy) 193 | - [Azure best practices for Azure Container Registry](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-best-practices) 194 | - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security.html) 195 | - [Google Artifact Registry ](https://cloud.google.com/artifact-registry/docs/docker/authentication) 196 | - [Harbor](https://goharbor.io/) 197 | 198 | ## Secure the Container Runtime 199 | 200 | See the following container runtimes, there are three main types of container runtimes—low-level runtimes, high-level runtimes, and virtualized runtimes or sandboxed. 201 | 202 | 1. Low-Level Container Runtimes: 203 | - [runC](https://github.com/opencontainers/runc) 204 | - [crun](https://github.com/containers/crun) 205 | - [containerd](https://containerd.io/) 206 | 2. High-Level Container Runtimes 207 | - [Docker Engine](https://docs.docker.com) 208 | - [Podman](https://podman.io/) 209 | - [CRI-O](https://github.com/cri-o/cri-o) - OCI-based implementation of Kubernetes Container Runtime Interface 210 | - [Mirantes Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) 211 | 3. Sandboxed and Virtualized Container Runtimes 212 | - [gVisor](https://gvisor.dev/) 213 | - [nabla-containers](https://nabla-containers.github.io/) 214 | - [kata-containers](https://github.com/kata-containers) 215 | ### Why is important Runtime Security? 216 | - Detection of IOC (Indicator Of Compromise) 217 | - Detect Zero Days attack 218 | - Compliance requirement 219 | - Recommended in highly dynamic environments 220 | 221 | ### Constraints 222 | - Event context 223 | - Safety 224 | - Low overhead 225 | - Wide support of kernels 226 | 227 | 228 | Enable detection of anomalous behaviour in applications. 229 | 230 | - [x] Applied the secure configurations in the container runtime. By default is insecure. 231 | - [x] Restrict access to container runtime daemon/APIs 232 | - [x] Use if it's possible in Rootless Mode. 233 | 234 | ### Docker Security 235 | 236 | - [x] Avoid misconfigured exposed Docker API Ports, attackers used the misconfigured port to deploy and run a malicious image that contained malware that was specifically designed to evade static scanning. 237 | - [x] TLS encryption between the Docker client and daemon. Do not expose the Docker engine using Unix socket or remotely using http. 238 | 239 | > Never make the daemon socket available for remote connections, unless you are using Docker’s encrypted HTTPS socket, which supports authentication. 240 | 241 | - [x] Limit the usage of mount Docker socket in a container in an untrusted environment. 242 | 243 | - [x] Do not run Docker images with an option that exposes the socket in the container. 244 | 245 | -v /var/run/docker.sock://var/run/docker.sock 246 | 247 | > The Docker daemon socket is a Unix network socket that facilitates communication with the Docker API. By default, this socket is owned by the root user. If anyone else obtains access to the socket, they will have permissions equivalent to root access to the host. 248 | 249 | - [x] Run Docker in [Rootless Mode](https://docs.docker.com/engine/security/rootless/). `docker context use rootless` 250 | - [x] Enable the [user namespaces](https://docs.docker.com/engine/security/userns-remap/). 251 | - [x] Enable Docker Content Trust. Docker. `DOCKER_CONTENT_TRUST=1` 252 | . Docker Content Trust implements [The Update Framework](https://theupdateframework.io/) (TUF) 253 | . Powered by [Notary](https://github.com/notaryproject/notary), an open-source TUF-client and server that can operate over arbitrary trusted collections of data. 254 | 255 | - [x] Do not run Docker without the default **seccomp profile**: `seccomp=unconfined` 256 | 257 | > - [Seccomp enabled by default](https://docs.docker.com/engine/security/seccomp/). See the Docker profile [here](https://docs.docker.com/engine/security/seccomp/) 258 | > - [Hardening Docker and Kubernetes with seccomp](https://martinheinz.dev/blog/41) 259 | 260 | **More Material about Docker Security** 261 | - [Docker Security Labs](https://github.com/docker/labs/tree/master/security) 262 | - [CIS Docker Bench](https://github.com/docker/docker-bench-security). 263 | - [Content trust in Docker](https://docs.docker.com/engine/security/trust/) 264 | - [Docker Security Playground - DSP](https://github.com/DockerSecurityPlayground/DSP) - Network Security and Penetration Test techniques 265 | ## Secure the Infrastructure 266 | 267 | **Risk:** 268 | - If host is compromised, the container will be too. 269 | - Kernel exploits 270 | 271 | **Best practices:** 272 | - [x] Keep the host kernel patched to prevent a range of known vulnerabilities, many of which can result in container escape. Since the kernel is shared by the container and the host, the kernel exploits when an attacker manages 273 | to run on a container can directly affect the host. 274 | - [x] Use CIS-Benchmark for the operating system. 275 | 276 | - [x] Use secure computing (seccomp) to restrict host system call (syscall) access from containers. 277 | - [x] Use Security-Enhanced Linux (SELinux) to further isolate containers. 278 | 279 | ## Secure the Data 280 | 281 | - [x] Don't leak sensitive info in the images, avoid using environment variables for your sensitive information. 282 | > Secrets are Digital credentials: 283 | > - passwords 284 | > - API keys & Tokens 285 | > - SSH keys 286 | > - Private certificates for secure communication, transmitting and receiving data (TLS, SSL, and so on) 287 | > - Private encryption keys for systems like PGP 288 | > - Database names or connection strings. 289 | > - Sensitive configuration settings (email address, usernames, debug flags, etc.) 290 | 291 | - [x] Use a proper filesystem encryption technology for container storage 292 | - [x] Use volume mounts to pass secrets to a container at runtime 293 | - [x] Provide write/execute access only to the containers that need to modify the data in a specific host filesystem path 294 | - [x] OPA to write controls like only allowing Read-only Root Filesystem access, listing allowed host filesystem paths to mount, and listing allowed Flex volume drivers. 295 | - [x] Automatically scan container images for sensitive data such as credentials, tokens, SSH keys, TLS certificates, database names or connection strings and so on, before pushing them to a container registry (can be done locally and in CI). 296 | - [x] Limit storage related syscalls and capabilities to prevent runtime privilege escalation. 297 | 298 | - [x] Implement RBAC, or role-based access control. Every human or application only needs the minimum secrets required to operate, nothing more. **Principle of Least Privilege**. 299 | - [x] Run audits regularly. Centralized audit trails are the key to knowing all the key security events. 300 | - [x] Rotate secrets, a standard security practice. 301 | - [x] Automatically create and store secrets 302 | 303 | ### Secrets Management Tools 304 | 305 | Open source tools: 306 | - [detect-secrets by Yelp](https://github.com/Yelp/detect-secrets): detecting and preventing secrets in code. 307 | - [git-secrets by awslabs](https://github.com/awslabs/git-secrets#nix-linux-macos): Prevents you from committing secrets and credentials into git repositories 308 | 309 | Cloud Provider Key Management 310 | - [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) 311 | - [Azure Key Vault](https://docs.microsoft.com/en-us/azure/key-vault/general/basic-concepts) 312 | - [Google Secret Manager](https://cloud.google.com/secret-manager) 313 | 314 | Enterprise secrets vault: 315 | - [HashiCorp Vault](https://www.vaultproject.io/) 316 | - [CyberArk Conjur](https://www.cyberark.com/products/secrets-manager-enterprise/) 317 | 318 | ## Secure the Workloads... Running the containers 319 | - [x] Avoid privileged containers 320 | 321 | • Root access to all devices 322 | • Ability to tamper with Linux security modules like AppArmor and SELinux 323 | • Ability to install a new instance of the Docker platform, using the host’s kernel capabilities, and run Docker within Docker. 324 | 325 | > To check if the container is running in privileged mode 326 | > `docker inspect --format =’{{. HostConfig.Privileged}}’[container_id]` 327 | 328 | - [x] Limit container resources. 329 | 330 | > When a container is compromised, attackers may try to make use of the underlying host resources to perform malicious activity. 331 | > Set memory and CPU usage limits to minimize the impact of breaches for resource-intensive containers. 332 | 333 | ``` 334 | docker run -d --name container-1 --cpuset-cpus 0 --cpu-shares 768 cpu-stress 335 | ``` 336 | 337 | - [x] Preventing a fork bomb. `docker run --rm -it --pids-limit 200 debian:jessie ` 338 | 339 | - [x] Segregate container networks. 340 | 341 | - The default bridge network exists on all Docker hosts—if you do not specify a different network, new containers automatically connect to it. 342 | - Use custom bridge networks to control which containers can communicate between them, and to enable automatic DNS resolution from container name to IP address. 343 | - Ensure that containers can connect to each other only if absolutely necessary, and avoid connecting sensitive containers to public-facing networks. 344 | - Docker provides network drivers that let you create your own bridge network, overlay network, or macvlan network. If you need more control, you can create a Docker network plugin. 345 | 346 | - [x] Improve container isolation. 347 | 348 | > Protecting a container is exactly the same as protecting any process running on Linux. 349 | > Ideally, the operating system on a container host should protect the host kernel from container escapes, and prevent mutual influence between containers. 350 | 351 | - [x] Set filesystem and volumes to Read only. 352 | 353 | > This can prevent malicious activity such as deploying malware on the container or modifying configuration. 354 | > `docker run --read-only alpine` 355 | 356 | - [x] Complete lifecycle management restrict system calls from Within Containers 357 | - [x] Monitor Container Activity. Analyze collected events to detect suspicious behaviourial patterns. 358 | - [x] Create an incident response process to ensure rapid response in the case of an attack. 359 | - [x] Apply automated patching 360 | - [x] Confirms Inmutability. Implement drift prevention to ensure container inmutability. 361 | - [x] Ensure you have robust auditing and forensics for quick troubleshooting and compliance reporting. 362 | 363 | ## Common Containers Attacks 364 | - Unsecured Docker daemons 365 | - [Cetus: Cryptojacking Worm Targeting Docker Daemons](https://unit42.paloaltonetworks.com/cetus-cryptojacking-worm/) 366 | - [Black-T: New Cryptojacking Variant from TeamTNT](https://unit42.paloaltonetworks.com/black-t-cryptojacking-variant/) 367 | ## Container Security Guides 368 | 369 | * [SP 800-190 - Application Container Security Guide by NIST](https://csrc.nist.gov/publications/detail/sp/800-190/final) 370 | ## Further reading: 371 | - [Linux Capabilities](https://www.kernel.org/doc/ols/2008/ols2008v1-pages-163-172.pdf): making them work, published in hernel.org 2008. 372 | - [Using seccomp to limit the kernel attack surface](https://man7.org/conf/lpc2015/limiting_kernel_attack_surface_with_seccomp-LPC_2015-Kerrisk.pdf) 373 | - [Docker Security Best Practices by Rani Osnat - AquaSecurity](https://blog.aquasec.com/docker-security-best-practices) 374 | - [Applying devsecops in a Golang app with trivy-github-actions by Daniel Pacak - AquaSecurity](https://blog.aquasec.com/devsecops-with-trivy-github-actions) 375 | - [21 Docker Security Best Practices – Deamon, Image & Container by James Walker - Spacelift](https://spacelift.io/blog/docker-security) 376 | 377 | ## Collaborate 378 | 379 | If you find any typos, errors, outdated resources; or if you have a different point of view. Please open a pull request or contact me. 380 | 381 | Pull requests and stars are always welcome 🙌 382 | --------------------------------------------------------------------------------