Code Monkey home page Code Monkey logo

docker-security's Introduction

Docker Security

This is the OWASP Docker Top 10. It's a work in progress.

About this document

This document describes the most important 10 security bullet points for building a secure containerized environment. You can use it as a specification sheet if you start from scratch, alternatively handing it to a contractor who will do this for you.

It can also be used to audit or secure an existing installation but especially here you should start thinking about security very early. Best is in the design phase. Later on it becomes either difficult to change some decisions you made or they become costly, in terms of money or time.

Name

Albeit the document's name resembles the OWASP Top 10 it's quite different. First, it is not about risks which are based on data collected as the OWASP Top 10. Secondly the 10 bullet points here resemble (proactive) controls.

For whom is this?

This guide is for developers, auditors, architects, system and networking engineers. As indicated above you can also use this guide for external contractors to add formal technical requirements to your contract. The information security officer should have some interest too to meet baseline security requirements and beyond.

These 10 bullet points are mostly (see below this paragraph) about system and network security and system and network architecture. As a developer you don't have to be an expert in those -- that's what this guide is for. But as indicated above best is to start thinking about and addressing those points early. Please do not just start building it.

One of the bullet points should not be misunderstood: Patch management is not a technical point. It's a management process. Last but not least for technical or information security management who has not been much worried about containerization this document also provides insights about the risks involved.

Structure of this document

Security in Docker environments seemed often to be misunderstood. It was/is a highly disputed matter what the threats are supposed to be. So before diving into the Docker Top 10 bullet points, the threats need to be modeled which is happening upfront in this document. It not only helps to understand any security impacts but also gives you the ability to prioritize your tasks.

Contribution

Please see CONTRIBUTING.md. To ease contributions to the the open points please file your PRs against the corresponding dev branches (D06_dev, D07_dev, ...).

How to Build PDF version

You can build yourself a PDF version as long as you have Docker and docker-compose installed.

docker-compose run --rm build

It's not frequently updated in this repository as it otherwise clogs this repo.

FAQ

Why not "Container Security"

Albeit the name of this project carries the word "Docker", it also can be used with little abstraction for other containment solutions. Docker is as of now the most popular one, so the in-depth details are focusing for now on Docker. This could change later.

A single container?

If you run more than 3 containers on a server you probably have an orchestration solution to manage them. Specific security pitfalls of such a tool are currently beyond the scope of this document. That does not mean that this guide is just concerning one or a few containers managed manually -- on the contrary. It means only that we're looking at the containers including their networking and their host systems in such an orchestrated environment and not on special pitfalls of e.g. Kubernetes, Swarm, Rancher or OKD/OpenShift.

Why ten?

To be honest for us humans the number 10 sounds catchy and while putting it all together those 10 were considered to be the most important ones.

docker-security's People

Contributors

dizzersee avatar drwetter avatar giftcup avatar hartwork avatar hblankenship avatar kauedg avatar lpmi-13 avatar pauloasilva avatar vin01 avatar wurstbrot avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

docker-security's Issues

D01 - Secure User Mapping: Namespaces

I disagree with the following lines:
"The catch using namespaces is that you can only run one namespace at a time. If you run user namespacing you e.g. can't use network namespacing on the same host [6]."
The cited document only states that it is not possible to share "PID or NET namespaces with the host" while using the user namespace, but that does not mean that generally speaking only one namespace can be used at a time.
Furthermore, other documents and blog entries explicitly state that "[m]odern containerization systems (e.g. Docker, LXC, etc.) use all of these namespaces when programs are launched". (https://blog.selectel.com/containerization-mechanisms-namespaces/)
Probably you meant the right thing but formulated it a bit ambiguous.

I would be very glad to hear your thoughts about this topic!

PDF generation: Replacement for gitbook-cli (and maybe calibre)?

Because of several issues with gitbook-cli, its status, and calibre issues I am seeking for a replacement or help with a solution which works.

The goal is:

  • to enable almost everybody to build or get a PDF
  • should work at least under every Linux distro
  • it should be maintainable (no private or deprecated repos)

See also #17, #31, #32

Structure of D points

I will start with a structure of the D sections which will basically provide the core for a) planning a secure container environment, for b) security controls and for c) auditing. It'll be basically addressing the threats mentioned in https://github.com/OWASP/Docker-Security/blob/master/001_Threats.md .

This document is not supposed to have a single page per D section like the OWASP Top 10 but still I was thinking on borrowing a few headlines from the boxes (no boxes either) like

  • ~How Do I Prevent?,
  • ~Am I Vulnerable --> need to use a different term like How can I detect?,
  • ~Example Attack Scenarios --> probably needs to be related to the aforementioned threats
  • References

and before an introductory paragraph telling what each point is about. Each of those sections will have a text paragraph or examples, and as said no boxes. I am not in favor of a single page as I am afraid there's too much content.

Any thoughts on this?

MD to PDF

In the end a PDF should be available.

While github is great in dealing with markdown documents I suspect it's not as easy to generate a handy PDF from the markdown files.

Help or hints would be appreciated.

D02 - Patch Management Strategy Suggestion

Suggestion to include guidance on tracking the components in your base image, and your own bundled software, as part of D02.

There are tools like Anchore Syft that can generate a software bill of materials for container images. This information can be fed into tools like OWASP Dependency-Track for continuous analysis. And identification of vulnerable components.

It also helps address OWASP Top 10 A9:2017-Using Components with Known Vulnerabilities, and activities identified in the OWASP SCVS.

Trailing page(s) of document

This is just a reminder that a) trailing page(s) would do good b) that then maybe the naming scheme needs to be readjusted .

owasp/modsecurity vulnerabilites

Hi,

I noticed a lot of vulnerabilities in the owasp/modsecurity:3 Docker image. I didn't find a repo for the Docker image so posting here. (It feels a bit sour having to accept 2 critical and 106 high vulnerabilities if we want to implement WAF in our cluster..)

$ trivy i owasp/modsecurity:3

owasp/modsecurity:3 (debian 10.3)
=================================
Total: 569 (UNKNOWN: 2, LOW: 379, MEDIUM: 80, HIGH: 106, CRITICAL: 2)

The Docker image could use some attention, the source files are left in the container only wasting image size.

Could you address these vulnerabilities and create a repo for the source?

Cheers, cDR

Image Scanning in D02

Hi *,

I could need some help wrt to image scanning for known vulnerabilities, see D02 --> How can I find out? --> Automatic.

Preferably short and "crispy"

Cheers, Dirk

Addition to the threat mindmap might be needed

Breaking out of a container might not only be achieved by root processes or (ab)use cases of SETUID/SETGID, but through risky bind mounts of the host file system, too.
UID 0 might help with additional permissions in such a scenario, but i'd argue it would still be considered a separate point.

The docker docs even acknowledge it here (search page for "security implications").

Side note: Most english sources call it container breakout instead of container outbreak.
Using your favourite search engine with both terms will demonstrate the difference in search result quality.

Add year of document release to numbering scheme

While I found a clash of the numbering scheme of OWASP Top 10 and the API Top 10 (OWASP/API-Security#24) I accidentially realized that the Docker Top 10 lack the year of release in their numbering scheme.

Recommendation

Use D1:2019 instead of D1 in the summary table and when referring to individual list entries. This would harmonize Top 10 lists of OWASP overall a bit.

Other threats (+testing guide)

Hi

I have some other threats to add to this (good) list

  • Untrusted base images
  • Supply chain poisoning
  • This is not related to docker itself, but it might be good to add Kubernetes issues too (maybe a kubernetes top 10 is too much)

I dont know if those qualify for the top 10, but for sure in a docker security guide.

Would you be accepting a PR where i add those? I have contributed before to the mobile testing guide and i will be glad to contribute here too :)

Translation to Brazilian Portuguese and Contributions

Hello there,

I'm just have started a translation for this awesome project do Brazilian Portuguese. I'm a leader for Belo Horizonte Chapter and we just fork this project to do this translation apart and we send a pull request when apropriate.

As WIP I consider a great oportunity to stay close translating it at the same time this projects gets in shape. I'm also have interest to contribute in some way, just let me know. This container rush had a impact on security so I consider this project a must have.

Greetings from Brazil.
Happy holidays.

D04 - Secure Defaults

Am going to slowly add to this issue, and then eventually merge into repo:

  1. apt install apt-transport-https

I think it's important to use TLS for all package installations. You'll have to have to separate install statements, which can cause slight increase in image size but is worth it.

  1. apt-get --no-install-recommends -y install libtool

reduce surface area of attack by not installing extra packages during installation of packages too.

[D01] Issues with relying on (or advertising) Docker instruction "USER <user>[:<group>]"

The current text mentions:

Then, before you start the microservice, the USER <username> [3] switches to this user.

While that is true and might be of help while building an image, it is my understanding that it would be a mistake to let the image tell the operator what user to use unless we have full control over the the image we run. E.g. you could drop line USER node from Dockerfile and when I rebuild or pull the image again next time, I'd start running the image as user root. (If I had a line in docker-compose.yml or my Docker command line running the image, I would be safe against that kind of change.)

What do you think?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.