agentsclimarketplace

Managing network policies

Skill jeremylongshore/claude-code-plugins-plus-skills/plugins/devops/network-policy-manager/skills/managing-network-policies

'Execute use when managing Kubernetes network policies and firewall rules. Trigger with phrases like "create network policy", "configure firewall rules", "restrict pod communication", or "setup ingress/egress rules". Generates Kubernetes NetworkPolicy manifests following least privilege and zero-trust principles.From its SKILL.md

Install
npx -y skills add jeremylongshore/claude-code-plugins-plus-skills --skill managing-network-policies

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

4.6 KB, 833 tokens by cl100k_base, as published. Nobody here has run it

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)
  • kubectl configured 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

  1. Map the application communication patterns: identify all service-to-service, service-to-database, and service-to-external connections
  2. Start with a default-deny policy for both ingress and egress in each namespace to establish zero-trust baseline
  3. Add explicit allow rules for each legitimate communication path: specify source pod labels, destination pod labels, and ports
  4. Always include a DNS egress rule allowing traffic to kube-system namespace on UDP/TCP port 53 for CoreDNS
  5. Define egress rules for external API access: use CIDR blocks or namespaceSelector for known external services
  6. Apply policies to a test namespace first and verify connectivity with kubectl exec curl/wget commands
  7. Monitor for blocked traffic in the CNI plugin logs (Calico: calicoctl node status, Cilium: cilium monitor)
  8. Iterate on policies: add missing allow rules for any legitimate traffic that gets blocked
  9. 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

ErrorCauseSolution
All traffic blocked after applying policyDefault-deny applied without corresponding allow rulesApply allow rules before or simultaneously with deny policies; verify with kubectl exec tests
DNS resolution fails after network policyMissing egress rule for kube-dns/CoreDNSAdd egress policy allowing UDP and TCP port 53 to kube-system namespace
Policy not targeting intended podsLabel mismatch between policy selector and pod labelsVerify labels with kubectl get pods --show-labels; match selectors exactly
Traffic still allowed despite deny policyCNI plugin does not support NetworkPolicy or policy in wrong namespaceVerify CNI support with kubectl get networkpolicy -A; ensure policy is in the correct namespace
Intermittent connection failuresPolicy allows traffic but connection pool or timeout settings too aggressiveCheck if the issue is network policy or application-level; test with kubectl exec during failures

Examples

  • "Create a default-deny policy for the production namespace, 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

What ships with it: 5 files

6.7 KB alongside SKILL.md, 1 of them executable

references/

Keep looking

Skills are one crate of 326,144. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.