Securing Cloud-Native Applications

This post was originally published here.

Application container technologies, also referred to as containers, combine application software packaging through different images with a form of operating system virtualization. The goal of such tech is that everything needed to easily package and run software reliably can be moved from one environment to another. As well as allowing devs to run an app and all of its dependencies in isolated processes, containers are also transferable, reusable, and automatable.

Implementing full-stack, full-lifecycle container security comes with many challenges to be overcome. On top of being faced with conflicting parameters of feature/product agility and time-to-market versus security control and visibility, dev and ops teams also have to deal with the ephemeral nature and portability of containers — which is when new security concerns can arise.

These security challenges are predominantly due to the multiple layers involved with a containerized environment in comparison to other infrastructure types. When it comes to virtual machines, for example, you have only a host OS, a guest OS, and a guest application environment to secure. Containers only contain the software, libraries, and other dependencies they require to run, which means they can go directly on the host operating system. This means unneeded software can be cut, leaving a small and efficient “container” holding the application — though it does mean many more instances running the same hardware as before in comparison to VMs.

Another challenge of securing application containers lies with existing security hardening mechanisms, which may only be designed to protect specific applications. Some are not designed to shield whole environments as certain measures do from inside the containers.

Hardening a containerized environment requires the use of new security strategies and tools designed especially for scenarios where perimeters are usually not clear — which this article attempts to address.

These are a number of best practices that will help us in hardening containerized environments. They are mainly founded on the Application Container Security Guide (SP 800-190) published by the NIST and some controls provided by the Kube community.

• Make sure container runtime is up-to-date in terms of security patches. Some vulnerabilities could lead to situations involving “container escape.” In this case, hackers could not only infiltrate other containers but the host operating system itself.
• Container images can often include outdated, insecure versions of software or libraries, buggy applications, or even hidden malware. Scanning for container vulnerabilities is also essential by using tools that are container-aware. Traditional tools don’t always have the analytical ability to detect vulnerabilities within containers, which can lead to a false sense of safety.
• Pull images only from trusted sources, such as private container registries. Harden access to the registry by requiring encrypted and authenticated connections. Harden base docker images and regularly update them. Implement a process where only pre-approved images are used.
• Poorly configured images are also often the root of many security vulnerabilities. Do not store secrets such as authentication keys within images.
• Containerized infrastructure makes scanning network traffic for security threats more challenging as they communicate over a virtual network. Detecting network traffic anomalies in those environments required specialized, application-aware network filtering tools.
• Do not run privileged containers. Assign only the capabilities that are needed. Giving the container full Linux kernel capabilities will allow it to change features on the host system directly, compromising the security of the host and the system.
• Do not run containers as root. Consider that some public base images have the user set to root by default; in those cases, create a new derived image that adds a new user and changes the default to that one.
• Sensitive information should never be stored in a YAML resource. All sensitive data in config maps and secrets should be encrypted.
• Enable RBAC with Least Privilege. Continuously review and improve RBAC rules. Incorrect or excessively permissive RBAC policies are a security threat in case of a compromised pod or identity (user or service account).
• Secure connections (TLS) should be enabled for every component that supports it to prevent traffic sniffing.

These are some of the tools we might consider for securing Kube environments. In general, they offer the same features, like vulnerability management, runtime defense, and integration with CI/CD, that will help meet the regulation requirements:

• Twistlock delivers comprehensive container security in the form of full lifecycle protection, from vulnerability management to container native firewall solutions.
• Aqua allows you to gain fast visibility into the state of container environments and utilize development-to-production lifecycle controls such as automatic image scanning for vulnerabilities.
• Sysdig provides an open-source, system-level exploration. Capture system states and activity from a running container instance, then save it, filter, and analyze for process improvements.
• AlertLogic offers security-as-a-service solutions that combine cloud-based software and threat analytics with expert services to secure the application and infrastructure stack of the cloud.