
Managing Network Policies
FreeStreamline Kubernetes network policy management.
Free · Opens the source repo
What Managing Network Policies does
Managing Network Policies is a skill designed for developers and DevOps engineers who need to enforce secure communication within Kubernetes environments. This skill helps generate Kubernetes NetworkPolicy manifests that adhere to zero-trust principles, ensuring that only authorized pods can communicate with each other. It simplifies the process of creating ingress and egress rules by providing a structured approach to defining network policies based on least privilege.
To effectively use this skill, users should have a Kubernetes cluster equipped with a compatible CNI plugin, such as Calico or Cilium. The skill guides users through the necessary steps to map application communication patterns, starting with a default-deny policy to establish a secure baseline. By specifying source and destination pod labels, ports, and CIDR blocks, users can create tailored policies that align with their application architecture and security requirements.
The skill also emphasizes the importance of monitoring and iterating on network policies. Users can apply their policies in a test namespace first and validate connectivity using kubectl commands. This iterative approach allows for adjustments based on real traffic patterns and ensures that legitimate communications are not inadvertently blocked. Additionally, the skill provides error handling guidance to troubleshoot common issues that may arise during policy application.
Overall, Managing Network Policies is an essential tool for those looking to enhance the security of their Kubernetes deployments by systematically managing network communications between services and external endpoints.
When to use it
Use this skill when you need to establish secure network policies in a Kubernetes environment, particularly when implementing zero-trust networking principles.
When not to use it
This skill may not be suitable for environments without Kubernetes or for users unfamiliar with networking concepts and Kubernetes policies.
What you can build with it
Establishing Zero-Trust Networking
Implement a default-deny policy in your Kubernetes cluster to enforce zero-trust principles, ensuring only authorized pod communications are allowed.
Creating Tailored Ingress Rules
Generate specific ingress rules for your application, allowing only necessary traffic to reach critical services based on defined pod labels.
Iterating on Network Policies
Monitor traffic and adjust your network policies iteratively to accommodate legitimate communication paths while maintaining security.
How to install Managing Network Policies
View source1. Install with the skills CLI
npx skills add jeremylongshore/claude-code-plugins-plus-skills/managing-network-policies --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by jeremylongshoreManaging Network Policies
Overview
Create and manage Kubernetes NetworkPolicy manifests to enforce zero-trust networking between pods, namespaces, and external endpoints. Generate ingress and egress rules with label selectors, namespace selectors, CIDR blocks, and port specifications following the principle of least privilege.
Prerequisites
- Kubernetes cluster with a CNI plugin that supports NetworkPolicy (Calico, Cilium, Weave Net)
kubectlconfigured with permissions to create and manage NetworkPolicy resources- Pod labels consistently defined across deployments for accurate selector targeting
- Service communication map documenting which pods need to talk to which pods on which ports
- Understanding of DNS requirements (pods need egress to kube-dns on port 53 for name resolution)
Instructions
- Map the application communication patterns: identify all service-to-service, service-to-database, and service-to-external connections
- Start with a default-deny policy for both ingress and egress in each namespace to establish zero-trust baseline
- Add explicit allow rules for each legitimate communication path: specify source pod labels, destination pod labels, and ports
- Always include a DNS egress rule allowing traffic to
kube-systemnamespace on UDP/TCP port 53 for CoreDNS - Define egress rules for external API access: use CIDR blocks or namespaceSelector for known external services
- Apply policies to a test namespace first and verify connectivity with
kubectl execcurl/wget commands - Monitor for blocked traffic in the CNI plugin logs (Calico:
calicoctl node status, Cilium:cilium monitor) - Iterate on policies: add missing allow rules for any legitimate traffic that gets blocked
- Document each policy with annotations explaining the business reason for the allowed communication
Output
- Default-deny NetworkPolicy manifests for ingress and egress per namespace
- Allow-list NetworkPolicy manifests for each service communication path
- DNS egress policy allowing pod name resolution
- External access egress policies with CIDR blocks
- Connectivity test commands for validation
Error Handling
| Error | Cause | Solution |
|---|---|---|
All traffic blocked after applying policy | Default-deny applied without corresponding allow rules | Apply allow rules before or simultaneously with deny policies; verify with kubectl exec tests |
DNS resolution fails after network policy | Missing egress rule for kube-dns/CoreDNS | Add egress policy allowing UDP and TCP port 53 to kube-system namespace |
Policy not targeting intended pods | Label mismatch between policy selector and pod labels | Verify labels with kubectl get pods --show-labels; match selectors exactly |
Traffic still allowed despite deny policy | CNI plugin does not support NetworkPolicy or policy in wrong namespace | Verify CNI support with kubectl get networkpolicy -A; ensure policy is in the correct namespace |
Intermittent connection failures | Policy allows traffic but connection pool or timeout settings too aggressive | Check if the issue is network policy or application-level; test with kubectl exec during failures |
Examples
- "Create a default-deny policy for the
productionnamespace, then add allow rules so only the ingress controller can reach web pods on port 443." - "Generate egress policies that restrict the API pods to communicate only with PostgreSQL (port 5432), Redis (port 6379), and external HTTPS APIs."
- "Build a complete set of network policies for a 3-tier app: frontend -> API (8080), API -> database (5432), API -> cache (6379), all pods -> DNS (53)."
Resources
- Kubernetes NetworkPolicy: https://kubernetes.io/docs/concepts/services-networking/network-policies/
- Calico network policy: https://docs.tigera.io/calico/latest/network-policy/
- Cilium network policy: https://docs.cilium.io/en/stable/security/policy/
- Network policy editor (visual): https://editor.networkpolicy.io/
Frequently asked questions about Managing Network Policies
Similar skills
Turborepo
Optimized build system for JavaScript/TypeScript monorepos.
Azure Pipelines Validation
Streamline your Azure DevOps pipeline changes locally.
Azure Developer CLI
Streamline your Azure project workflows with best practices.
Azure Container Registry CLI
Manage Azure Container Registry resources with ease.
Aspire
Build and orchestrate polyglot distributed applications seamlessly.
Vercel CLI
Manage and deploy Vercel projects from the command line.
