One of the concepts that will come up on the Security+ exam is that of ‘containerization.’

• A recurring theme in this version of Security+ is the importance of deploying applications using best practices like virtualization and isolation, with micro-segmentation being a key technique for enhancing functionality and security. Docker containerization is one way this can be achieved.

Generally speaking, any time you need an application like Apache2, for example, it’s a relatively simple process to *apt install* that sucker.

• Think long term: What problems does this cause?

  • Portability: That configuration is now tied to that computer or virtual machine.
    • Yes, a virtual machine can be moved, but VMWare VMs are like +20 GB. That is not exactly the definition of portable!
    • If you install and configure Apache with all the necessary modules, you are stuck using that computer until it dies. Complex configurations tied to a single host can also be difficult to recover in a disaster.
  • Security: Having multiple apps on the same computer is 1-Tier. If any application is compromised on the host, everything else is compromised.
  • Scalability: You set up a web server, which gets crushed by 1 million hits. If you don’t build an application with scalability, you’ll likely reinvent the wheel to deal with overwhelming resource requests.
  • Fault tolerance: What happens if your computer does die and you can’t access the data or application configurations? You get fired. That’s what!

  Docker is a containerization technology that solves these problems and is easy to use once you get used to it.

  • Docker containers are lightweight, super-fast VMs (sort of!) that have a single purpose.
    • Instead of installing an entire operating system in something like VMWare, Docker images will only ship with precisely what your application needs to function.
  • Docker images are portable and easily deployed.
    • Let’s say you have a web application running in a docker container.
    • Let’s say that Docker container gets compromised.
    • If you ‘commit’ changes to a Docker container once you are finished installing it and everything is working as intended, it’s super easy to burn the compromised node and spin up a fresh version that has only ever been touched by you.
  • Docker images provide isolation and micro-segmentation:
    • A typical Docker deployment might look like this

      • Let’s say you want to run an application that needs:

        • Apache2
        • MySQL

      • You could create multiple docker images that work together.

        • One Docker image would host the Apache2 server with PHP installed
        • One Docker image would contain the folders and files the web server is hosting
        • One Docker image would contain the database server application
          • You could create a separate docker image containing the data the database server manages.
        • This way, if a malicious user compromised the Apache2 server, the MySQL application isn’t running in the same process space.
        • Let’s say you want to upgrade your version of Apache2.
          • You could burn the container running the webserver application.
            • The container with the webpage data and folders never has to be touched.
          • You could then deploy a newer version of the Apache2 server and tell it to use the existing Docker containers that contain all your data.
        • Let’s say your Apache2 server gets slammed with 1 million hits
          • You can use ‘Kubernetes’ (Koo - Bur - Net - ease) to load balance and spin up exact duplicates of these servers on separate physical hosts.
            • There are many jobs for folks who deploy and configure Kubernetes to manage docker images like this. Without a college degree, they can earn 90k a year.

        In this lab, we will learn to work with the fundamental aspects of Docker.

        • Good news: You may not have to deal with most of the fundamental setup we’ll do in these labs in everyday situations.
        • There are thousands of pre-configured docker images online that are easy to download and start. Instead of spending time installing and troubleshooting a tool or application you need, you can pull a preconfigured docker image and use that instead. Someone else will have already done all the work for you! This can save you hours of your time regularly.
        • The Catch: Without understanding the fundamental underlying aspects, you’ll never be able to make your life 1000x easier when the Docker option is the easy option!

        Start by installing docker.io (Let’s use Kali)

        • NOTE: At iCSI, it’s best to use the 2024_KALI template for this.

        apt install docker.io
        

        Although it is possible to build a docker image from scratch, you will usually find something preconfigured and then build in whatever you need from there. The place to go for all things docker is here:

        <https://hub.docker.com/>
        

        Creating an account isn’t necessary. You can search for images from the front page.

        

        In either case, we’ll end up searching for Apache2.

        

        Before we download anything, let’s take a look at the ‘tags’ section. Every docker image will always provide the ability to download previous versions/releases. These ‘tags’ simply allow us to specify which version we want to download. If you are interested in spinning up vulnerable software at home so you can try to exploit it, pulling down a docker version of the application using an old version number (or tag) is usually a good way to get that done.

        

        In this case we’ll be using the ‘docker pull’ command to download the ‘latest’ version.

        

        

        We just downloaded a Docker image. Images are saved versions that will only change if we commit changes to them.

        We can verify which docker images we have downloaded with this command:

        docker images
        

        

        181MB. Not too bad for an operating system! (Your version may be a different size.)

        Now that we have an image on disk we can use, we’ll want to spin up a container created from this image.

        We’ll start like this:

        docker run ubuntu/apache2
        

        

        You’ll see that you can’t type anymore, which isn’t ideal. Nothing I have tried will allow me to easily return to the shell after running a container the way we just did.

        • You’ll need to close this terminal session and open a new one manually.
        • I’ll show you how to spin up docker containers with the -d parameter later, which will return the shell to you.

        Once you are back, let’s check to see if the docker container is still running with this command:

        docker ps
        

        

        It is indeed still running. Notice that by simply using docker run Docker assigned two things:

        • A container ID we can not control
        • A container name that we can. (We’ll do that in the next lab)

        Let’s stop this container and burn it.

        docker stop <container_name>
        #Example: docker stop hopeful_swanson
        docker container prune
        #This will delete ALL docker container prune
        

        

        If you check the running containers, you’ll see that none are running.

        docker ps
        

        

        Now that we’ve stopped and deleted the running container let’s take a look at the images.

        docker images
        

        

        Checkpoint: Show the instructor that the ‘docker images’ command reports that you have your Ubuntu/apache2 image ready to go for the next lab!