¿Worried about public traffic attacks or certificate failures on production clusters? This guide focuses on Seguridad Kubernetes: ingress WAF y cert-manager gestionado and delivers a precise, operational plan to combine an ingress WAF with a managed cert-manager strategy that reduces risk, automates TLS, and meets enterprise hardening standards.
Key design goals: stop OWASP threats at the edge, automate certificate issuance/renewal with robust DNS or HTTP challenges, protect private keys with a KMS, monitor expirations, and implement policies that scale across tenants and clusters.
Key takeaways: what to know in 1 minute
- Combine an ingress WAF with managed certificate automation to block web attacks before they reach workloads while ensuring TLS continuity.
- Prefer DNS01 for wildcard certificates when issuing multi-tenant TLS and using a managed cert provider to reduce http01 fragility.
- Harden cert-manager with RBAC, pod security and encrypted Secrets and store private keys in KMS/HSM when available.
- Edge WAF (Cloudflare/AWS WAF) reduces latency and operational overhead but an ingress WAF gives more control for application-layer rules local to the cluster.
- Monitor cert-manager metrics and set alerting for renewals; include automated remediation steps in CI/CD.
Architecture and threat model for ingress WAF plus managed cert-manager
A clear architecture reduces misconfiguration risk. Typical deployments place a cluster ingress controller (NGINX, Contour, or Envoy) in front of services. The ingress controller may enforce TLS termination or TLS passthrough. An ingress WAF (ModSecurity, NAXSI, NGINX App Protect, or an Envoy filter) inspects HTTP(S) requests and applies signatures and custom rules. Managed cert-manager runs as a control plane component to request, renew, and store certificates automatically.
Primary threats addressed by this combination:
- Layer 7 attacks (SQLi, XSS, RCE) blocked at the ingress WAF.
- TLS certificate expiry and mis-issuance avoided through automated ACME flows or managed CA.
- Private key exposure mitigated with KMS-backed key storage and secrets encryption.
Essential components and placement:
Ingress WAF options and trade-offs
A practical selection matrix clarifies choices. Compare four common deployment models below.
| WAF model |
Pros |
Cons |
Latency impact |
| Cloud/edge WAF (Cloudflare, AWS WAF) |
Global scale, DDoS mitigation, managed signatures |
Vendor lock-in, less app context, costs scale |
Low (CDN optimized) |
| Ingress WAF (ModSecurity on NGINX) |
Full control, custom rules, integrates with ingress annotations |
Operational overhead, tuning required |
Medium |
| Sidecar/Service mesh WAF (Envoy filters) |
Per-service context, mTLS integration |
Complex to operate, resource overhead |
Variable |
| Managed WAF + ingress hybrid |
Defense-in-depth, simpler cluster configuration |
Requires coordination, possible double rules |
Low to medium |
Selecting a model: a short checklist
- For public SaaS with unpredictable traffic: edge WAF + managed certs.
- For multi-tenant clusters requiring per-app rules: ingress WAF with centralized rule management.
- For strict compliance with key custody: KMS/HSM + cert-manager configured to use an external signer.
Cert-manager managed: options, issuers and operational modes
cert-manager supports ACME (Let's Encrypt), private CAs, and external issuers. Managed cert-manager commonly refers to either a SaaS-managed certificate controller or a hosted CA service integrated with a lightweight agent.
Key issuer modes:
- ACME http01: Simple, requires port 80 HTTP challenge. Good for single domain per cluster. More fragile in complex networking.
- ACME dns01: Preferred for wildcard certificates and multi-tenant scenarios; uses DNS provider APIs to create TXT records. See a list of supported providers at cert-manager DNS providers.
- Private CA / Vault: Issues internal certificates; useful for mTLS and internal services.
- Managed CA via provider: Cloud providers (Google-managed certs, AWS ACM) or third-party services handle issuance and rotation.
Managed cert-manager benefits:
- Offloads ACME rate limiting and renewals to a provider.
- Simplifies multi-cluster workload by centralizing issuance.
- Reduces operational surface for ACME troubleshooting.
Managed cert-manager caveats:
- Trust model: ensure the managed provider meets compliance for key custody.
- Cost: managed issuance can bring recurring fees.
Hardening cert-manager and protecting private keys
Hardening cert-manager prevents escalation and key theft. Implement at least the following controls:
- Minimum RBAC: create a ServiceAccount for cert-manager with only required verbs and resources. Avoid cluster-admin for controllers.
- Pod security and PSPs: run cert-manager in a restricted pod security profile; disallow hostNetwork unless necessary.
- Secrets encryption: enable Kubernetes EncryptionConfiguration for Secrets at rest. See Kubernetes secret encryption.
- KMS/HSM integration: store private keys in an external KMS or HSM. For example, integrate cert-manager with HashiCorp Vault as an issuer: HashiCorp Vault.
- Key rotation policy: configure cert lifetimes and automate key rotation; avoid long-lived keys.
- Network policy: restrict egress for cert-manager pods to only required APIs (DNS provider, ACME endpoints, Vault/KMS).
Sample RBAC principle (high level)
- Create a namespace-scoped cert-manager installation when possible.
- Grant only necessary access to Secrets and Issuers for teams and controllers.
- Use Kubernetes Audit logs to monitor issuance calls.
Monitoring, metrics and alerting for cert-manager and WAF
Observability avoids surprises. Recommended metrics and alerts:
- cert-manager metrics via Prometheus: monitor certificate expiration time, ACME failures, and order statuses. Example metrics: certmanager_certificate_expiration_seconds, certmanager_controller_sync_total.
- Ingress/WAF metrics: request counts, blocked request rate, rule hit counts.
- SLO alarms: alert if > 1% of requests blocked by WAF unexpectedly or if cert expiry < 14 days.
- Logging: centralize WAF logs (ModSecurity audit logs, edge WAF logs) into ELK or a SIEM for forensic capability.
Integrations:
- Prometheus: Prometheus exporters for cert-manager and ingress controllers.
- Grafana: dashboards for certificate health and WAF rule hits at Grafana.
- Pager/ChatOps: automated alerts funneling to a runbook with remediation scripts.
Multi-tenant and multi-cluster patterns for TLS and WAF
Common enterprise needs:
- Separate namespaces by tenant and use namespaced Issuers for per-tenant isolation.
- Use wildcard certificates via dns01 for many subdomains under one zone.
- For multi-cluster, centralize certificate issuance through a management cluster or use a federated cert solution.
Pattern examples:
- Tenant A and Tenant B each get a namespaced Issuer bound to their DNS provider credentials stored in Secrets encrypted by KMS.
- A central cert-manager (management cluster) acts as a signing authority; leaf certs are distributed into member clusters via a secure API.
Operationalize cert creation and WAF rules as code:
Automated tests and staging: avoiding production outages
- Use Let's Encrypt staging environment for ACME tests to avoid rate limits.
- Implement smoke tests that validate certificate chain, TLS negotiation, and WAF blocking rules during each deploy.
- Test renewal flows by creating a short-lived certificate type in staging.
Troubleshooting renewals and common failure modes
Typical failures and fast checks:
- ACME http01 fails: validate that the Ingress routes port 80 and that DNS points to the correct external IP. Check the challenge pod logs in cert-manager.
- ACME dns01 fails: validate DNS provider API credentials, TTLs, and propagation. Use dig to check TXT records.
- Rate limited by ACME CA: switch to staging for tests and follow CA retry guidelines.
- Secret not mounted: confirm RBAC for cert-manager to write Secrets in the target namespace.
Useful commands:
- kubectl logs -n cert-manager deploy/cert-manager - check controller logs
- kubectl describe certificate - shows events and ACME order failures
Recovery and disaster planning for certificate infrastructure
- Export and back up Issuer and ClusterIssuer manifests.
- Backup KMS/HSM key material according to provider recommendations.
- Maintain documented runbooks for emergency issuance through alternate CA or temporary self-signed certs to restore traffic while resolving root cause.
Practical example: how it actually works
📊 Case data:
- Domain: example-app.company.com
- Cluster: production-01
- Issuer chosen: dns01 with Cloud DNS provider
🧮 Process: cert-manager creates a DNS TXT record via the DNS provider API; ACME CA verifies the TXT; when verified, cert-manager stores the certificate Secret in the app namespace; the ingress controller mounts that Secret and serves TLS.
✅ Result: automated wildcard cert for *.company.com renewed without HTTP challenge exposure.
Visual process flow
Step 1 → Step 2 → Step 3 → ✅ Live
Step 1 🡒 cert-manager requests ACME challenge (dns01)
Step 2 🡒 DNS provider creates TXT record; ACME validates
Step 3 🡒 cert-manager stores Secret, ingress serves TLS
Comparing edge WAF vs ingress WAF
WAF comparison: edge vs ingress
Edge WAF
- ✓ Global DDoS and CDN support
- ✓ Low latency for public traffic
- ✗ Less application-specific context
Ingress WAF
- ✓ Fine-grained app rules and context
- ✓ Integrates with Kubernetes RBAC
- ✗ Requires ongoing tuning
Advantages, risks and common mistakes
✅ Benefits / when to apply
- Use ingress WAF when per-application rules and integration with Kubernetes metadata are required.
- Use managed cert-manager when certificate lifecycle must be delegated to a trusted provider that meets SLAs.
- Combine edge WAF + ingress WAF for defense-in-depth and to reduce blast radius.
⚠️ Errors to avoid / risks
- Relying solely on http01 in multi-cluster or complex routing environments can cause renewals to fail.
- Running cert-manager with excessive privileges increases risk if the component is compromised.
- Not encrypting Secrets or not using KMS for private keys exposes certs to theft.
Recommended runbook snippets and commands
- Check certificate expiry: kubectl get certificate -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,EXP:.status.notAfter
- View cert-manager events: kubectl describe certificate -n
- Verify WAF rules: Inspect ingress controller config and rule hit metrics in Grafana.
Frequently asked questions
Frequently asked questions
Use a ClusterIssuer configured with your DNS provider credentials and the dns01 solver. Store credentials in an encrypted Secret and reference them in the ClusterIssuer manifest.
Which is better: cloud WAF or ingress WAF?
Cloud WAF is better for global DDoS protection and lower operational overhead. Ingress WAF is better for application-specific rules and local control. For most production workloads, a hybrid approach is recommended.
How to protect private keys managed by cert-manager?
Enable Kubernetes Secrets encryption, integrate with an external KMS/HSM (Vault, AWS KMS), and enforce strict RBAC so only cert-manager can create certificate Secrets.
Can cert-manager use HashiCorp Vault as an issuer?
Yes. cert-manager supports Vault as an issuer for PKI flows. Follow the official cert-manager Vault integration guide.
What metrics should be monitored for cert-manager?
Monitor certificate expiration, ACME order failures, challenge durations, and controller restarts. Export metrics to Prometheus and alert on expiry < 14 days.
How to handle ACME rate limiting during testing?
Use the CA's staging environment (for Let's Encrypt: Let's Encrypt staging) and avoid frequent create/delete cycles in production.
How to integrate WAF rule testing into CI/CD?
Add automated tests that assert that known-malicious payloads are blocked, verify WAF rule coverage and ensure no false positives impact critical endpoints.
Conclusion
This guide demonstrates how to implement Seguridad Kubernetes: ingress WAF y cert-manager gestionado in production-grade clusters with a focus on hardening, monitoring, and operational resilience. Combining WAF protection at the edge or ingress with a managed certificate lifecycle reduces both attack surface and the risk of TLS outages.
YOUR NEXT STEP:
- Audit current ingress controllers and identify whether an ingress WAF or edge WAF is already in place.
- Implement cert-manager staging flows (dns01 for wildcards) and enable Secrets encryption for the cluster.
- Configure Prometheus alerts for certificate expiry and WAF rule alerting; add a remediation playbook to the runbook.
