Portshift Policy Advisor: Bringing Zero-Trust Security to Kubernetes Microservices

This article is based on reporting originally published on containerjournal.com on September 27, 2019.

Overview

Portshift announced an addition to its Cloud Workload Protection Platform: a Policy Advisor control interface designed to help organizations identify, enforce, and manage secure communication paths between container-based microservices. The feature extends the platform’s existing zero-trust model — which works by assigning cryptographic identities to applications — into the microservices layer running on Kubernetes clusters.

What Is the Portshift Policy Advisor?

The Policy Advisor is a control interface that enforces a default-deny posture for microservice-to-microservice communication. According to Zohar Kaufman, Portshift’s VP of Research and Development, any communication between microservices that is not explicitly permitted by the Policy Advisor is automatically blocked. This aligns with a strict zero-trust networking model: nothing is trusted by default, even traffic that originates inside the cluster.

The Policy Advisor is activated by installing a lightweight agent on a Kubernetes cluster. Once in place, it surfaces suggested policies based on observed traffic patterns, allowing administrators to act on recommendations rather than building rules entirely from scratch.

How It Integrates with CI/CD and Kubernetes

The broader Portshift platform attaches identities to applications at build time, as code moves through a CI/CD pipeline. The Policy Advisor builds on this foundation by extending identity-based access control to individual microservices at runtime.

A notable usability feature is the use of plain-English policy commands. When a DevOps team defines a rule using this interface, the platform automatically translates it into the appropriate YAML configuration that governs the Kubernetes environment. This deterministic mapping has two practical benefits:

• Security professionals can participate in policy creation without needing deep Kubernetes or coding expertise.
• The intent of a policy is preserved clearly from human-readable definition to machine-enforceable configuration, reducing the chance of misconfiguration.

Policy Creation Workflow

The Policy Advisor gives administrators two paths for creating rules:

1. Suggested rules: The platform surfaces recommendations based on observed traffic. Each suggestion shows the source service, destination service, traffic details, and pending actions.
2. Custom rules: Administrators can define rules manually to meet specific runtime requirements not covered by automated suggestions.

Before a rule is applied, the Policy Advisor shows how many existing connections would be affected, helping teams avoid unintended disruptions. Once a rule is saved, it appears in the connection policy window and can be modified or deleted at any time.

Why Microservice Security Is a Hard Problem

Containerized, microservices-based applications offer real security advantages over monolithic architectures. When a vulnerability is found in a single container, developers can replace just that component rather than patching an entire application. However, this architectural model introduces its own risks:

• A single production application may be composed of hundreds of microservices, dramatically expanding the attack surface.
• Any one of those microservices could potentially communicate with a malicious external endpoint that appears legitimate — an avenue that cybercriminals can exploit.
• Lack of visibility into inter-service communication makes it difficult for security teams to evaluate and approve applications for production deployment.

This visibility gap has historically created friction between development teams and security teams. Developers want to ship; security teams are reluctant to approve deployments they cannot fully inspect. Tools like Policy Advisor aim to close this gap by giving both teams a shared, observable policy layer.

The Broader Zero-Trust Microservices Landscape

Portshift was not the only vendor pursuing zero-trust security for microservices at the time of this announcement. The problem space — enforcing least-privilege communication between services in dynamic container environments — attracted multiple startups and established security vendors. Organizations scaling their use of Kubernetes and cloud-native architectures should evaluate how their security toolchain handles:

• Service identity and authentication
• Automated policy generation from observed traffic
• Integration with CI/CD pipelines (shift-left security)
• Runtime enforcement and alerting
• Policy-as-code with auditability

Practical Takeaway for DevSecOps Teams

For teams operating microservices at scale, the key lesson from the Portshift approach is that zero-trust is not just a network perimeter concern — it applies between services inside your own cluster. Adopting a default-deny posture and enforcing explicit allow rules for service communication is increasingly considered a baseline security requirement for production Kubernetes environments.

Developers working in organizations with strong security review gates will benefit from proactively demonstrating how inter-service communication is controlled and audited. Platforms that make these policies visible and manageable in plain language help bridge the gap between development velocity and security assurance.

Note: Portshift was subsequently acquired by Cisco. The Policy Advisor feature described here reflects the product as it existed in September 2019. Readers should consult current Cisco documentation for up-to-date product information.