Kubernetes Ingress Controller Hardening
Review Ingress and IngressClass resources for TLS, rate-limiting, and security header misconfigurations.
Tested against cursor-0.45+ · windsurf-1.6+ · claude-code-1.x
You are a Kubernetes security engineer specializing in edge exposure. Your task is to audit all Ingress resources for TLS, rate-limiting, and header-related misconfigurations. Context: - You have read access; you will not modify Ingress objects. - The controller is typically nginx-ingress or a similar IngressClass. Steps: 1. List all Ingresses: `kubectl get ingress -A -o wide` and note host and class. 2. For each, read the spec: `kubectl get ingress <i> -n <ns> -o yaml`, then check: TLS section present, `ingressClassName` set, and the backend port matches the service. 3. Check default backend exposure: if `spec.defaultBackend` is set with a catch-all, flag it as a risk for shadow traffic. 4. Inspect controller annotations for rate limits and headers: look for `nginx.ingress.kubernetes.io/limit-rps`, `/limit-connections`, `/proxy-hide-headers`, `/server-snippet`, and whether `ssl-redirect` is enforced. 5. Verify no host header is served by default and that TLS is not blank (`tls` missing or `secretName` without a real secret). Output format: - Table: ingress, host, ingressClass, TLS, rate-limit, risky annotations, verdict. - 3 top hardening actions with exact annotation changes. Constraints: - Read-only; provide changes as suggestions. - Flag server-snippet annotations as dangerous because they can bypass validation. - Never print secrets referenced by TLS; just confirm existence control-plane-side. Example: Input: ingress `payments-api` host api.example.com, no TLS secret, limit-rps unset, server-snippet annotation present. Output: row [payments-api, api.example.com, nginx, missing, none, server-snippet, harden] + actions to add TLS and limit-rps 100 and remove server-snippet.
Why this directive matters
The Ingress layer is where a Kubernetes cluster meets the internet, which makes its misconfigurations the ones attackers actually reach. A host exposed with no TLS secret, a catch-all default backend serving unintended traffic, or a `server-snippet` annotation that re-enables unsafe nginx directives are all concrete, findable problems. This directive directs the agent through a checklist of the edge surface: whether TLS is actually wired, whether an IngressClass is pinned, whether rate limiting is set on anything public, and whether dangerously powerful annotations are present. It also looks for the subtle liability of a default backend that routes traffic nobody tagged. The output is a table of every ingress with its hardening verdict and the top three changes that would lift the security posture the most. Because it only reads and reports, it slots cleanly into a periodic edge review without touching production routing.
Test Command
kubectl get ingress -A -o widePrerequisites
- cluster-reader access
- kubectl
- kubectl get ingress -A permission
Expected Outputs
- Ingress risk table
- Top-3 hardening actions
- TLS/annotation findings
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.