I'm trying to create an assignment for students to do that contains the following :
A docker image with issues that have to be scanned and remedied. (using an opensource scanner in kubernetes)
(Maybe) A sample attack scenario that can exploit those vulnerabilities.
The problem arises when I try to find a suitable vulnerable image or create one. I cannot find a base of security issues at all. I really bend my back thinking of a suitable phrase in Google but everything leads merely to some blog posts about how-to scan an image.
I expected a database that might contain multiple sec issues and what causes them. I'd also expect some way to discern which are the most popular ones.
Do you have the source I require ?
Maybe you can just offer me 3-4 common security issues that are good to know and educational when having your first brush with docker ? (And how to create those issues ?)
The whole situation would have been probably easier if I myself would have been an expert in the field, but the thing I do is also my assignment as a student. (So as students we design assignments for each other. )
Looks like you are looking for the Container security hardening and Kubernetes security options maybe.
You can use some tools like
kubesec - Security risk analysis for Kubernetes resources
checkov - Prevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open-source packages
Trivy - vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
If you are looking for some questions you can set like, this is CKS (Certified Kubernetes Security) exam question
There are a number of pods/container running in the "spectacle" namespace.
Identify and delete the pods which have CRITICAL vulnerabilities.
For this trivy opensource tools comes into the picture to scan the image that you will be using in the deployment of Kubernetes or docker
trivy image --severity CRITICAL nginx:1.16 (Image running in container)
List of few questions you can create lab out of it : https://github.com/moabukar/CKS-Exercises-Certified-Kubernetes-Security-Specialist/tree/main/7-mock-exam-questions
Related
I am researching shared libraries between containers from security point of view.
In many security resources, the shared library scenario, where containers share dependency reference (i.e. same file) is discussed, I can come up with two scenarios:
De-facto discussed scenario - where some lib directory is mounted from the host machine to container
Invented scenario - where a shared volume is created for different containers (different services, replicate set of same container, or both), and it is populated with libraries which are shared between all of the containers.
Despite the discussions, I was not able to find this kind of behavior in real world, so the question is: How common is this approach?
A reference to an official and known image which uses this technique would be great!
This is generally not considered a best practice at all. A single Docker image is intended to be self-contained and include all of the application code and libraries it needs to run. SO questions aside, I’ve never encountered a Docker image that suggests using volumes to inject any sort of code into containers.
(The one exception is the node image; there’s a frequent SO question about using an anonymous volume for node_modules directories [TL;DR: changes in package.json never update the volume] but even then this is trying to avoid sharing the library tree with other contexts.)
One helpful technique is to build an intermediate base image that contains some set of libraries, and then building an application on top of that. At a mechanical level, for a particular version of the ubuntu:18.04 image, I think all other images based on that use the physically same libc.so.6, but from a Docker point of view this is an implementation detail.
I am new to Docker and want to learn the ropes with real-life challenges.
I have an application hosted on IIS and has dependencies over SQL Express and SOLR.
I want to understand the following:
Is it possible to have my whole set-up, including of enabling IIS,
SQL, SOLR and my application in one single container?
If point 1 is feasible, how should I start with it?
Sorry if my questions are basics.
It is feasible, just not a good practice. You want to isolate the software stack to improve the mantainability (easier to deploy updates), modularity (you can reuse a certain component in a different project and even have multiple projects reusing the same image) and security (a software vulnerability in a component of the stack will hardly be able to reach a different component).
So, instead of putting all together into the same image, I do recommend using Docker Compose to have multiple images for each component of the stack (you can even pull generic, up-to-date images from Docker Hub) and assemble them up from the Compose file, so with a single command you can fire up all the components needed for your application to work.
That being said, it is feasible to have all the stack together into the same Dockerfile, but it will be an important mess. You'll need a Dockerfile that installs all the software required, which will make it bulky and hard to mantain. If you're really up for this, you'll have to start from a basic OS image (maybe Windows Server Core IIS) and from there start installing all the other software manually. If there are Dockerfiles for the other components you need to install and they share the same base image or a compatible one, you can straight copy-paste the contents into your Dockerfile, at the cost of said mantainability.
Also, you should definitely use volumes to keep your data safe, especially if you take this monolithic approach, since you risk losing data from the database otherwise.
TL;DR: yes, you can, but you really don't want to since there are much better alternatives that are almost as hard.
I would like to compose multiple Docker images that start with different bases. However, many of the installation scripts afterward are similar.
What's the best way to source a sub Docker file?
Sounds like what you're looking for is the ability to include Dockerfiles in other Dockerfiles. There was a proposal for such a feature, but currently there is nothing that supports this out of the box. The discussion is worth reading through because it includes links to tools like harbor and dfpp that people built to a support a subset of the functionality.
One problem with tools like this is that you can't easily make the same include file work for debian, centos, and alpine linux (for example). The way this is currently addressed (like redis and redis-alpine images for essentially the same software) is to have duplicate dockerfiles.
Why should I consider using Rocket instead of Docker in our development pipeline. We would like to use docker to create testable containers, but now there is Rocket which pretends to know the same. If we would like to start containerization should we seriously consider Rocket as it seems it is still pretty new?
There is not much information about Rocket, so I'm no clear where it stays now in 2015.
UPDATE: from https://coreos.com/blog/app-container-and-the-open-container-project/
As we participate in OCP, our primary goals are as follows:
Users should be able to package their application once and have it work with any container runtime (like Docker, rkt, Kurma, or Jetpack)
The standard should fulfill the requirements of the most rigorous security and production environments
The standard should be vendor neutral and developed in the open
Rocket is officially dead: https://github.com/rkt/rkt/issues/4024
After acquisition by Red Hot new owner concentrates efforts on https://podman.io/
podman provides rootless containers. Something that Docker strove to get for a long time (according to the below comment, they finally managed).
As with most competitors both have their advantage and disandvantages.
Docker hub offers a public registry where docker images can be pushed and pulled with ease.
There is also now a free registry offered by GitLab! Its really good.
A core issue at the moment is security. Docker now scan their images for security flaws and report on the security status of each image.
With rocket image signatures are cross checked with the signature of the publisher to see if they have been tampered with. This affords a degree of confidence.
For a fuller discussion on security see https://bobcares.com/blog/docker-vs-rkt-rocket/
With regards standards, it seems that OCI (Open Container Initiative) has been adopted by the big players and will pave the way forward for containerisation standatisation.
I know we can create docker images using ansible. I'm learning and doing POC work.
I'm trying to find what are the pros/cons of creating a docker image using Ansible.
Would like to hear if you have played and found any issues/solutions with creating docker images (NOT deploying docker images) using ansible?
Also, are there any good reasons not to create docker images using Ansible?
It can be a good choice.
If an agentless system is good enough for your needs, keeping your Docker images lightweight (by not having any agent in them) is a reasonable thing to desire.
If your ops team uses Ansible, using the same playbooks in configuring your Docker images (used for dev/test) as for production is desirable.
If your production environment uses Docker in the manner in which it's intended to be used, then you have reduced need for complex logic around maintenance and upkeep of existing systems, which makes Ansible a better option.
That said, I also have a laundry list of complaints about Ansible -- particularly, in places where its DSL is poorly designed in ways that make automating generation of playbooks error-prone, and places where functionality present in some of its competitors (albeit not particularly relevant to Docker image generation) was designed in only as an afterthought.
No tool is perfect; the decision in terms of what meets your needs and fails only in ways you find acceptable needs to be made in the context of your own use cases.