Set up Panoptica in your own Kubernetes environment—in minutes.
If you work in software development or IT, you’ve likely heard about – and perhaps are even practicing – GitOps, the latest, greatest way to accelerate software delivery. GitOps uses Git, the version control system, to centralize and standardize software development and deployment operations.
In many ways, GitOps is awesome. It lets you manage complex operations declaratively, through a centralized hub. You can version-control changes. You can mitigate configuration drift. And so on.
Yet, alongside these benefits, there’s one huge potential GitOps pitfall to consider: Security risks. When you manage everything in your CI/CD pipeline via Git, your pipeline is only as secure as Git and its integrations with your environment.
That’s why it’s critical to secure your Git connections when you practice GitOps. To drive the point home, this article walks through the security risks associated with GitOps, then explains how to address themi. To ground the discussion, we’ll use a CI/CD pipeline that deploys to a Kubernetes cluster for our examples, but the general points in this blog apply to any GitOps-based CI/CD pipeline.
The security risks that arise in GitOps are relatively straightforward: When you do GitOps, you manage all CI/CD operations via Git. In most cases, this means using APIs to integrate your Git repos with your CI/CD pipeline tools and your deployment environment.
As a result, any sensitive data that is exposed via API requests can become a security risk if it is not managed properly. For example, if you allow a CI/CD tool, or an application running in your deployment environment, to access secrets stored in a Git repo via an API call, you could end up with a security breach if a malicious user gains access to that API.
Along similar lines, insecure configurations – such as an insecure Kubernetes security context – that exist in your Git repos can be automatically pushed into your production environment. This could happen in any CI/CD pipeline, of course. But because GitOps automates deployments and minimizes manual human intervention, the risk that insecure configurations will end up production without being detected becomes greater.
Those are the problems. Now, let’s look at how to address them using a tool like Panoptica, which tracks security risks across your GitOps-based CI/CD pipeline, and helps you intercept them before they become breaches.
To understand how Panoptica does this, you must first understand that in GitOps, you have two basic types of connections:
To secure both of these connection types, you must continuously monitor them for security risks. Doing so ensures that you can detect misconfigurations, as well as intercept secrets or other sensitive data that is shared across a connection without being properly secured.
When you have this continuous visibility and scanning, you can detect three main types of security risks within your CI/CD pipeline.
The first are misconfigured security contexts. Security contexts define actions that applications are allowed to perform when they are deployed as containers within Kubernetes pods. For example, if a security context allows privilege escalation, it could become a vector for an attacker to compromise a host node.
Panoptica scans security contexts within connections between your Git environment and your Kubernetes clusters, then alerts you to potential risks. This is particularly beneficial within a GitOps-based pipeline, where you move so much data automatically that it can be easy to overlook insecure security contexts or other risks.
Panoptica also automatically detects secrets (such as passwords or access keys) that are available in plain text as part of a GitOps-based CI/CD pipeline. The tool detects all the ways in which secrets can be described in Kubernetes, and alerts users to instances where secrets
Permissions that are unnecessarily broad are another GitOps security risk. Panoptica alerts you to these by scanning the permissions granted to Kubernetes resources and flagging instances where permissions appear to violate the principle of least privilege – which means that only the minimum necessary permissions should be granted to a resource.
Panoptica can perform additional types of security checks within your CI/CD pipeline. These include static checks whenever a deployment takes place. These static checks look for abnormal conditions that could be signs of a risky deployment.
What if you want not just to detect risks, but also mitigate them automatically?
Panoptica can help you do this, too, via CI/CD policies. You can configure policies that automatically block deployments if Panoptica determines that the risks are too high.
For example, you could create a rule to block deployments that include plain-text secrets data:
You can then verify that the policy was installed correctly:
Within fast-moving CI/CD pipelines where your engineers’ ability to catch risks manually is low, making the ability to block risks automatically hugely important. Not only does it save time, but it greatly reduces the risk that a security vulnerability or data exposure will reach your production environment, where it is easier to exploit.
GitOps is great – but only when you manage the security risks that are inherent to a fast-moving CI/CD pipeline subject to minimal manual oversight.
Panoptica helps you keep deployments secure by identifying risks like insecure security contexts, insecure secrets management and excessive permissions. In turn, Panoptica ensures that you can keep delivering software continuously, and take full advantage of GitOps, without the security risks.