managing-network-policies
Generates Kubernetes NetworkPolicy manifests to restrict and secure pod communication.
Install
mkdir -p .claude/skills/managing-network-policies && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4236" && unzip -o skill.zip -d .claude/skills/managing-network-policies && rm skill.zipInstalls to .claude/skills/managing-network-policies
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Execute use when managing Kubernetes network policies and firewall rules.Key capabilities
- →Generate Kubernetes NetworkPolicy manifests for zero-trust networking
- →Configure ingress and egress rules using label selectors and CIDR blocks
- →Implement default-deny policies for namespaces
- →Define DNS egress rules for CoreDNS
- →Apply policies to test namespaces and verify connectivity
- →Monitor for blocked traffic in CNI plugin logs
How it works
The skill guides the user through mapping application communication patterns and then generating NetworkPolicy manifests. It emphasizes starting with default-deny policies and adding explicit allow rules for legitimate traffic, including DNS and external access.
Inputs & outputs
When to use managing-network-policies
- →Create zero-trust default-deny network policies
- →Configure ingress and egress rules for pods
- →Restrict service-to-database communication
- →Implement network segmentation in Kubernetes
About this skill
Managing 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/
When not to use it
- →When not using Kubernetes
- →When the CNI plugin does not support NetworkPolicy
Prerequisites
Limitations
- →Requires a Kubernetes cluster with a CNI plugin that supports NetworkPolicy
- →Requires `kubectl` configured with appropriate permissions
- →Relies on consistently defined pod labels for accurate selector targeting
How it compares
This skill provides a structured approach to generating Kubernetes NetworkPolicy manifests following least privilege and zero-trust principles, which is more systematic than manually creating policies.
Compared to similar skills
managing-network-policies side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| managing-network-policies (this skill) | 1 | 25d | Review | Intermediate |
| linkerd-patterns | 6 | 5mo | Review | Advanced |
| azure-stack-edge | 0 | 4mo | No flags | Intermediate |
| azure-kubernetes-automatic-readiness | 0 | 2mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
linkerd-patterns
wshobson
Implement Linkerd service mesh patterns for lightweight, security-focused service mesh deployments. Use when setting up Linkerd, configuring traffic policies, or implementing zero-trust networking with minimal overhead.
azure-stack-edge
orgdevendra
Expert knowledge for Azure Stack Edge development including troubleshooting, best practices, decision making, limits & quotas, security, configuration, integrations & coding patterns, and deployment. Use when running IoT Edge or GPU/Kubernetes apps, configuring VMs/storage/networking, or managing de
azure-kubernetes-automatic-readiness
jonathan-vella
Assess Kubernetes workloads and cluster configuration for AKS Automatic compatibility. Identifies incompatibilities, generates fixes, and guides migration from AKS Standard to AKS Automatic. WHEN: migrate to AKS Automatic, check AKS Automatic readiness, validate manifests for Automatic, assess clust
k8s-security
rohitg00
Audit Kubernetes RBAC, enforce policies, and manage secrets. Use for security reviews, permission audits, policy enforcement with Kyverno/Gatekeeper, and secret management.
container-security-testing
Ed1s0nZ
容器安全测试的专业技能和方法论
k8s-certs
rohitg00
Kubernetes certificate management with cert-manager. Use when managing TLS certificates, configuring issuers, or troubleshooting certificate issues.