<img src="https://ws.zoominfo.com/pixel/JHVDdRXH2uangmUMQBZd" width="1" height="1" style="display: none;">

Magalix Introduces the Cloud-Native Application Policy Pack

Exit icon Learn More

How to Prevent Non-Secure Container Images from Being Deployed with Policy-As-Code

Policy as Code Security as Code
How to Prevent Non-Secure Container Images from Being Deployed with Policy-As-Code
Policy as Code Security as Code

Regardless of what you are building, it's always best to integrate security from the early stages of the development process. This approach ensures more security when cloud-native applications go into production.

When it comes to containerized workloads, it's critical to properly secure container images during the application's lifecycle. Although it's crucial to maintain container security, many DevOps teams still fail to follow best practices and secure container images.

Securing a cloud-native application is challenging on its own with the various moving pieces involved to get your application from an integrated development environment into production.

But it's crucial to secure container images as they are essentially an application's unit of execution. It's also the envelope that packages the code throughout the lifecycle of the application.

It's much easier for security-conscious organizations to shift security left when container images are secured during early iterations. It also reduces the risk of security issues turning up during production. However, this doesn't mean that you can ignore security until the latter stages of development.

Containers are opaque in nature, and it's often difficult to see what's inside. As a result, cyberattacks attempt to exploit potential vulnerabilities that are unknown at any given time.

In this scenario, threat actors seek to access your environment in a manner you haven't anticipated. As such, container security demands policy-as-code, highly adaptable processes, and constant vigilance.

As you build containers, it's crucial to scan and secure the following:

  • Build Image
  • Code analysis (static and dynamic)
  • Imported third-party libraries
  • Kubernetes Manifest

When you secure the above, you build the foundation of a strong security posture. It's critical because no application is truly secure without secure container images.


wppr_new

Learn why Governance is crucial to scaling business operations with Magalix latest Whitepaper.

“Shift-Left Cloud-Native Security with a DevOps Mindset”.

Download Now

 


Scan the Image at Every Stage of the Life Cycle

Image scanning must be at the heart of your development culture. It's not something you do once and forget about. Instead, incorporate image scanning protocols whenever and wherever possible during the development lifecycle.

It's vital to include image scanning within the CI/CD pipeline when you start building the image. When the image is running (continuously) and when the image is in repo.

New Common Vulnerabilities and Exposures (CVE) are identified and published daily. This means that the container image that was compliant yesterday might have a weakness to exploit today. Continuous image scanning helps mitigate this risk.

You can control image executions using policy as code. This approach helps block images from being deployed when a CVE scan has flagged them. Depending on the severity of the vulnerability and the sensitivity of your environment, you can also use an admission controller to accomplish the same result.

It's also best to engage in inline scanning within your registries and pipelines. This approach can help provide better control and more security. To do this, you have to scan your local environment without sharing registry credentials or image contents externally.

Never Run Container Images as Root

Although running an image as root is often the easiest option for DevOps teams to get the application working, it comes with significant risk. It's almost like locking the front door while all your windows are left wide open.

How to Prevent Non-Secure Container Images from Being Deployed with Policy-As-Code

Shifting left with Magalix and GitHub Actions using Github Code Scanning

When you run an image on root, you’ll execute the code on root. So, a threat actor just has to obtain root access to execute malicious code inside your container.

If you're thinking that kernel isolation prevents hackers from exploiting root privileges, you would be right. However, kernel isolation doesn't prevent threat actors from using such services through the network.

Once they get root access, attackers are free to perform container breakouts. For example, they just have to exploit "runc," a known kernel vulnerability as containers run with root permissions by default. It's up to the development team to decide whether to change them manually or to automate systems and block root access.

How to Prevent Non-Secure Container Images from Being Deployed with Policy-As-Code

Risky configurations detected at runtime should only be allowed to run for a predetermined amount of time when it’s unavoidable. However, it’s to enforce strict monitoring protocols to address each deviation away from established security policies.

Prevent Non-Secure Images from Deployment

It's important to keep checking for environment variables that apply to each container. Relays on the policy demand a set of keys to exist at the container level and initiate operations.

When the container starts, it'll block the code from further executing if it doesn't locate the keys. Even if it does find the keys, your consideration code is leveraged to decide whether to deploy or stop the service. In this manner, you can prevent non-secure container images from deployment.

Size Does Matter

Robust container security depends on multiple variables. When it comes to container images, the smaller the image, the easier it's to secure it. When the image surface layer is small, there are far fewer opportunities to exploit it.

Although the ideal scenario is to have images running single processes, it's rarely possible. However, this should always be a goal to strive towards and achieve whenever possible. It's also best not to use too many imported third-party libraries to mitigate risk and ensure robust security.

Always Use Signed Images

Whenever you must use third-party libraries, it’s important to always use signed images. Signed container images allow DevOps teams to add a digital fingerprint to an image. This approach helps verify trust by cryptographically testing the container images. After all, the final user of the container images must check the chain of custody to verify and trust the team that added multiple layers to a container image.

In this scenario, it’s essential to maintain a stage and production registry and only push secure images into production. This approach also allows you to use policy-as-code to block images from non-approved registries.

At Magalix, we help companies shift security left by defining, managing, and deploying custom governance policies by leveraging PoC. We help implement the right workflows, playbooks, and more using a robust OPA policy execution engine

To learn more, reach out to one of our in-house Kubernetes experts or sign-up for a 30-day free trial.

Explore Magalix Policy Library with a 30-day free trial

Comments and Responses

Related Articles

What Is Zero Trust Architecture and How Does It Work?

In an enterprise environment with containers and micro-segmentation, zero-trust architecture helps enhance security protocols. Learn more.

Read more
Cloud Asset Management and Protection: Storage Assets

Learn useful strategies to manage cloud storage assets and get the most value for your investment.

Read more
4 Reasons Why Companies should Codify their Security

The move to the cloud has significantly increased the operational and security complexity. Codifying security policies can help mitigate the potential risk

Read more