home / skills / julianobarbosa / claude-code-skills / managing-infra-skill

managing-infra-skill skill

/skills/managing-infra-skill

This skill guides infrastructure decisions across Kubernetes, Terraform, Helm, Kustomize, and CI/CD to optimize architecture and security.

npx playbooks add skill julianobarbosa/claude-code-skills --skill managing-infra-skill

Review the files below or copy the command above to add this skill to your agents.

Files (9)
SKILL.md
2.1 KB
---
name: managing-infra
description: Infrastructure patterns for Kubernetes, Terraform, Helm, Kustomize, and GitHub Actions. Use when making K8s architectural decisions, choosing between Helm vs Kustomize, structuring Terraform modules, writing CI/CD workflows, or applying security best practices.
allowed-tools: Read, Bash, Grep, Glob
---

# Infrastructure Patterns

## When to Use What

| Tool               | Use For                                             |
| ------------------ | --------------------------------------------------- |
| **Raw K8s YAML**   | Simple deployments, one-off resources               |
| **Kustomize**      | Environment variations, overlays without templating |
| **Helm**           | Complex apps, third-party charts, heavy templating  |
| **Terraform**      | Cloud resources, infrastructure lifecycle           |
| **GitHub Actions** | CI/CD, automated testing, releases                  |
| **Makefile**       | Build automation, self-documenting targets          |
| **Dockerfile**     | Container builds, multi-stage, multi-arch           |

## Quick Decisions

**Kustomize** when: Simple env differences, readable manifests, patching YAML
**Helm** when: Complex templating, third-party charts, release management

## K8s Security Defaults

Every workload: non-root user, read-only filesystem, no privilege escalation, dropped capabilities, network policies.

## GitHub Actions Patterns

- **CI workflow**: Lint, test, compile on PRs (run on both x86 + ARM)
- **Release workflow**: Multi-arch Docker build on tags (native ARM runners)
- Pin actions by SHA, least-privilege permissions

## References

- [KUBERNETES.md](KUBERNETES.md) - K8s resource patterns
- [TERRAFORM.md](TERRAFORM.md) - Terraform module patterns
- [GITHUB-ACTIONS.md](GITHUB-ACTIONS.md) - CI/CD workflow patterns
- [MAKEFILE.md](MAKEFILE.md) - Build automation patterns
- [DOCKERFILE.md](DOCKERFILE.md) - Container build patterns
- [templates/](templates/) - Ready-to-use templates

## Commands

```bash
kubectl apply -k ./              # Apply kustomize
helm upgrade --install NAME .    # Install/upgrade chart
terraform plan && terraform apply
```

Overview

This skill provides pragmatic infrastructure patterns for Kubernetes, Terraform, Helm, Kustomize, and GitHub Actions to guide architectural decisions and CI/CD design. It focuses on choosing the right tool, structuring modules and charts, and applying secure defaults for production workloads. Use it to reduce complexity, enforce consistency, and speed up delivery pipelines.

How this skill works

I summarize decision criteria for common tools and give concrete patterns you can apply immediately: when to prefer raw YAML, Kustomize, or Helm; how to structure Terraform modules; and recommended GitHub Actions workflows for CI and releases. I also encode Kubernetes security defaults and actionable commands for day-to-day operations. The guidance is tool-agnostic but pragmatic, emphasizing readability, maintainability, and least-privilege automation.

When to use it

  • Use raw Kubernetes YAML for small, simple deployments or one-off resources.
  • Use Kustomize for environment overlays and readable, patch-based variations without templating.
  • Use Helm for complex applications, third-party charts, or when you need heavy templating and release management.
  • Use Terraform for cloud infrastructure and lifecycle management across providers.
  • Use GitHub Actions for CI/CD: run lint, test, and multi-arch builds; run release workflows on tags.

Best practices

  • Apply Kubernetes security defaults: run as non-root, read-only filesystem, drop capabilities, prevent privilege escalation, and use network policies.
  • Prefer Kustomize for simple env diffs; prefer Helm when templating or managing upstream charts is required.
  • Structure Terraform modules by feature and reuse: keep small modules, clear inputs/outputs, and version constraints.
  • Pin GitHub Actions to SHAs, grant least-privilege permissions, and include ARM + x86 runners for multi-arch CI.
  • Use Makefile targets to document common tasks and Docker multi-stage builds for smaller images.

Example use cases

  • Decide between Helm and Kustomize for a multi-environment Kubernetes deployment with minor config drift.
  • Design Terraform modules for a microservice platform with separate network, compute, and state modules.
  • Create GitHub Actions CI that lints, tests, and builds images for x86 and ARM on PRs.
  • Build a release workflow that performs multi-arch Docker builds and publishes artifacts on tag events.
  • Harden pod security by applying the listed defaults and adding network policies for inter-service traffic control.

FAQ

When should I prefer Kustomize over Helm?

Choose Kustomize when you need readable overlays and simple YAML patching across environments without templating. Use Helm when you need parameterized templates, chart reuse, or manage third-party charts.

What are the essential Kubernetes security settings?

At minimum run workloads as a non-root user, mark filesystems read-only, drop Linux capabilities, deny privilege escalation, and enforce network policies.