The host on which the containers are running
Run the docker security bench on every node that runs docker containers https://github.com/docker/docker-bench-security
Running the following command on a node that runs docker containers:
docker run -it --net host --pid host --cap-add audit_control \
-e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
Docker is still in development.
As with every other software in-dev bugs will happen, insecure features might be added, there could be architectural flaws that lead to security breaches. Do not underestimate this! Your system might be completely safe today, but with the patch from next week someone finds a bug, writes an exploit, and suddenly your system is ...
Docker images itself
An additional option is to use Clair.
Clair is an open source project for the static analysis of
vulnerabilities in application containers (currently including appc
In regular intervals, Clair ingests vulnerability metadata from a configured set of sources and stores it in the database.
Clients use the ...
In addition to the points in this thread; the following would be my recommendation:
Get control over Docker PID1 with dumb-init
ref: PID1 and Zombie reaping problem
Do not run docker in production without a container orchestration system
Take your pick from Kubernetes, Mesos, Swarm etc.
Use gosu for user control inside a docker image
Follow the 12 ...
You might also want to run a scan for security vulnerabilities of some sample base images so your students get an idea of how changing the base can affect how secure your image is. For example comparing an alpine image versus a full blown Ubuntu image (especially some of the older Ubuntu images).
Clair is a decent scanner that can be set up fairly easily in ...
A tool that I think is rather under recognised is s2i. The basic idea is that you don’t put a Dockerfile into your source repo specifying the runtime to use you keep your app code bare (just code). The decision as to which security patched s2i image to compile and run the code with is a separate matter that is independent and can be centrally managed.
Containers isolate an application on a shared OS, VM's isolate an OS on shared hardware. With those different levels of abstraction, you have different exploits and protections.
A successful kernel level exploit on a container will affect the shared kernel, and therefore breakout of the container isolation. Think meltdown and spectre.
A successful VM ...
A good source for statistics could be stackshare.io.
In general, polyglot services i.e. teams delivering different stacks could create silos, and additional overhead for diverse toolchains; nevertheless I consider that larger organizations have the polyglot situation organically because this type of thing is not always an issue of top-management.
Have a look at "Ingress" and "Cert-Manager":
With a Kubernetes Ingress you can configure the load balancer, see e.g. https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer
With "Cert-Manager" you can get certificates from Let's Encrypt (like certbot does), and it handles renewing automatically. See https://github.com/jetstack/cert-manager
What could be a feasible way to motivate Maven and repository makers to establish some kind of early time warning, like issue special headers on download, or and additionally for example reject download of vulnerable components by default?
Your concern, i.e. the meat of your question is a very valid one: how to improve security when downloading "stuff" from ...
No, you don't need maven.
Maven is a build automation tool as ant and gradle are, generally, but not limited to, jvm based projects.
Nexus is an artifact repository, but some others exists.
Artifact repositories software have different set of features (license, different storage options, different repositories type support like gems or npm ..., search ...
If you are filling up your docker entrypoint with sed commands, consider this practice:
Use a tool such as confd to manage your docker images configuration files and keep them updated
Confd will read data from many supported key-value stores and render configuration templates dynamically.
When you're running ephemeral workloads like you would on a spot instance the best bet, if you don't want to bake an ami, is going to be a secret store of some kind.
The two most common methods I've seen for doing this are:
If your provisioning tool (terraform, cloudformation, salt cloud) allows it then you can create a kms key and use it to encrypt ...
I would recommend you use their Google Cloud Secrets Engine. Documentation is here: https://www.vaultproject.io/docs/secrets/gcp/index.html
Managing such sensitive secrets by any means other than a Vault service is dangerous.
In my experience with "raising awareness about security" (for technical-minded people) is simply to show them the problem in action.
Find out what concrete, practical problems actually exist, and just show them (by actually showing, or by having them find out for themselves).
All docker security problems I've come upon have been quite self-evident and kind ...
Docker Bench is a scripted report of many of the CIS recommendations (at least those that can be scripted. Various organizations use the CIS recommendations as a starting point for their security policy, the goal is to have a recognized organization provide the best practices. This is useful when dealing with auditors in regulated environments since a ...
Larger organizations are concerned that containers introduce more security risks than traditional VMs as there isn't any hypervisor segregation. Developers running arbitrary images, that run as root, that they don't bother to security patch, looks worse for security team's than automatically patched VMs controlled by ops teams without containers.
These are built-in grains, which are collected at minion startup. Here's the code responsible for generating them.
You cannot remove them, but you can overwrite them, for example to an empty value in /etc/salt/grains:
or with grains execution module: salt minion1 grains.delval osfinger.
Keep in mind that some of the core grains are ...
First of all there is one Maven central repository and that is Maven central. The website mvnrepository.com is just a search engine for Maven central.
Secondly there is a gazillion of paid services that already scan artifacts for you and allow you to know about known vulnerabilities beforehand. So that problem is already solved.
Finally several people who ...
We've configured the plugin properly (we're able to invoke acunetix from jenkins although we're having issues getting the report copied into the Jenkins workspace). The issue he might have run into is that you might have more than one jre installed and you have to register the certificate on the keystore JRE that Jenkins is using (you can check which one is ...