Find out the key steps for ensuring comprehensive container security.
Many organizations are interested in containers because they enable users to easily package an application, and all its dependencies, into a single image that can be moved from development, to testing and production without changing. The technology makes it easy to ensure consistency across environments and multiple deployment targets like physical servers, virtual machines (VMs), and private and/or public clouds. As a result, IT teams can more easily develop and manage the applications that deliver business value.
However, whether organizations are considering transitioning their current legacy infrastructure to containerized applications, or building containerized applications for the first time, one of the biggest questions that comes up is whether the technology is secure. While container technology may be new to many organizations, the philosophy behind securing them should be very familiar: You need to think about security throughout the layers of the solution stack before you deploy and run your container. You also need to think about security throughout the application and container life cycle.
Containers do inherit many of the security features of Linux, but there are some specific issues that need to be considered when it comes to the model --10, in fact.
In the end, organizations need a secure, enterprise-grade container-based application platform that does not compromise the functions needed by each team, while also improving operational efficiency and infrastructure utilization.
Continue on to learn about the 10 key elements of container security and how to deliver continuous and comprehensive security for containers.
As senior principal technical product marketing manager of security at Red Hat, Kirsten Newcomer works closely with Red Hat’s many security professionals across the Red Hat portfolio of enterprise-ready open source offerings. Kirsten is a diversified software management professional with 15+ years of experience in application development and infrastructure solutions. Prior to joining Red Hat, Kirsten provided strategic direction for Black Duck’s open source governance solutions, designed to help organizations maximize the benefits of open source. Her career has spanned successful roles at IBM Software Group, Rational Software and BMC Software. Kirsten is an active member of the Linux Foundation's Software Package Data Exchange (SPDX) working group.
The container host and multitenancy
With containers, organizations can deploy multiple applications on a single host, spinning up and shutting down individual containers as needed. However, to take full advantage of containers, operations teams need the right environment for running them and the approach to securing them should be the same as securing any running process on Linux.
Operations needs an operating system that can secure containers at the boundaries: securing the host kernel from container escapes and securing containers from each other. Additionally, it is important to keep in mind that:
- It's ideal to create containers with the least privilege possible
- Containers should run as user, not root
- You should make use of the multiple levels of security available in Linux: Linux namespaces, Security-Enhanced Linux (SELinux), Cgroups, capabilities, and secure computing mode (seccomp)
- Containers can be run inside guest VMs, but container multitenancy on a single host provides a more lightweight, flexible, and easier-to-scale deployment solution
Content: what's inside your container?
When it comes to security, it’s what’s inside your container that counts. Many applications and infrastructures have been composed from readily available components, and containerized versions of open source packages are now available so that organizations don’t have to build their own. However, as with any code downloaded from an external source, organizations need to know where the source of the packages, who built them, and whether there is any malicious code inside. Below are four questions IT pros need to ask themselves when building containers:
· Will what’s inside the containers compromise my infrastructure?
· Are there known vulnerabilities in the application layer?
· Are the runtime and OS layers up to date?
· How frequently will the container be updated and how will I know when it’s updated?
Whenever possible, use content from trusted sources that help you assess and manage the security of the content. For example, use sources that provide security monitoring to update you about any newly discovered vulnerabilities and notify you when updated images with fixes are available.
As IT teams build containers that layer content on top of the public container images that they download, they will need to manage access to, and promotion of, the downloaded container images and the internally built images in the same way other types of binaries are managed. There are a range of private registries that support storage of container images; select a private registry that helps teams automate policies for the use of container images stored in the registry. Also, ask yourself these questions:
· What security meta-data is available for your images?
· Are the images in the registry updated regularly?
· Are there access controls on the registry?
· How strong are they?
Managing container builds
The software build process in a containerized environment is the stage in the lifecycle where application code is integrated with required runtime libraries. Effectively managing and integrating security scanners for real-time checking against known vulnerabilities into this build/continuous integration process is fundamental to securing the software stack. Sticking to a “build once, deploy everywhere” philosophy helps to ensure that the product of the build process is exactly what is deployed in production; and rather than patching a running container, developers should rebuild and redeploy them instead.
It’s a good idea to design a container image management and build process that takes advantage of container layers to implement separation of control, so that:
· The operations team manages base images.
· Architects manage middleware, runtimes, databases, and other such solutions.
· Developers focus on application layers and just write code.
Managing container deployment
In the off chance anything falls through during the build process, or for situations where a vulnerability is discovered after an image has been deployed, it's important to have another layer of security: tools for automated, policy-based deployment. Organizations also should monitor the image registry to prevent deployment of vulnerable images and to automatically trigger the CI/CD process to replace affected images.
Developers should use automated policies to manage container deployment from a security perspective, including gating what can be deployed: For example, if a container requires root access or requests unnecessary capabilities.
Container orchestration: Securing the container platform
Modern microservices-based applications are very rarely delivered in a single container. More likely, organizations are deploying multiple containers -- sometimes on the same host and sometimes distributed across multiple hosts or nodes. As a result, organizations must use a container orchestration platform with integrated security features, including:
· Role-based access controls with LDAP and OAuth integration
· Integrated registry
· Integrated CI/CD with configurable policies
· The ability to plug-in third party registries and CI/CD systems
· Integrated host OS with embedded security features
· Network management
· Storage plug-ins
· API management
As most IT teams will be deploying multiple containers distributed across multiple nodes, they need to keep network security in mind and isolate applications from one another within a cluster. For secure container multitenancy, look for a container platform that takes a single cluster and segments the traffic to isolate different users, teams, applications, and environments within that cluster.
With network namespaces, each collection of containers - known as a Pod - has its own IP and port range, isolating pod networks from each other on the node. This proliferation of IP addresses and ports makes networking more complex and to add to that, containers are meant to come and go.
As a result, it is wise to invest in tools that handle this complexity for you, including a container platform that uses software defined networking (SDN) to provide a unified cluster network for communication between containers across the cluster. The platform also should provide the ability to control egress traffic using either a router or firewall method to enable IP whitelisting to control, for example, database access.
(Image: Maksim Kabakou/Shutterstock)
Containers are beneficial for both stateless and stateful applications, and protecting attached storage is a crucial aspect of securing stateful services. To secure storage, IT teams should use:
· SELinux access controls
· Secure mounts
· Supplemental group IDs for shared storage
In addition to the security features available via storage solutions, data in transit should be encrypted via HTTPS for all container platform components communicating between each other.
(Image: Quang Ho/Shutterstock)
APIs are key to applications composed of microservices and managing application and API authentication and authorization is a critical part of securing those applications. Each application has multiple independent API services, leading to proliferation of service endpoints, which require additional tools for governance. An API application management tool can help.
When looking at securing APIs, organizations should make sure they understand and deploy solutions that cover:
· Authentication and authorization
· LDAP integration
· Endpoint access controls
· Rate limiting
Cluster federation: access management
Federation is useful for deploying and accessing application services that cover multiple clusters and are running in the public cloud or enterprise data centers. When managing federated clusters, orchestration tools should provide the security needed across the different deployment platform instances. As with many other layers, authentication and authorization are key, in addition to the ability to securely pass data to applications, wherever they run, and manage application multitenancy across clusters.
Kubernetes is extending Cluster Federation (beta in version 1.3) to include support for Federated Secrets, Federated Namespaces and Ingress objects.