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.
What this skill does
# 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 | 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 `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 - 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/
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.