The aggregate of all vulnerabilities and flaws that can be exploited by cyber attackers to gain entry to your system is known as the attack surface. The attack surface determines the level of impact and intensity of a security breach. The bigger the attack surface the bigger the impact. The attack surface in Kubernetes and Docker are big because Kubernetes orchestrates containers that carry multiple applications. It's not only the Kubernetes environment that is wrecked when an attacker takes advantage of Kubernetes flaws, million-dollar applications are compromised.

In this article, you will learn about practices that maximize attack surface and see how Portainer solutions minimize the attack surface.

When we talk about the attack surface we are talking about vulnerabilities that have the ability to bypass the authentication layer when exploited by a cyber attacker. Here are three attack surface types:

• Weak passwords 
• Misconfigurations  
• Firmware vulnerabilities 
• Obsolete applications 
• Poor coding practices

A physical attack surface comprises vulnerable tangible components such as USB drives, desktops, hard drives, and mobile devices. These devices need strong authentication to limit the attack surface. Every structure that accommodates physical assets has to be surveilled to guarantee protection.

An attack surface has to be small or no attack surface at all. It's hard to keep to an environment that has no attack surface because of insecurities that are not created internally but by external entities such as third party software vendors.

In addition, many businesses have many devices and applications involved in day to day tasks and services. It's complex to manage an attack surface in a big-dynamic environment. A small attack surface makes it hard for attackers to exploit your systems. An attack surface has to be monitored and observed to track and control its expansion.

However, you can create an attack surface map by plotting all potential weak assets and components that give entry into the system. Vulnerabilities have to be assessed in terms of severity and eliminated according to severity level. Roles that have high level rights have to be audited and trusted; zero trust policies have to be implemented. Containers that need privileges have to be highly monitored and stripped of privileges when critical tasks that need the privileges have been fulfilled.

What Maximizes an Attack Surface?

Embedding secrets in repositories and not controlling access to your systems are bad practices that maximize an attack surface. Below is a list of bad practices that maximize an attack surface:

Not Controlling Access to Your Cluster and Containers

Who and what goes into your Kubernetes cluster and infrastructure has to be audited to guarantee that it does not have any malicious intent. Firewalls and NetworkPolicies do a great job of blocking rogue traffic. However, another filter layer is needed to ensure that only authorized people are allowed to access and write cluster changes. Everyone that accesses the cluster has to be assigned a role that has a specific list of all the actions they are allowed to implement when using the cluster. 

Intern developers have to be given the ability to list services and pods. But, giving them the ability to change and delete services sounds risky. Not everyone has to be given full access to cluster components. 

Kubernetes is a big platform used by many users in one company. Therefore, it is important to track and know who committed which change. Kubernetes has access control solutions such as Role-based access control (RBAC); this mechanism enables you to assign roles to different subjects. These roles specify which tasks a subject is allowed to execute on certain Kubernetes resources.

Exposing and Embedding Secrets

A security analysis carried out by GitGuardian has disclosed that 10 million secrets on GitHub have been exposed in 2022. Secrets get exposed when developers decide to hardcode secrets in repositories. When you write an API key in plain text files, that's how you hardcode or embed secrets. Secrets have to be encrypted and stored in a secure secret manager like Doppler. Hardcoded secrets can be extracted by cyber attackers and used to impersonate you.

API endpoints are accessed using secrets. So, an attacker has full access to your API after they have extracted the hard coded secrets. They can even use these secrets to stop your services and demand ransom. Exposed secrets make the widest attack surface and the biggest impact. Cyber attackers don't even have to inject malicious access to gain access to the cluster; they just use the stolen secrets to open the cluster swiftly in a fast manner.

One often overlooked secret is in fact the Kubernetes config file used by Devs/Ops to access the cluster remotely. This is the master key, and if not correctly stored, gives unbridled access to the Kubernetes Clusters within your environment.

Giving Containers Privileged Rights 

Access to the host machine is needed when sharing host directories and mounting an S3 bucket on a pod through FUSE. However, giving containers privileges is a bad idea. Privileged containers aren’t a vulnerability when being used by authorized cluster users. The problem with privileged containers is that they widen the attack surface. When an attacker penetrates a privileged container they won't only exploit the container they will also have access to the host machine which has more crucial resources. 

It's very easy to bring down a system when you have access to the host machine. The host machine is the holy grail. The security breach would make less impact when the attacker only exploits the container only but the impact is severe and costly when the host machine is exploited.

Using Old Components 

Most of the time developers update a system or component when they experience trouble with it only to realize that there is a new version. Any old version in your systems introduces vulnerabilities; because new versions have security patches that eliminate security bugs. When you use a component that is not up to date you are denying your systems a secure environment. Cyberattackers know which vulnerabilities are found in certain old components and how other cyber attackers bypassed security boundaries. 

Minimizing Kubernetes Attack Surface Using Portainer

This section shows you how Portainer minimizes the attack surface by logging events and implementing the RBAC mechanism.

Setting Roles Using Portainer to Block Unauthorized Actions

Controlling user access to block malicious users from accessing the system is important. More especially delegating different roles that specify the privileges a user has. Portainer has the RBAC mechanism which allows you to delegate privileges accordingly between different users.

Below are the roles and privileges that you can assign to different users and teams when using Portainer. 

Portainer has environment group management, this feature enables portainer users to manage access to different container environments that are connected to Portainer.

For example, I have created a group called HydroX which comprises IT personnel that handle the day to day tasks that keep the containers running.

If I want to give the team a role, I have to go to the Environment group management section to see all the available environments. In the image below we have an environment called Test environment which comprises local containers. Clicking the “Manage access ”button leads me to the section where I can give the HydroX team Roles and access to the Test environment.

Now, I can give HydroX the access operator role which gives all team members access to the Test environment resources.

After creating a role, the HydroX team has been given access to the Test environment after creating a role:

Anyone who is not in the HydroX team will not have access to the Test environment thus reducing the attack surface. By creating and assigning roles we make sure that only approved and qualified users are able to have full access to roles. 

How to Log Activities Using Portainer

Auditing and logging cluster activities to spot any malicious activities and vulnerability that weaken the system and expand the attack surface is crucial. Logs give you clues and evidence of what caused a vulnerability. Logs are the heart of any security breach investigation case. They give valuable data of what happened at what time. Regularly auditing your logs enables you to catch vulnerabilities before cyber attackers exploit them.

When you use Portainer to manage your Docker containers it automatically logs the activities every user executes such as deleting and restarting a container. For example, when the user restarts or stops any container, the activity logs will show you that a specific user restarted and stopped a container at a certain time. 

As you can see below, the user “boemo” restarted and stopped a container on 2023-04-26. 

Conclusion

Consistency is key when it comes to eliminating vulnerabilities. You have to regularly monitor and control the attack surface to have an environment that has a small to no attack surface. It is intimidating to try to regulate a big-dynamic environment like Kubernetes but everything is possible when done in steps and articulate manner. Create and use the attack surface map I explained previously to know which vulnerabilities need your immediate attention.

Portainer minimizes the attack surface in many ways. The two Portainer solutions we learned in this article are important but you can also use Portainer to apply Kubernetes security policies that are powered by Open Policy Agency. Using tools and platforms like Portainer is the quicker and pain-free path to minimizing attack surfaces.