Lab 11:

#### Question 1 :Compare and contrast ENTRYPOINT and CMD in Dockerfile. In what situation would you use each of them?
Answer:
CMD allows us to set a default command which will be executed only when we run a container without specifying a command. ENTRYPOINT is similar to CMD, in the sense that it allows us to specify a command with parameters, the difference is that the ENTRYPOINT command and parameters are not ignored when the container is run with command line parameters. ENTRYPOINT is preferred to CMD when building an
executable Docker image where we need a command to always to be executed without the ability to overwrite it from command line.

#### Question 2 :List five security precautions you will take when building or deploying a Docker resource (image or container).

Answer:
##### Limit Container Resources
When a container is compromised, attackers may try to make use of the underlying host resources to perform malicious activity. Set Docker memory and CPU usage limits to minimize the impact of breaches for resource-intensive containers. In Docker, the default setting is to allow the container to access all RAM and CPU resources on the host. It is important to set resource quotas, to limit the resources your container can use—for security reasons, and to ensure each container has the appropriate resources and does not disrupt other services running on the host.

##### Set Filesystem and Volumes to Read-only
Set Filesystem and Volumes to Read-only A simple and effective security trick is to run containers with a read-only filesystem. This can prevent malicious activity such as deploying malware on the container or modifying configuration.
The following code sets a Docker container to read only:

docker run --read-only alpine sh -c 'echo "running as read only" > /tmp' 

##### Restrict System Calls from Within Containers
In a container, you can choose to allow or deny any system calls. Not all system calls are required to run a container. With this in mind, you can monitor the container, obtain a list of all system calls made, explicitly allow those calls and no others. It is important to base your configuration on observation of the container at runtime, because you may not be aware of the specific system calls used by your container’s components, and how those calls are named in the underlying operating system.

##### Use Minimal Base Images
Docker images are commonly built on top of “base images”. While this is convenient, because it avoids having to configure an image from scratch, it raises security concerns. You may use a base image with components that are not really required for your purposes. A common example is using a base image with a full Debian Stretch distribution, whereas your specific project does not really require operating system libraries or utilities.
##### Don’t Leak Sensitive Info to Docker Images
Docker images often require sensitive data for their normal operations, such as credentials, tokens, SSH keys, TLS certificates, database names or connection strings. In other cases, applications running in a container may generate or store sensitive data. Sensitive information should never be hardcoded into the Dockerfile—it will be copied to Docker containers, and may be cached in intermediate container layers, even if you attempt to delete them.

#### Question 3 :Show a single line command that will remove all exited Docker containers. Do not use any text filtering editor. Show test results.

Answer:

#### Question 4 :Show how you can copy files to a running container without entering the container’s interactive shell.

Answer:

#### Question 5: Create a dockerized web application running on nginx. The web index page index.html should be located on your host machine. The directory containing the index page should be mounted to the container and served from there.

Answer:
We run default nginx container using:
``docker run -p 5555:80 --name my-nginx-container -d nginx``
To serve our site we use volumes to link a directory from host to container as following:
If we visit localhost:5555 we will get
Now we edit our html file and check the site:

#### Question 6:Setup rsyslog on your host machine as a central logging server. Create a Docker container and configure it to forward its log to your central logging server.

Answer:
We create `/etc/docker/daemon.json` to set logging configuration settings for Docker daemon for all new containers.

Or we add to run command `--log-driver syslog --log-opt
syslog-address=unixgram:///dev/log` when running new containers. Now to test we run a docker that simply print something to the STDOUT in containers that are sent by Docker daemon to /dev/log system socket. Rsyslog collects these logs from the socket, processes them and writes to /var/log/docker/{{.Name}}.log files. We

find the error message using journalctl:

#### BONUS 2:
The Dockerfile has the following issues:

- It uses Alpine as the base image, but then attempts to install packages using apt-get, which is not available in Alpine.
- The Dockerfile creates the index.html file in the root directory instead of in the web directory where it is expected to be.
- The CMD directive uses Python 3 syntax, but the image installs only Python 2.7.

Here is the fixed version:

FROM python:3-alpine
WORKDIR /web
RUN echo "<html><h1>Testing web</h1></html>" > index.html
CMD ["python", "-m", "http.server"]

To build and run the fixed image, you can use the following commands:

docker build -t my-web-image .
docker run -p 8000:8000 my-web-image

This will start the container and map port 8000 on the host to port 8000 inside the container, allowing you to access the web page by navigating to http://localhost:8000 in a web browser.