As the DevOps process continues towards a stronger and stable footing the fight to secure ‘stronger-links’ between IT and DevOps continues. Strengthening containers is one of those issues. It’s not possible to talk about containers without mentioning Docker as no well-trained DevOp worth their weight could work without it. It wasn’t until Docker came along that containers could be used in any meaningful way. Both are hot topics right now and JP Morgan Chase and Bank Mellon are both pursuing container based strategies.

It is always the case with a new software launch or product development that it is only through trial and error that problems are solved. Containers are lightweight machines that carry a small footprint in terms of system requirements. They take seconds to start. The big thing about containers is that they reduce imprint and thus costs. Containers also come with risks and were not created with security in mind. Containers are made from images and DevOps can either download them publicly or from Docker Hub utilizing an automated process. These are five main security habits of well-trained DevOps for containers that must be adhered to:

1) Scan frequently – How to reduce the attacks is the major headache that consumes DevOps. How to stop code with vulnerabilities entering into the system is the key issue. DevOps will always have some issues owing to the way Dev works but building an understanding through knowledge of the area where vulnerabilities exist can reduce further attacks. Containerization has a unique set of conditions and the open access policy is the cause. Containers unique set-up involves more than just locking down the host. There is a need to maintain standard configurations and container profiles and scanning frequently can reduce these vulnerabilities.

2) Revoke Privileges – Root access is one of the most contentious issues in the battle for greater security. Historically all containers give access to the owner and its users but Docker has been re-tweaked so that root privilege access is given to the owner alone. Due to their vulnerability and access to the entire system, containers can be implicit in malicious attacks which can creep into other containers because they give deep-level access. The decision to revoke privileges has been a timely move by Docker and the DevOp industry.

3) Hide Secrets – Secrets are an important issue with containers and a major consideration in production. The main point is what to do during run-time. Secrets are usually kept in encrypted packages or part of the source code. It can be placed as part of the image. One of the main problems is that when it is published to the registry anyone can pull that image and the secrets would be at their disposal. Putting it under ENV variables is a primary task and using docker run –it –e “DBUSER=dbuser” –e “DBPASSWD=dbpasswd” myimage /bin/bash is one of your first priorities. Put your secrets in some directory structure on Docker hosts. Then mount the right directory inside the container.

4) Remove Unused Components/Images – Trusting the image source is a major concern for developers. There is a constant flow of images from a centralized hub development and a lot of the images contain vulnerabilities. But how the DevOps team deals with the vulnerability is still a contentious issue. The more layers in the image-build the bigger chance of a component that hasn’t been scanned getting into production. How to prevent code with vulnerabilities from entering the environment is one of the key questions along with the ‘layer’ problem.

5) Avoid SSH/Use automation – If security could work their magic and weave their procedures into DevOps processes it would be game over. Unfortunately IT are often unaware of the processes that work with containers in production. DevOps just wants to get on with its main task; automation. Most container based application processes are heavily automated. Automation is required because IT can no longer manage the complex services architecture that enterprises use today.

devop