The Need for Container Security in the Build Environment

A notable problem with IT trends is that they come without security in mind. This is the case initially, at least. For example, DevOps has been slowly evolving into DevSecOps. Containers need to be built securely throughout the build pipeline.

Adrian Lane, of Securosis, published a series of container security tips and what to look for. Lane details important best practices to follow when it comes to integrating containers into your development process. The first article focused on build pipeline security. This is an often-overlooked aspect of container security. We read through the article and pulled the essential tips you should follow for securing your container build environment.

Collaboration

Build environment might not be the first thing on your list but it probably should be. It has the least built-in security and it’s the easiest place for malicious or inefficient code to be inserted.

Lane points out that “most people fail to consider the build environment when thinking about container security.” This largely comes back to traditional IT silos. The build environment is usually limited to the development team. Development teams don’t want to share their work as they’re actively working on it, but with Continuous Integration or full Continuous Deployment, the code is being put into production much faster. The minimal security approach may have been okay with slower releases, but development teams need to be collaborative with security teams.

Keeping developers happy

One issue that may arise is that containers are intended to make development faster. It’s easy to think, “I want containers to speed up development, it doesn’t make sense to slow down my process with security.” This mindset ignores the fact that faster releases can easily lead to less secure releases. Securing the build environment may be slightly slower, but it’s essential to creating a quality product. Quality should always be the priority.

Security shouldn’t be added without developers in mind, though. Containers allow developers to focus on creating applications without having to worry about the supporting systems. They are also lightweight, meaning they can scale and be modified easily. These core benefits to containers should not be overlooked when looking at security controls. Hindering these will have a negative impact on developers.

Security options

Lane lists three options in detail. The first of which is source code control. This option comes from sites like Stash, Git, and Github. It is common for security, operations, and quality assurance to contribute code, tests, and configuration data. Since so many users can utilize these options, it’s obviously important to use token-based or certification-based authentication.

The next suggestion that he provides is build tools and controllers. Lane says that many of the development teams they speak with use build controllers like Bamboo and Jenkins. These tools are useful, but they complicate security.  For this, Lane suggests full network segregation of the build controller systems. He also says to lock network connections to limit what can communicate with them. Limiting access to build controllers is essential when using these build controllers. This advice also applies to container management tools, such as Docker or applications using Kubernetes. The client for these tools should be segregated between development, test, and production. This is done to “limit who and which services can launch containers in production.”

His final bit of advice regards container registry security. He points out that developers and IT teams tend to allow anyone to add containers to the registry. This behavior can lead to insecure containers entering production. Sometimes teams like to add open source pre-built containers to production, but this is obviously not a safe practice if put in the wrong hands. The registry should only accept containers from trusted sources. One of the most important rules to implement is that your registries and clients require IAM credentials. Limiting who has access is crucial to maintaining a healthy build environment.

We encourage you to read the full article.