Updates from February, 2017 Toggle Comment Threads | Keyboard Shortcuts

  • gio 12:53 am on February 15, 2017 Permalink
    Tags: docker, security   

    Docker: some tips about security 

    Risk Areas

    • Host security
    • Client <> Daemon communication
    • Daemon security
    • Communication with public/private registry
    • Images
    • Containers
    • Registry’s security

    Life cycle of an image

    _dockerfile_ ==BUILD==>> _image_ ==SPIN==> Container
                 maintaining images securely

    Dockerfile Security

    • Do not write secrets in your dockerfile. Use some secret management solution like Hashicorp Vault.
    • Create a USER to executes the processes in the image, otherwise the container will run as root.
    • Avoid to use the latest tag. Better use version pinnin to avoid cache issues.
    • Remove unnecessary setuid, setgid permissions.
    • Do not write any kind of update instructions. All the layers are cached and this not assure the execution of the update.
    • Download packages securely and do not download unnecessary packages. Reduce your attack surface.
    • Use COPY instead of ADD to reduce the attack surface. add-or-copy
    • Use HEALTHCHECK command. Reducing Deploy Risk With Dockerโ€™s New Health Check Instruction Test-drive Docker Healthcheck in 10 minutes
    • Use gosu instead of sudo wherever is possible gosu.
    • Try to restrict a image/container to one single service.

    Maintaining and Consuming Images

    • Docker Content Trust

      • provides authenticity, integrity and freshness guarantees.
      • takes some time to understand and prepare
    • Vulenrability free images:

      • tool selection: binary level analysis + hash based
      • Twistlock, Scalock, Nautilus to use only signed images, scan images, automatic container profiling.
      • aquasec
    • Except compatibility issues, all images and packages must be up-to-date.

    Advanced Security (production/enterprise zone)

    • Do not use Docker hub Images. High possibility of malicious images.
    • Maintain your own in-house registries.
    • Perform image optimization techniques.
    • Use commercial tools:
      • Image Lockdown
      • RBAC
    • Use file monitoring solutions to monitor any malicious changes in image layers.
    • Have separate patch, vulnerability management procedures for containers.
    • Customize CIS Docker benchmarks.

    Container Runtime

    Some Docker defaults to consider

    • Containers can consume entire memory causeing DOS.
    • Containers can communicate with each other leading to sniffing etc.
    • Containers are on the same bridge leading ARP spoofing, MITM, etc.
    • Containers have no fork limit causing fork bomb.
    • Containers run as root.
    • Docker daemon access users have effective root privileges


    • Namespaces: beware of non-namespaced kernel keyrings: SYS_TIME, etc. Do not share namespaces unless really needed.
    • Seccomp
    • LSM’s SELinux and Apparmor
    • Capabilities: do not use privileged containers and try to set flag for not acquiring any additional privileges.


    • Manideep 5:24 pm on July 14, 2017 Permalink

      Thanks for the credits ๐Ÿ™‚

  • gio 12:08 am on February 25, 2016 Permalink  

    GitLab 8.5 and the new CI 

    With GitLab 8.5 we are introducing some great new features, between them also a brand new CI service.

    To have a working CI follow this quick start.

    If you don’t know how to setup your runner or you need one: ask me. We have a VM with docker available to register new runners.

  • gio 11:35 pm on February 24, 2016 Permalink  

    Docker cookbook 

    :: list images

    sudo docker images

    :: list the containers

    sudo docker ps
    sudo docker ps -a

    :: start/stop a container

    sudo docker start CONTAINER

    (More …)

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc