Often the main security advantage of Docker is neglected: The application within the container runs with administrative privileges: root. This violates the least privilege principle and gives an attacker better chances further extending his activities if he manages to break out of the application into the container. From the host perspective the application should never run as root.
D2 - Patchmanagement Strategy
The host, the containment technology, the orchestration solution and the minimal operating system images in the container will have security bugs. Once publicly known it is vital for your security posture to address the bugs. For all domains mentioned you need to decide when you apply regular and emergency patches.
D3 - Network Separation and Firewalling
You properly need to design your network upfront. Management interfaces from the orchestration tool as well as network services are crucial and need to be protected on a network level. Also make sure that all other network based microservices are only exposed to the legitimate consumer of this microservice and not to the whole network.
D4 - Secure Defaults and Hardening
Depending on your choice of host and container operating system and orchestration tool you have to take care that no unneeded components are installed or started. Also all needed components need to be properly configured and locked down.
D5 - Maintain Security Contexts
Mixing production containers on one host with other stages of undefined or less secure containers may open a backdoor to your production. Also mixing e.g. frontend with backend services on one host may have a negative security impact.
D6 - Protect Secrets
Authentication and authorization of a microservice against a peer or a third party requires secrets to be provided. Also for an attacker those secrets potentially provide access to your data. Any passwords, tokens, private keys or certificates need to be protected as good as possible.
D7 - Resource Protection
As all containers share the same physical CPU, disks, memory and networks those physical resources need to be protected so that a single container running out of control -- deliberately or not -- doesn't affect any other container's resources.
D8 - Container Image Integrity and Origin
The minimal operating system in the container runs your code and needs to be fully trustworthy, starting from the origin up until the deployment. You need to make sure that all transfers as well as the images at rest are secure.
D9 - Follow Immutable Paradigm
Often container images don't need to write into their filesystem or a mounted filesystem, once set up and deployed. In those cases you have a extra security benefit if you start the containers in read-only mode.
D10 - Logging
For your container image, orchestration tool and host you need to log all security relevant events on a system and API level. All logs should be remote, they should contain a common timestamp and they should be tamper proof. Your application should also provide remote logging, not into the container.