Container Security (Part 1 of 3)

 

To read part 2 of 3 please click here

To read part 3 of 3 please click here

Containers

A container is an isolated, lightweight silo for running an application on the host operating system. Although it shares the host operating system's kernel, it doesn't get unfettered access to the kernel. Instead, the container gets an isolated一 and in some cases virtualized― view of the system and to save the data the container can mount persistent storage such as an Azure Disk or a file share (including Azure Files).  

You will need Docker in order to work with the Windows Containers which consists of the Docker Engine (dockerd.exe), and the Docker Client (docker.exe).

How it works?

A container is built on the top of the kernel, but the kernel doesn't provide all of the APIs and services an app needs to run, in fact most of these are provided by system files (libraries) that run above the kernel in user mode. As the container is isolated from the host's user mode environment, it needs its own copy of these user mode system files, which are packaged into something known as a base image that serves as the foundational layer upon which your container is built, providing it with the operating system services not provided by the kernel.

Containers require much less resources (like they don't need a full OS), they are easy to deploy, and they start fast, which allows you to have higher density i.e. it allows you to run more services on the same hardware unit thereby reducing costs. However, as a side effect of running on the same kernel, you will get less isolation than VMs. 

Features of Containers

Features	Description
Isolation	Typically provides lightweight isolation from the host and other containers, but doesn’t provide as strong a security boundary as VM. Although you can increase the security by using Hyper-V isolation mode to isolate each container in a lightweight VM.
Operating System	Runs the user mode portion of an operating system and can be tailored to contain just the needed services for your app, using fewer system resources.
Deployment	Deploy individual container by using Docker via command line; deploy multiple containers by using an orchestrator such as Azure Kubernetes Service.
Persistent Storage	Use Azure Disks for local storage for a single node, or Azure Files (SMB shares) for storage shared by multiple nodes or servers.
Fault Tolerance	If a cluster node fails, any containers running on it are rapidly recreated by the orchestrator on another cluster node.
Networking	Uses an isolated view of a virtual network adapter, providing a little less virtualization˗ the host’s firewall is shared with containers˗ while using less resources.

 

You can think of a container as the "computer" with the image hard disk installed and it can be powered on or off just like a computer

ACI (Azure Container Instances) Security

ACI is a PaaS service for the scenario that can operate in isolated containers, including simple applications, task automation, and build jobs. But for the scenarios where you need full container orchestration, including service discovery across multiple containers, automatic scaling, and coordinated application upgrades, we recommend Azure Kubernetes Service.

Security recommendations for ACI

• Use a private registry- In addition to providing a managed private registry, Azure Container Registry supports service principle-based authentication through Azure Active Directory for basic authentication flows. This authentication includes role-based access for read-only (pull), write (push), and other permissions..

• Monitor and scan container images continuously- Take advantage of solutions to scan container images in a private registry and identify potential vulnerabilities. It's important to understand the depth of threat detection that different solutions provide.

• Protect credentials- Containers can spread across several clusters and Azure regions. Azure Key Vault is a cloud service that safeguards encryption keys and secrets (such as certificates, connection strings, and passwords) for containerized applications; and as this data is sensitive and business critical, you can secure access to your key vaults so that authorized applications as well as users can access them only. 

• Use vulnerability management as part of your container development lifecycle- By using effective vulnerability management throughout the container development lifecycle, you can improve the odds that you can easily identify and resolve security concerns before they can even become a more serious problem.

• Scan for vulnerabilities- You can incorporate vulnerability scanning throughout the container's lifecycle before pushing the images to a public or private registry. This will identify any flaw that was somehow missed during development and address any newly discovered vulnerabilities that might exist in the code used in the container images.

• Ensure that only approved images are used in your environment- Allow only approved container images. An effective way of reducing the attack surface and preventing developers from making critical security mistakes is to control the flow of container images into your development environment. Image signing and fingerprinting can provide a chain of custody that enables you to verify the integrity of the containers.

• Enforce least privileges in runtime- The concept of least privileges is the basic security best practice that also applies to the containers. Ensuring that containers operate with the lowest privileges and access required to get the job done reduces your exposure to risks.

• Reduce the container attack surface by removing unneeded privileges- You can also minimize the potential attack surface by removing any unused or unnecessary processes or privileges from the container runtime. If a malicious user or workload escapes in a privileged container, the container will then run as root on that system.

• Log all container administrative user access for auditing- The logs might be necessary for auditing purposes and will be useful as forensic evidence after any security incident. Azure solutions includes integration of Azure Kubernetes Service with Azure Security Center to monitor the security configuration of the cluster environment as well as generate security recommendations, Azure Container Monitoring solution, Resource Logs for ACI and Azure Container Registry.       

Features of ACI

Fast startup times - Containers offers a significant startup benefit over VMs. ACI can start containers in Azure in seconds, without the need to provision and manage VMs.

Container access

• ACI enables exposing your container groups directly to the internet with an IP address and a Fully Qualified Domain Name (FQDN).
• ACI also supports executing a command in a running container by providing an interactive shell to help with application development and troubleshooting. 

 Container deployment- Deploys containers from DockerHub or Azure Container Registry.

Hypervisor-level security- ACI guarantees that your application is as isolated in a container as it would be in a VM.

Custom Sizes- ACI provides optimum utilization by allowing the exact specifications of CPU cores and memory. You can pay based on what you need and get billed by the second, so that you can fine-tune your spending based on the actual need.

Persistent storage- To retrieve and persist state with ACI, we offer direct mounting of Azure Files shares backed by Azure Storage.

Flexible billing- Supports per-GB, per-CPU, and per-second billing.  

Linux and Windows containers- ACI can schedule both Windows and Linux containers with the same API. You can simply specify the OS type when you create your container groups.

Co-scheduled groups- ACI supports scheduling of multi-container groups that share a host machine, local network, storage, and lifecycle. This enables you to combine your main application container with the other supporting roles containers, such as logging sidecars.

Virtual network deployment- This feature of ACI enables deployment of container instances into an Azure virtual network, through which they can communicate securely with the other resources in the virtual network, including those that are on-premises (through VPN gateway or ExpressRoute).

To read part 2 of 3 please click here

To read part 3 of 3 please click here