Hardening Docker Images following CIS Benchmark

[MikeHorn-git]

Is your feature request related to a problem? Please describe.

I using docker-bench-security to secure my Tpot OS.
The tool follow CIS Benchmark, and some Section failed. Here are some snippets :

4.1 - Ensure that a user for the container has been created (Automated)
[WARN]      * Running as root

4.6 - Ensure that HEALTHCHECK instructions have been added to container images (Automated)
[WARN]      * No Healthcheck found

5.3 - Ensure that, if applicable, SELinux security options are set (Automated)
[WARN]      * No SecurityOptions Found

5.4 - Ensure that Linux kernel capabilities are restricted within containers (Automated)
[WARN]      * Capabilities added:

etc.

Describe the solution you'd like

Hardening Docker Images with certain CIS Docker Benchmark guideline if possible.

Describe alternatives you've considered

Maybe :

• List all failed section related to Docker Images conception.
• List section that can be applied to Honeypot Dockerfile.

Additional context

I guess that some of these cannot be corrected due to technical or conception constraint.
But maybe some of them can be considered.

[t3chn0m4g3]

Thanks, we are building T-Pot with the best effort / practice for security and technical functionality in mind, however, while docker bench is being used ... :

• Some of the images are requiring root, while most of them are running with a dedicated user.
• Adding healthchecks to the honeypots (to really check if the service is running) is desirable, but sadly counterproductive as it mostly results in false positive honeypot logs.
• Enabling SELinux is not in the cards as it tends to be too invasive on the host. It is possible however, if so required, to adjust the host accordingly.
• We have looked into dropping all caps and subsequently only adding the ones needed for each honeypot and it resulted to be impractical. During the tests honeypots and tool features changed, some of which resulting in different cap requirements. Thus not only the docker image needed to be updated / pushed, but also the docker compose file, which resulted in interrupted services as the user was required to update the docker compose file as well.

With that in mind, docker bench will always have some failed sections, and thus needs to be looked at with a practical approach to security while maintaining technical functionality and user convenience.

[MikeHorn-git]

Ok, thanks for your reply.