Rooba
/
cowrie
mirror of https://github.com/cowrie/cowrie.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
cowrie/Dockerfile

58 lines
2.0 KiB
Docker
Raw Normal View History

Docker cacheing and python2 (#879) * Docker caching for devel Use more caching features of Docker for building the devel image. Downsite of this is that for users who heavily build the image it will eat up more disk space then before. But I think think only developers are affected here and all others will pull from the registry. A regular docker cleanup on the machines will solve this problem. * Upgrade python to python3 The main Dockerfile will build now a python3 based image. A copy of the old python2 file is still available for further testing.
2018-09-17 06:49:57 +00:00
FROM debian:stable-slim as python3-base
RUN apt-get update
RUN apt-get install --no-install-recommends -y libffi6 python3 python3-pip
RUN adduser --system --shell /bin/bash --group --disabled-password --no-create-home --home /cowrie cowrie
RUN mkdir -p /cowrie/var/lib/cowrie/downloads
RUN mkdir -p /cowrie/var/lib/cowrie/tty
RUN mkdir -p /cowrie/var/log/cowrie/
RUN chown -R cowrie:cowrie /cowrie
RUN chmod -R a+rX /cowrie
Full docker support (#830) * Full docker support Currently Docker images are build by a second git repository. Changes to installation or starting cowrie would need to be done on both. Merging this into one repository prevents that those will be forgotten and makes it easier to understand why changes happen. The dockerfile is a different one then the one from the docker-cowrie repository. I chose to use a python2-alpine linux. In the end this image has 55% smaller image size than the Debian image. The build process is split into to parts. The first image has everything installed to compile the python modules. The second one has only things installed which are needed to run the daemon. There is no need to install python-virtualenv because we are using docker. We don't need that much layers. Twisted can drop his privileges when starting the daemon when `--uid` and `--gid` is passed. This works only with numerical id. The user nobody is used for this. This is on Docker a good idea since there should be only one service with this user running. In other systems there might be several services using this daemon which is not a good choise. When building a new Docker image for cowrie Docker multistage build images are created running flake8 and unittests to ensure that all future releases are stable and matching our code guidelines. Bonus effect is when using this as a git pre-push-hook a developer doesn't need to wait for travis to fail on an error. Based on the current project structure we need a lot of `COPY` instructions inside the dockerfile which has negative sideeffects. - bloading the dockerfile up - longer buildtimes - more layers are created - more diskspace is used We should find a way to reduce this. Best way for doing this is keeping the static files like `honeyfs` and `share` right next to the source code. * Removing UID 0 check Cowrie checked on startup if it was started with root privileges. This conflicts with the option to let cowrie drop his privileges on startup using the twisted option `--uid` and `--gid`. I tested it a day ago without removing the code block and it run through but now it is for some reasons blocking. My feeling is that the code for droping privileges is also asynchron and sometimes the check is faster then the dropping of the privileges. But I might be wrong here. The solution is to remove the hole check. Considering that the check is there for preventing new users to shoot their feet we fixed this problem on different levels. New users should the docker images which are far easier to control and deploy then everything else because we take care. If a user wants to deploy it from scratch onto their serves there is a install instruction with detailed steps. This steps includes creating a special system user for cowrie and starting it with this user. * Fix missing directory, simplify path I missed to create the TTY log path. That's now fixed. Also the path for the trial command has been simplified. * Revert "Removing UID 0 check" This reverts commit f76329cd798744d10a0f52281e5a3588955d2531. * Introducint ENV var COWRIE_DOCKER The variable is used inside the docker image to let cowrie know that it is running inside docker and don't need to perform the "running as root" check. Inside the docker image cowrie is started with the `--uid` and `--gid` option and will drop to a different user then root. * Restructured Dockerfile, Added cowrie user The image is now builded with a user and group for running in the later image cowrie. Also the build steps are re-aranged to save build time. We assume that static files like `honeyfs` and `share` are less frequently updated and can be build into the base image where every other images is based on. * Renamed directory src -> cowrie The name cowrie should be more self-explaining then src. * Update cowrie_plugin.py
2018-08-06 08:27:32 +00:00
COPY requirements.txt .
Docker output (#869) * Full Docker support for output plugins cowrie makes more fun if there are also all the output plugins available inside the docker image. And now they are! * Fixing wrong requirements: snappy vs python-snappy snappy: “SnapPy is a package for studying the topology and geometry of 3-manifolds, with a focus on hyperbolic structures. It is based on the SnapPea kernel written by Jeff Weeks.” python-snappy: “Python bindings for the snappy compression library from Google.” We want python-snappy. ;) * MAINTAINER argument deprecated in Docker The MAINTAINER keyword is deprecated in Docker and is replaced with the new syntax. Also it is now attached to the right container and not to one we actually throw away.
2018-09-02 05:57:21 +00:00
COPY requirements-output.txt .
Full docker support (#830) * Full docker support Currently Docker images are build by a second git repository. Changes to installation or starting cowrie would need to be done on both. Merging this into one repository prevents that those will be forgotten and makes it easier to understand why changes happen. The dockerfile is a different one then the one from the docker-cowrie repository. I chose to use a python2-alpine linux. In the end this image has 55% smaller image size than the Debian image. The build process is split into to parts. The first image has everything installed to compile the python modules. The second one has only things installed which are needed to run the daemon. There is no need to install python-virtualenv because we are using docker. We don't need that much layers. Twisted can drop his privileges when starting the daemon when `--uid` and `--gid` is passed. This works only with numerical id. The user nobody is used for this. This is on Docker a good idea since there should be only one service with this user running. In other systems there might be several services using this daemon which is not a good choise. When building a new Docker image for cowrie Docker multistage build images are created running flake8 and unittests to ensure that all future releases are stable and matching our code guidelines. Bonus effect is when using this as a git pre-push-hook a developer doesn't need to wait for travis to fail on an error. Based on the current project structure we need a lot of `COPY` instructions inside the dockerfile which has negative sideeffects. - bloading the dockerfile up - longer buildtimes - more layers are created - more diskspace is used We should find a way to reduce this. Best way for doing this is keeping the static files like `honeyfs` and `share` right next to the source code. * Removing UID 0 check Cowrie checked on startup if it was started with root privileges. This conflicts with the option to let cowrie drop his privileges on startup using the twisted option `--uid` and `--gid`. I tested it a day ago without removing the code block and it run through but now it is for some reasons blocking. My feeling is that the code for droping privileges is also asynchron and sometimes the check is faster then the dropping of the privileges. But I might be wrong here. The solution is to remove the hole check. Considering that the check is there for preventing new users to shoot their feet we fixed this problem on different levels. New users should the docker images which are far easier to control and deploy then everything else because we take care. If a user wants to deploy it from scratch onto their serves there is a install instruction with detailed steps. This steps includes creating a special system user for cowrie and starting it with this user. * Fix missing directory, simplify path I missed to create the TTY log path. That's now fixed. Also the path for the trial command has been simplified. * Revert "Removing UID 0 check" This reverts commit f76329cd798744d10a0f52281e5a3588955d2531. * Introducint ENV var COWRIE_DOCKER The variable is used inside the docker image to let cowrie know that it is running inside docker and don't need to perform the "running as root" check. Inside the docker image cowrie is started with the `--uid` and `--gid` option and will drop to a different user then root. * Restructured Dockerfile, Added cowrie user The image is now builded with a user and group for running in the later image cowrie. Also the build steps are re-aranged to save build time. We assume that static files like `honeyfs` and `share` are less frequently updated and can be build into the base image where every other images is based on. * Renamed directory src -> cowrie The name cowrie should be more self-explaining then src. * Update cowrie_plugin.py
2018-08-06 08:27:32 +00:00
COPY honeyfs /cowrie/honeyfs
COPY share /cowrie/share
COPY etc /cowrie/etc
Docker cacheing and python2 (#879) * Docker caching for devel Use more caching features of Docker for building the devel image. Downsite of this is that for users who heavily build the image it will eat up more disk space then before. But I think think only developers are affected here and all others will pull from the registry. A regular docker cleanup on the machines will solve this problem. * Upgrade python to python3 The main Dockerfile will build now a python3 based image. A copy of the old python2 file is still available for further testing.
2018-09-17 06:49:57 +00:00
FROM python3-base as builder
RUN apt-get install --no-install-recommends -y python3-wheel python3-setuptools build-essential libssl-dev libffi-dev python3-dev libsnappy-dev default-libmysqlclient-dev
RUN pip3 wheel --wheel-dir=/root/wheelhouse -r requirements.txt
RUN pip3 wheel --wheel-dir=/root/wheelhouse -r requirements-output.txt
Full docker support (#830) * Full docker support Currently Docker images are build by a second git repository. Changes to installation or starting cowrie would need to be done on both. Merging this into one repository prevents that those will be forgotten and makes it easier to understand why changes happen. The dockerfile is a different one then the one from the docker-cowrie repository. I chose to use a python2-alpine linux. In the end this image has 55% smaller image size than the Debian image. The build process is split into to parts. The first image has everything installed to compile the python modules. The second one has only things installed which are needed to run the daemon. There is no need to install python-virtualenv because we are using docker. We don't need that much layers. Twisted can drop his privileges when starting the daemon when `--uid` and `--gid` is passed. This works only with numerical id. The user nobody is used for this. This is on Docker a good idea since there should be only one service with this user running. In other systems there might be several services using this daemon which is not a good choise. When building a new Docker image for cowrie Docker multistage build images are created running flake8 and unittests to ensure that all future releases are stable and matching our code guidelines. Bonus effect is when using this as a git pre-push-hook a developer doesn't need to wait for travis to fail on an error. Based on the current project structure we need a lot of `COPY` instructions inside the dockerfile which has negative sideeffects. - bloading the dockerfile up - longer buildtimes - more layers are created - more diskspace is used We should find a way to reduce this. Best way for doing this is keeping the static files like `honeyfs` and `share` right next to the source code. * Removing UID 0 check Cowrie checked on startup if it was started with root privileges. This conflicts with the option to let cowrie drop his privileges on startup using the twisted option `--uid` and `--gid`. I tested it a day ago without removing the code block and it run through but now it is for some reasons blocking. My feeling is that the code for droping privileges is also asynchron and sometimes the check is faster then the dropping of the privileges. But I might be wrong here. The solution is to remove the hole check. Considering that the check is there for preventing new users to shoot their feet we fixed this problem on different levels. New users should the docker images which are far easier to control and deploy then everything else because we take care. If a user wants to deploy it from scratch onto their serves there is a install instruction with detailed steps. This steps includes creating a special system user for cowrie and starting it with this user. * Fix missing directory, simplify path I missed to create the TTY log path. That's now fixed. Also the path for the trial command has been simplified. * Revert "Removing UID 0 check" This reverts commit f76329cd798744d10a0f52281e5a3588955d2531. * Introducint ENV var COWRIE_DOCKER The variable is used inside the docker image to let cowrie know that it is running inside docker and don't need to perform the "running as root" check. Inside the docker image cowrie is started with the `--uid` and `--gid` option and will drop to a different user then root. * Restructured Dockerfile, Added cowrie user The image is now builded with a user and group for running in the later image cowrie. Also the build steps are re-aranged to save build time. We assume that static files like `honeyfs` and `share` are less frequently updated and can be build into the base image where every other images is based on. * Renamed directory src -> cowrie The name cowrie should be more self-explaining then src. * Update cowrie_plugin.py
2018-08-06 08:27:32 +00:00
Docker cacheing and python2 (#879) * Docker caching for devel Use more caching features of Docker for building the devel image. Downsite of this is that for users who heavily build the image it will eat up more disk space then before. But I think think only developers are affected here and all others will pull from the registry. A regular docker cleanup on the machines will solve this problem. * Upgrade python to python3 The main Dockerfile will build now a python3 based image. A copy of the old python2 file is still available for further testing.
2018-09-17 06:49:57 +00:00
FROM python3-base as post-builder
Full docker support (#830) * Full docker support Currently Docker images are build by a second git repository. Changes to installation or starting cowrie would need to be done on both. Merging this into one repository prevents that those will be forgotten and makes it easier to understand why changes happen. The dockerfile is a different one then the one from the docker-cowrie repository. I chose to use a python2-alpine linux. In the end this image has 55% smaller image size than the Debian image. The build process is split into to parts. The first image has everything installed to compile the python modules. The second one has only things installed which are needed to run the daemon. There is no need to install python-virtualenv because we are using docker. We don't need that much layers. Twisted can drop his privileges when starting the daemon when `--uid` and `--gid` is passed. This works only with numerical id. The user nobody is used for this. This is on Docker a good idea since there should be only one service with this user running. In other systems there might be several services using this daemon which is not a good choise. When building a new Docker image for cowrie Docker multistage build images are created running flake8 and unittests to ensure that all future releases are stable and matching our code guidelines. Bonus effect is when using this as a git pre-push-hook a developer doesn't need to wait for travis to fail on an error. Based on the current project structure we need a lot of `COPY` instructions inside the dockerfile which has negative sideeffects. - bloading the dockerfile up - longer buildtimes - more layers are created - more diskspace is used We should find a way to reduce this. Best way for doing this is keeping the static files like `honeyfs` and `share` right next to the source code. * Removing UID 0 check Cowrie checked on startup if it was started with root privileges. This conflicts with the option to let cowrie drop his privileges on startup using the twisted option `--uid` and `--gid`. I tested it a day ago without removing the code block and it run through but now it is for some reasons blocking. My feeling is that the code for droping privileges is also asynchron and sometimes the check is faster then the dropping of the privileges. But I might be wrong here. The solution is to remove the hole check. Considering that the check is there for preventing new users to shoot their feet we fixed this problem on different levels. New users should the docker images which are far easier to control and deploy then everything else because we take care. If a user wants to deploy it from scratch onto their serves there is a install instruction with detailed steps. This steps includes creating a special system user for cowrie and starting it with this user. * Fix missing directory, simplify path I missed to create the TTY log path. That's now fixed. Also the path for the trial command has been simplified. * Revert "Removing UID 0 check" This reverts commit f76329cd798744d10a0f52281e5a3588955d2531. * Introducint ENV var COWRIE_DOCKER The variable is used inside the docker image to let cowrie know that it is running inside docker and don't need to perform the "running as root" check. Inside the docker image cowrie is started with the `--uid` and `--gid` option and will drop to a different user then root. * Restructured Dockerfile, Added cowrie user The image is now builded with a user and group for running in the later image cowrie. Also the build steps are re-aranged to save build time. We assume that static files like `honeyfs` and `share` are less frequently updated and can be build into the base image where every other images is based on. * Renamed directory src -> cowrie The name cowrie should be more self-explaining then src. * Update cowrie_plugin.py
2018-08-06 08:27:32 +00:00
COPY --from=builder /root/wheelhouse /root/wheelhouse
Docker cacheing and python2 (#879) * Docker caching for devel Use more caching features of Docker for building the devel image. Downsite of this is that for users who heavily build the image it will eat up more disk space then before. But I think think only developers are affected here and all others will pull from the registry. A regular docker cleanup on the machines will solve this problem. * Upgrade python to python3 The main Dockerfile will build now a python3 based image. A copy of the old python2 file is still available for further testing.
2018-09-17 06:49:57 +00:00
RUN pip3 install -r requirements.txt --no-index --find-links=/root/wheelhouse
RUN pip3 install -r requirements-output.txt --no-index --find-links=/root/wheelhouse
Docker devel image (#871) * Docker devel image TL;DR Providing an docker image for local development. I wanted to have a container which has all the needed tools installed while developming (eg flake8, pytest, pydev, etc). The intermediate container `devel` can now be used by PyCharm as a Remote Interpreter and for debugging. No need to setup any local test environments because we can now use a pre-release image. Build the container with `docker build --target devel -t cowrie:devel .` from within the project root directory. While building the container I encountered a bug with the `python:2-alpine3.8` image and (at least, could be other OS also beeing affected) the macOS kernel trying to use `socket.SO_REUSEPORT`. After some testing I found out that the problem is just this image. So I could have just gone and downgraded to `python:2-alpine3.7` or switched over to `alpine:latest`. But none of them really convinced me after some research so I decided to switch the Docker image to `debian:stable-slim`. The resulting image is now slightly bigger then our previous image but should give a better experience while debugging stuff. Bonus point is that we have a functional installation description for Debian based systems. * New path for twisteds dropin.cache
2018-09-06 12:35:37 +00:00
FROM post-builder as pre-devel
Docker cacheing and python2 (#879) * Docker caching for devel Use more caching features of Docker for building the devel image. Downsite of this is that for users who heavily build the image it will eat up more disk space then before. But I think think only developers are affected here and all others will pull from the registry. A regular docker cleanup on the machines will solve this problem. * Upgrade python to python3 The main Dockerfile will build now a python3 based image. A copy of the old python2 file is still available for further testing.
2018-09-17 06:49:57 +00:00
RUN pip3 install flake8 flake8-import-order pytest
Full docker support (#830) * Full docker support Currently Docker images are build by a second git repository. Changes to installation or starting cowrie would need to be done on both. Merging this into one repository prevents that those will be forgotten and makes it easier to understand why changes happen. The dockerfile is a different one then the one from the docker-cowrie repository. I chose to use a python2-alpine linux. In the end this image has 55% smaller image size than the Debian image. The build process is split into to parts. The first image has everything installed to compile the python modules. The second one has only things installed which are needed to run the daemon. There is no need to install python-virtualenv because we are using docker. We don't need that much layers. Twisted can drop his privileges when starting the daemon when `--uid` and `--gid` is passed. This works only with numerical id. The user nobody is used for this. This is on Docker a good idea since there should be only one service with this user running. In other systems there might be several services using this daemon which is not a good choise. When building a new Docker image for cowrie Docker multistage build images are created running flake8 and unittests to ensure that all future releases are stable and matching our code guidelines. Bonus effect is when using this as a git pre-push-hook a developer doesn't need to wait for travis to fail on an error. Based on the current project structure we need a lot of `COPY` instructions inside the dockerfile which has negative sideeffects. - bloading the dockerfile up - longer buildtimes - more layers are created - more diskspace is used We should find a way to reduce this. Best way for doing this is keeping the static files like `honeyfs` and `share` right next to the source code. * Removing UID 0 check Cowrie checked on startup if it was started with root privileges. This conflicts with the option to let cowrie drop his privileges on startup using the twisted option `--uid` and `--gid`. I tested it a day ago without removing the code block and it run through but now it is for some reasons blocking. My feeling is that the code for droping privileges is also asynchron and sometimes the check is faster then the dropping of the privileges. But I might be wrong here. The solution is to remove the hole check. Considering that the check is there for preventing new users to shoot their feet we fixed this problem on different levels. New users should the docker images which are far easier to control and deploy then everything else because we take care. If a user wants to deploy it from scratch onto their serves there is a install instruction with detailed steps. This steps includes creating a special system user for cowrie and starting it with this user. * Fix missing directory, simplify path I missed to create the TTY log path. That's now fixed. Also the path for the trial command has been simplified. * Revert "Removing UID 0 check" This reverts commit f76329cd798744d10a0f52281e5a3588955d2531. * Introducint ENV var COWRIE_DOCKER The variable is used inside the docker image to let cowrie know that it is running inside docker and don't need to perform the "running as root" check. Inside the docker image cowrie is started with the `--uid` and `--gid` option and will drop to a different user then root. * Restructured Dockerfile, Added cowrie user The image is now builded with a user and group for running in the later image cowrie. Also the build steps are re-aranged to save build time. We assume that static files like `honeyfs` and `share` are less frequently updated and can be build into the base image where every other images is based on. * Renamed directory src -> cowrie The name cowrie should be more self-explaining then src. * Update cowrie_plugin.py
2018-08-06 08:27:32 +00:00
Docker devel image (#871) * Docker devel image TL;DR Providing an docker image for local development. I wanted to have a container which has all the needed tools installed while developming (eg flake8, pytest, pydev, etc). The intermediate container `devel` can now be used by PyCharm as a Remote Interpreter and for debugging. No need to setup any local test environments because we can now use a pre-release image. Build the container with `docker build --target devel -t cowrie:devel .` from within the project root directory. While building the container I encountered a bug with the `python:2-alpine3.8` image and (at least, could be other OS also beeing affected) the macOS kernel trying to use `socket.SO_REUSEPORT`. After some testing I found out that the problem is just this image. So I could have just gone and downgraded to `python:2-alpine3.7` or switched over to `alpine:latest`. But none of them really convinced me after some research so I decided to switch the Docker image to `debian:stable-slim`. The resulting image is now slightly bigger then our previous image but should give a better experience while debugging stuff. Bonus point is that we have a functional installation description for Debian based systems. * New path for twisteds dropin.cache
2018-09-06 12:35:37 +00:00
FROM pre-devel as devel
USER cowrie
Full docker support (#830) * Full docker support Currently Docker images are build by a second git repository. Changes to installation or starting cowrie would need to be done on both. Merging this into one repository prevents that those will be forgotten and makes it easier to understand why changes happen. The dockerfile is a different one then the one from the docker-cowrie repository. I chose to use a python2-alpine linux. In the end this image has 55% smaller image size than the Debian image. The build process is split into to parts. The first image has everything installed to compile the python modules. The second one has only things installed which are needed to run the daemon. There is no need to install python-virtualenv because we are using docker. We don't need that much layers. Twisted can drop his privileges when starting the daemon when `--uid` and `--gid` is passed. This works only with numerical id. The user nobody is used for this. This is on Docker a good idea since there should be only one service with this user running. In other systems there might be several services using this daemon which is not a good choise. When building a new Docker image for cowrie Docker multistage build images are created running flake8 and unittests to ensure that all future releases are stable and matching our code guidelines. Bonus effect is when using this as a git pre-push-hook a developer doesn't need to wait for travis to fail on an error. Based on the current project structure we need a lot of `COPY` instructions inside the dockerfile which has negative sideeffects. - bloading the dockerfile up - longer buildtimes - more layers are created - more diskspace is used We should find a way to reduce this. Best way for doing this is keeping the static files like `honeyfs` and `share` right next to the source code. * Removing UID 0 check Cowrie checked on startup if it was started with root privileges. This conflicts with the option to let cowrie drop his privileges on startup using the twisted option `--uid` and `--gid`. I tested it a day ago without removing the code block and it run through but now it is for some reasons blocking. My feeling is that the code for droping privileges is also asynchron and sometimes the check is faster then the dropping of the privileges. But I might be wrong here. The solution is to remove the hole check. Considering that the check is there for preventing new users to shoot their feet we fixed this problem on different levels. New users should the docker images which are far easier to control and deploy then everything else because we take care. If a user wants to deploy it from scratch onto their serves there is a install instruction with detailed steps. This steps includes creating a special system user for cowrie and starting it with this user. * Fix missing directory, simplify path I missed to create the TTY log path. That's now fixed. Also the path for the trial command has been simplified. * Revert "Removing UID 0 check" This reverts commit f76329cd798744d10a0f52281e5a3588955d2531. * Introducint ENV var COWRIE_DOCKER The variable is used inside the docker image to let cowrie know that it is running inside docker and don't need to perform the "running as root" check. Inside the docker image cowrie is started with the `--uid` and `--gid` option and will drop to a different user then root. * Restructured Dockerfile, Added cowrie user The image is now builded with a user and group for running in the later image cowrie. Also the build steps are re-aranged to save build time. We assume that static files like `honeyfs` and `share` are less frequently updated and can be build into the base image where every other images is based on. * Renamed directory src -> cowrie The name cowrie should be more self-explaining then src. * Update cowrie_plugin.py
2018-08-06 08:27:32 +00:00
Docker devel image (#871) * Docker devel image TL;DR Providing an docker image for local development. I wanted to have a container which has all the needed tools installed while developming (eg flake8, pytest, pydev, etc). The intermediate container `devel` can now be used by PyCharm as a Remote Interpreter and for debugging. No need to setup any local test environments because we can now use a pre-release image. Build the container with `docker build --target devel -t cowrie:devel .` from within the project root directory. While building the container I encountered a bug with the `python:2-alpine3.8` image and (at least, could be other OS also beeing affected) the macOS kernel trying to use `socket.SO_REUSEPORT`. After some testing I found out that the problem is just this image. So I could have just gone and downgraded to `python:2-alpine3.7` or switched over to `alpine:latest`. But none of them really convinced me after some research so I decided to switch the Docker image to `debian:stable-slim`. The resulting image is now slightly bigger then our previous image but should give a better experience while debugging stuff. Bonus point is that we have a functional installation description for Debian based systems. * New path for twisteds dropin.cache
2018-09-06 12:35:37 +00:00
FROM pre-devel as tests
COPY src /cowrie
Full docker support (#830) * Full docker support Currently Docker images are build by a second git repository. Changes to installation or starting cowrie would need to be done on both. Merging this into one repository prevents that those will be forgotten and makes it easier to understand why changes happen. The dockerfile is a different one then the one from the docker-cowrie repository. I chose to use a python2-alpine linux. In the end this image has 55% smaller image size than the Debian image. The build process is split into to parts. The first image has everything installed to compile the python modules. The second one has only things installed which are needed to run the daemon. There is no need to install python-virtualenv because we are using docker. We don't need that much layers. Twisted can drop his privileges when starting the daemon when `--uid` and `--gid` is passed. This works only with numerical id. The user nobody is used for this. This is on Docker a good idea since there should be only one service with this user running. In other systems there might be several services using this daemon which is not a good choise. When building a new Docker image for cowrie Docker multistage build images are created running flake8 and unittests to ensure that all future releases are stable and matching our code guidelines. Bonus effect is when using this as a git pre-push-hook a developer doesn't need to wait for travis to fail on an error. Based on the current project structure we need a lot of `COPY` instructions inside the dockerfile which has negative sideeffects. - bloading the dockerfile up - longer buildtimes - more layers are created - more diskspace is used We should find a way to reduce this. Best way for doing this is keeping the static files like `honeyfs` and `share` right next to the source code. * Removing UID 0 check Cowrie checked on startup if it was started with root privileges. This conflicts with the option to let cowrie drop his privileges on startup using the twisted option `--uid` and `--gid`. I tested it a day ago without removing the code block and it run through but now it is for some reasons blocking. My feeling is that the code for droping privileges is also asynchron and sometimes the check is faster then the dropping of the privileges. But I might be wrong here. The solution is to remove the hole check. Considering that the check is there for preventing new users to shoot their feet we fixed this problem on different levels. New users should the docker images which are far easier to control and deploy then everything else because we take care. If a user wants to deploy it from scratch onto their serves there is a install instruction with detailed steps. This steps includes creating a special system user for cowrie and starting it with this user. * Fix missing directory, simplify path I missed to create the TTY log path. That's now fixed. Also the path for the trial command has been simplified. * Revert "Removing UID 0 check" This reverts commit f76329cd798744d10a0f52281e5a3588955d2531. * Introducint ENV var COWRIE_DOCKER The variable is used inside the docker image to let cowrie know that it is running inside docker and don't need to perform the "running as root" check. Inside the docker image cowrie is started with the `--uid` and `--gid` option and will drop to a different user then root. * Restructured Dockerfile, Added cowrie user The image is now builded with a user and group for running in the later image cowrie. Also the build steps are re-aranged to save build time. We assume that static files like `honeyfs` and `share` are less frequently updated and can be build into the base image where every other images is based on. * Renamed directory src -> cowrie The name cowrie should be more self-explaining then src. * Update cowrie_plugin.py
2018-08-06 08:27:32 +00:00
ENV PYTHONPATH=/cowrie
WORKDIR /cowrie
Docker devel image (#871) * Docker devel image TL;DR Providing an docker image for local development. I wanted to have a container which has all the needed tools installed while developming (eg flake8, pytest, pydev, etc). The intermediate container `devel` can now be used by PyCharm as a Remote Interpreter and for debugging. No need to setup any local test environments because we can now use a pre-release image. Build the container with `docker build --target devel -t cowrie:devel .` from within the project root directory. While building the container I encountered a bug with the `python:2-alpine3.8` image and (at least, could be other OS also beeing affected) the macOS kernel trying to use `socket.SO_REUSEPORT`. After some testing I found out that the problem is just this image. So I could have just gone and downgraded to `python:2-alpine3.7` or switched over to `alpine:latest`. But none of them really convinced me after some research so I decided to switch the Docker image to `debian:stable-slim`. The resulting image is now slightly bigger then our previous image but should give a better experience while debugging stuff. Bonus point is that we have a functional installation description for Debian based systems. * New path for twisteds dropin.cache
2018-09-06 12:35:37 +00:00
RUN flake8 --count --application-import-names cowrie --max-line-length=120 --statistics . && \
trial cowrie
FROM post-builder as pre-release
Docker cacheing and python2 (#879) * Docker caching for devel Use more caching features of Docker for building the devel image. Downsite of this is that for users who heavily build the image it will eat up more disk space then before. But I think think only developers are affected here and all others will pull from the registry. A regular docker cleanup on the machines will solve this problem. * Upgrade python to python3 The main Dockerfile will build now a python3 based image. A copy of the old python2 file is still available for further testing.
2018-09-17 06:49:57 +00:00
RUN apt-get remove -y python3-pip && \
Docker devel image (#871) * Docker devel image TL;DR Providing an docker image for local development. I wanted to have a container which has all the needed tools installed while developming (eg flake8, pytest, pydev, etc). The intermediate container `devel` can now be used by PyCharm as a Remote Interpreter and for debugging. No need to setup any local test environments because we can now use a pre-release image. Build the container with `docker build --target devel -t cowrie:devel .` from within the project root directory. While building the container I encountered a bug with the `python:2-alpine3.8` image and (at least, could be other OS also beeing affected) the macOS kernel trying to use `socket.SO_REUSEPORT`. After some testing I found out that the problem is just this image. So I could have just gone and downgraded to `python:2-alpine3.7` or switched over to `alpine:latest`. But none of them really convinced me after some research so I decided to switch the Docker image to `debian:stable-slim`. The resulting image is now slightly bigger then our previous image but should give a better experience while debugging stuff. Bonus point is that we have a functional installation description for Debian based systems. * New path for twisteds dropin.cache
2018-09-06 12:35:37 +00:00
apt-get autoremove -y && \
apt-get autoclean -y && \
rm -rf /root/wheelhouse && \
rm -rf /var/lib/apt/lists/* && \
rm -rf /var/log/*
COPY src /cowrie
Fix permissions inside Docker image (#873) Some developers have different file permissions in their source directory. This could lead to unusable Docker images. We enforce now the correct file permissions during our Docker build.
2018-09-06 15:36:08 +00:00
RUN find /cowrie -type d -exec chmod 755 {} \; && \
find /cowrie -type f -exec chmod 744 {} \;
Full docker support (#830) * Full docker support Currently Docker images are build by a second git repository. Changes to installation or starting cowrie would need to be done on both. Merging this into one repository prevents that those will be forgotten and makes it easier to understand why changes happen. The dockerfile is a different one then the one from the docker-cowrie repository. I chose to use a python2-alpine linux. In the end this image has 55% smaller image size than the Debian image. The build process is split into to parts. The first image has everything installed to compile the python modules. The second one has only things installed which are needed to run the daemon. There is no need to install python-virtualenv because we are using docker. We don't need that much layers. Twisted can drop his privileges when starting the daemon when `--uid` and `--gid` is passed. This works only with numerical id. The user nobody is used for this. This is on Docker a good idea since there should be only one service with this user running. In other systems there might be several services using this daemon which is not a good choise. When building a new Docker image for cowrie Docker multistage build images are created running flake8 and unittests to ensure that all future releases are stable and matching our code guidelines. Bonus effect is when using this as a git pre-push-hook a developer doesn't need to wait for travis to fail on an error. Based on the current project structure we need a lot of `COPY` instructions inside the dockerfile which has negative sideeffects. - bloading the dockerfile up - longer buildtimes - more layers are created - more diskspace is used We should find a way to reduce this. Best way for doing this is keeping the static files like `honeyfs` and `share` right next to the source code. * Removing UID 0 check Cowrie checked on startup if it was started with root privileges. This conflicts with the option to let cowrie drop his privileges on startup using the twisted option `--uid` and `--gid`. I tested it a day ago without removing the code block and it run through but now it is for some reasons blocking. My feeling is that the code for droping privileges is also asynchron and sometimes the check is faster then the dropping of the privileges. But I might be wrong here. The solution is to remove the hole check. Considering that the check is there for preventing new users to shoot their feet we fixed this problem on different levels. New users should the docker images which are far easier to control and deploy then everything else because we take care. If a user wants to deploy it from scratch onto their serves there is a install instruction with detailed steps. This steps includes creating a special system user for cowrie and starting it with this user. * Fix missing directory, simplify path I missed to create the TTY log path. That's now fixed. Also the path for the trial command has been simplified. * Revert "Removing UID 0 check" This reverts commit f76329cd798744d10a0f52281e5a3588955d2531. * Introducint ENV var COWRIE_DOCKER The variable is used inside the docker image to let cowrie know that it is running inside docker and don't need to perform the "running as root" check. Inside the docker image cowrie is started with the `--uid` and `--gid` option and will drop to a different user then root. * Restructured Dockerfile, Added cowrie user The image is now builded with a user and group for running in the later image cowrie. Also the build steps are re-aranged to save build time. We assume that static files like `honeyfs` and `share` are less frequently updated and can be build into the base image where every other images is based on. * Renamed directory src -> cowrie The name cowrie should be more self-explaining then src. * Update cowrie_plugin.py
2018-08-06 08:27:32 +00:00
Docker devel image (#871) * Docker devel image TL;DR Providing an docker image for local development. I wanted to have a container which has all the needed tools installed while developming (eg flake8, pytest, pydev, etc). The intermediate container `devel` can now be used by PyCharm as a Remote Interpreter and for debugging. No need to setup any local test environments because we can now use a pre-release image. Build the container with `docker build --target devel -t cowrie:devel .` from within the project root directory. While building the container I encountered a bug with the `python:2-alpine3.8` image and (at least, could be other OS also beeing affected) the macOS kernel trying to use `socket.SO_REUSEPORT`. After some testing I found out that the problem is just this image. So I could have just gone and downgraded to `python:2-alpine3.7` or switched over to `alpine:latest`. But none of them really convinced me after some research so I decided to switch the Docker image to `debian:stable-slim`. The resulting image is now slightly bigger then our previous image but should give a better experience while debugging stuff. Bonus point is that we have a functional installation description for Debian based systems. * New path for twisteds dropin.cache
2018-09-06 12:35:37 +00:00
FROM pre-release as release
Docker output (#869) * Full Docker support for output plugins cowrie makes more fun if there are also all the output plugins available inside the docker image. And now they are! * Fixing wrong requirements: snappy vs python-snappy snappy: “SnapPy is a package for studying the topology and geometry of 3-manifolds, with a focus on hyperbolic structures. It is based on the SnapPea kernel written by Jeff Weeks.” python-snappy: “Python bindings for the snappy compression library from Google.” We want python-snappy. ;) * MAINTAINER argument deprecated in Docker The MAINTAINER keyword is deprecated in Docker and is replaced with the new syntax. Also it is now attached to the right container and not to one we actually throw away.
2018-09-02 05:57:21 +00:00
LABEL maintainer="Florian Pelgrim <florian.pelgrim@craneworks.de>"
Full docker support (#830) * Full docker support Currently Docker images are build by a second git repository. Changes to installation or starting cowrie would need to be done on both. Merging this into one repository prevents that those will be forgotten and makes it easier to understand why changes happen. The dockerfile is a different one then the one from the docker-cowrie repository. I chose to use a python2-alpine linux. In the end this image has 55% smaller image size than the Debian image. The build process is split into to parts. The first image has everything installed to compile the python modules. The second one has only things installed which are needed to run the daemon. There is no need to install python-virtualenv because we are using docker. We don't need that much layers. Twisted can drop his privileges when starting the daemon when `--uid` and `--gid` is passed. This works only with numerical id. The user nobody is used for this. This is on Docker a good idea since there should be only one service with this user running. In other systems there might be several services using this daemon which is not a good choise. When building a new Docker image for cowrie Docker multistage build images are created running flake8 and unittests to ensure that all future releases are stable and matching our code guidelines. Bonus effect is when using this as a git pre-push-hook a developer doesn't need to wait for travis to fail on an error. Based on the current project structure we need a lot of `COPY` instructions inside the dockerfile which has negative sideeffects. - bloading the dockerfile up - longer buildtimes - more layers are created - more diskspace is used We should find a way to reduce this. Best way for doing this is keeping the static files like `honeyfs` and `share` right next to the source code. * Removing UID 0 check Cowrie checked on startup if it was started with root privileges. This conflicts with the option to let cowrie drop his privileges on startup using the twisted option `--uid` and `--gid`. I tested it a day ago without removing the code block and it run through but now it is for some reasons blocking. My feeling is that the code for droping privileges is also asynchron and sometimes the check is faster then the dropping of the privileges. But I might be wrong here. The solution is to remove the hole check. Considering that the check is there for preventing new users to shoot their feet we fixed this problem on different levels. New users should the docker images which are far easier to control and deploy then everything else because we take care. If a user wants to deploy it from scratch onto their serves there is a install instruction with detailed steps. This steps includes creating a special system user for cowrie and starting it with this user. * Fix missing directory, simplify path I missed to create the TTY log path. That's now fixed. Also the path for the trial command has been simplified. * Revert "Removing UID 0 check" This reverts commit f76329cd798744d10a0f52281e5a3588955d2531. * Introducint ENV var COWRIE_DOCKER The variable is used inside the docker image to let cowrie know that it is running inside docker and don't need to perform the "running as root" check. Inside the docker image cowrie is started with the `--uid` and `--gid` option and will drop to a different user then root. * Restructured Dockerfile, Added cowrie user The image is now builded with a user and group for running in the later image cowrie. Also the build steps are re-aranged to save build time. We assume that static files like `honeyfs` and `share` are less frequently updated and can be build into the base image where every other images is based on. * Renamed directory src -> cowrie The name cowrie should be more self-explaining then src. * Update cowrie_plugin.py
2018-08-06 08:27:32 +00:00
ENV PYTHONPATH=/cowrie
WORKDIR /cowrie
EXPOSE 2222/tcp
EXPOSE 2223/tcp
USER cowrie
Docker cacheing and python2 (#879) * Docker caching for devel Use more caching features of Docker for building the devel image. Downsite of this is that for users who heavily build the image it will eat up more disk space then before. But I think think only developers are affected here and all others will pull from the registry. A regular docker cleanup on the machines will solve this problem. * Upgrade python to python3 The main Dockerfile will build now a python3 based image. A copy of the old python2 file is still available for further testing.
2018-09-17 06:49:57 +00:00
CMD /usr/bin/python3 /usr/local/bin/twistd --umask 0022 --nodaemon --pidfile= -l - cowrie