Threat models applicable for Containers
Today we are discussing possible threat models applicable for Containers, To conceptualize the threat model for containers we need to consider the different entities involved.
1. External attackers who aim to breach the deployment from outside.
2. Internal attackers who have gained access to a part of the deployment.
3. Malicious internal factors, including developers and administrators with privileges to access the deployment.
4. Unintentional internal actors who might unknowingly trigger issues.
5. Application processes that programmatically interact with the system even though they don’t have any intent to compromise it.
Each entity has permissions that need evaluation:–
1. Credentials based access determines whether they can access user accounts on host machines where the deployment operates.
2. System permissions in a Kubernetes context involve role based access control settings for each user including users.
3. Network access considers which parts of the system are included within a Virtual Cloud (VPC).
Attacking a deployment can occur through routes with attack vectors present, at every stage of a containers life cycle. These vectors can be summarized as follows:
1. Vulnerable application code- This section starts with the code written by the developer for their application, which could potentially have vulnerabilities. Later sections will discuss how to detect and address these known vulnerabilities.
2. In order to build a container image it is important to avoid configurations that can introduce weaknesses. For example it is crucial to prevent containers from running with root user privileges. More information on this topic will be provided in sections.
3. Attackers may take advantage of vulnerabilities during the container image building process. Potentially insert code into the production environment.
4. Security concerns arise when storing container images in a registry and retrieving them for deployment. It is essential to ensure the integrity of these images and protect against tampering.
5. The host machines that run containers should not have outdated or vulnerable software. By implementing security practices and minimizing software on each host we can enhance security measures.
6. Containerized applications often require credentials and tokens to interact with system components. Ref – we will discuss this in detail how to manage it..
7. Networking insecurity is a concern, in container environments. Ensuring communication mechanisms, both internally and externally is discussed in different articles in detail.
One must be aware of the possibility of bugs in container runtimes like containerd and CRI O even though they are generally considered secure. To enhance container isolation methods are explored in an upcoming blog.
It’s important to note that certain attack vectors, such as repository security and host protection go beyond the scope of this discussion. Like in deployments securing source code repositories and networked hosts is essential.
In environments orchestrators like Kubernetes play a role. However if not properly configured or if there is control, over orchestrators attackers may find additional ways to compromise the deployment.
Do you like to read more educational content? Read our blogs at Cloudastra Technologies or contact us for business enquiry at Cloudastra Contact Us.