What Is Azure Container Security?

Here are some things to consider when securing your Azure containers:

As with any containers, securing images on Azure containers is one of the most important security steps you can take. Containers are built from images stored in repositories. Each image has multiple software layers that can, individually, contain vulnerabilities and possibly be compromised. By only allowing approved container images into your development environment, you greatly reduce the attack surface for cybercriminals. It is important to have explicit processes and tools in place that will monitor for and prevent the use of unapproved container images.

Another option for controlling the flow of containers into the environment is image signing or fingerprinting. This can provide a chain of custody that allows you to verify the integrity of the containers and the container images. Before pushing any images to the registry, it is crucial to perform a vulnerability scan on containers as a final evaluation after container development is complete.

Least privilege is a basic security best practice that should also be applied to Azure containers. When a vulnerability is exploited, whether through images or kernels, it gives the attacker access and potentially even privileges to several clusters and regions. Ensuring that containers operate with the lowest privileges and access required to get the job done reduces your exposure to risk.

By removing any unneeded privileges, should an employee transfer jobs or leave the company, you reduce the container attack surface. You can also reduce the potential attack surface by removing any unnecessary or unused privileges or processes from the container runtime.

Azure containers are built from images that are stored in either a public or private registry. While retrieving images from public registries may seem easier, it does not guarantee security. As mentioned above, container images have multiple layers of software, and each layer can have vulnerabilities.

Images on a public registry are more likely to have malicious software attached to them than those on a private registry. Images on private registries are more likely to be properly scanned and pose less risk. Private registries are managed and feature role-based access controls, providing more governance and security. Some examples of private container image registries include Azure Container Registry, Docker Trusted Registry, or the open-source Harbor project from the Cloud Native Computing Foundation.

All computers are built on top of pieces of hardware. The kernel, a piece of software imbedded within the operating system, serves as a bridge so the hardware and the rest of the system can interact. Unlike virtual machines, containers have open network traffic across their services as well as a shared kernel. The ability to share the host operating system kernel is one of the container’s biggest benefits; however, it is also a huge source of security concerns.

There isn’t much isolation between the kernel and containers during runtime, which means that a vulnerability located in the shared operating system kernel can then be used to exploit containers or gain access to them. Attackers can manipulate the running behaviors of the OS without injecting any malicious code simply by altering in-memory kernel data.