Micro-segmentation is a new security best practice, considered one of the pillars of the Zero Trust paradigm. It offers several advantages over previous approaches, such as network segmentation and application segmentation. These methods rely heavily on hardware controls that are difficult to manage. By contrast, micro-segmentation is software-based, decoupling security controls from the underlying infrastructure, making it possible to extend protection and visibility anywhere in the network.
Micro-segmentation provides an unprecedented level of granularity, which is important for securing new deployment options like cloud services and containers. These new models reduce the relevance of the traditional security perimeter, making it necessary to create “micro perimeters” around a large number of protected assets.
An important element of micro-segmentation is infrastructure visualization. Visualizations can help IT teams identify authorized and unauthorized activities in their environment, to better define network segmentation policies.
This increased visibility allows IT teams to define and fine-tune micro-segmentation policies that block unauthorized activity and alert when it is discovered. Micro-segmentation policies can take many forms—they can limit traffic by environment type, compliance scope, applications, and infrastructure layer controls.
Micro-segmentation enables organizations to truly implement the principle of least privilege, both in the on-premises data center and in cloud environments, providing a more effective defense than traditional network layer controls.
Micro-segmentation Policy as Code and DevOps
Micro-segmentation can help you reduce risk by isolating compromised applications and blocking lateral movement attacks. However, it can be difficult to achieve this level of granularity in a cloud-native environment. This issue occurs because many operations teams employ a centralized model that provides the team with full control over managing security policies.
The typical workflow employs an internal ticket-based system that allows operators to open ticket requests. A central policy team reviews these tickets and approves or rejects submitted requests. The policy team changes the policy only after approving a request. However, it may take the team days or weeks to change requests, creating bottlenecks.
How policies help improve micro-segmentation
DevOps teams aim to make the micro-segmentation process work similarly to application deployment. It requires giving up control over the review process and implementing micro-segmentation through a Policy as Code process. Here is how this typically works:
- Use identity-based micro-segmentation—enables DevOps teams to automate micro-segmentation and ensure application deployment security.
- Apply broad segmentation policies (policy guardrails)—DevOps teams can design policy guardrails according to the environment, cloud account, and business unit. It enables the team to manage fine-grained application-specific policies.
This type of distributed approach helps improve security without compromising the agility required to facilitate DevOps, helping organizations transition to a DevSecOps process.
How Gitops Will Change Network Security
GitOps is a software development paradigm that enables developers and IT operations teams to use Git for cluster management and application delivery. Applying Git to operations and development teams allows developers to use Git pull requests to manage infrastructure configuration and software deployment.
Git is an open-source distributed code management and version control system. It tracks source code changes throughout the software development process and automatically applies them to live environments such as Kubernetes clusters. A pull request allows users to push configuration changes and allows collaborators to review, discuss, or follow up on commits before the changes are merged into the main branch.
How does GitOps improve network security?
By adopting GitOps, security teams can create a Kubernetes cluster from code. Pushing Git-based policies to the new cluster becomes easy and error-free. It is much easier to integrate with existing systems by reusing a previous integration policy rather than creating it from scratch.
If anything goes wrong, teams can instantly roll back to the previous configuration. This also means that any accidental or malicious changes can be overridden by the current good configuration.
Improved access control
GitOps also improves access control for the software delivery process. It becomes easy and transparent to control who can contribute or modify security policies. Others can suggest policy changes via pull requests but never make direct changes. GitOps puts an end to the direct use of kubectl in a Kubernetes cluster, ensuring that developers work on configuration as code but never directly make changes to the cluster.
Example: locking down GitOps to enable security policy deployment
Here is how you would lock down a GitOps tool to enable the safe deployment of security policies. Consider how to do this in a popular GitOps tool, Argo CD:
- Only allow cluster roles for certain security actions, such as the definition of network policies.
- Create separate repositories for each team. This allows each team to define their own policies and sync via Argo CD.
- Enable read-only access to GitHub for Argo CD—it does not require write access as it does not make changes to policy, only to the live environment.
- Disable access to the image registry. This is not needed if Argo CD is only used to deploy security policies.
- Adjust sync/pull frequency. By default, ArgoCD is configured to sync every 5 minutes. You can make it less frequent to allow more time for collaboration on security policies.
In this article, I explained the basics of policy as code and showed how policy as code and GitOps can be used to automate micro-segmentation in production environments. I hope this will be of help as you transition your organization to a dynamic security configuration based on Zero Trust principles.