# Cert Manager

> "cert-manager in Cloud-Native Engineering - Certificate Management for" Kubernetes

- Skill: `paulpas/cert-manager` (Agent Skill)
- Install (CLI): `npx skillmds@latest add paulpas/cert-manager`
- Raw SKILL.md: https://api.skillmd.com/api/skills/paulpas/cert-manager/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- License: MIT
- Author: paulpas (https://skillmd.com/u/paulpas)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/paulpas/cert-manager

---





  related-skills: cncf-aws-kms, cncf-aws-s3, cncf-aws-secrets-manager, cncf-azure-key-vault

# cert-manager in Cloud-Native Engineering

**Category:** security  
**Status:** Graduated  
**Stars:** 9,000  
**Last Updated:** 2026-04-22  
**Primary Language:** Go  
**Documentation:** [https://cert-manager.io/](https://cert-manager.io/)  

---

## Purpose and Use Cases

cert-manager is a native Kubernetes certificate management controller that helps manage TLS certificates and their lifecycles within Kubernetes clusters.

### What Problem Does It Solve?

The complexity of managing TLS certificates across multiple applications, issuers, and certificate authorities. It automates certificate issuance, renewal, and revocation for Kubernetes resources.

### When to Use This Project

Use cert-manager when you need automated TLS certificate management for Kubernetes services, want to integrate with multiple CA providers (Let's Encrypt, Vault, etc.), or need certificate renewal automation.

### Key Use Cases


- **Automated TLS Certificates**: Automatically issue and renew TLS certificates
- **Multiple Issuers**: Support for Let's Encrypt, Vault, Self-Signed, ACME, PKI
- **Ingress Integration**: Automatic certificate mounting for Ingress resources
- **Service Integration**: Certificate management for Services and Pods
- **Certificate Lifecycle**: Automatic renewal and rotation
- **Multi-Cluster**: Cross-cluster certificate management
- **Certificate Requests**: On-demand certificate issuance


---

## Architecture Design Patterns

### Core Components

- **Controller**: Main controller managing certificate resources
- **Issuer**: Cluster-scoped certificate issuer definition
- **ClusterIssuer**: Cluster-wide certificate issuer
- **Certificate**: Request for a specific certificate
- **CertificateRequest**: Certificate signing request
- **Challenge**: ACME challenge resource
- **Order**: ACME order resource
- **Account**: ACME account registration

### Component Interactions

1. **Certificate → Controller**: Request certificate
2. **Controller → Issuer**: Request certificate from issuer
3. **Controller → Order**: Create ACME order
4. **Order → Challenge**: Create ACME challenge
5. **Challenge → DNS/HTTP**: Solve ACME challenge
6. **Controller → CA**: Submit CSR to CA
7. **CA → Controller**: Return certificate
8. **Controller → Secret**: Store certificate in Secret

### Data Flow Patterns

1. **Certificate Request**: Certificate CRD created → Controller validates → Issuer contacted → Certificate issued → Secret updated
2. **ACME Flow**: Order created → Challenges created → Challenges solved → Order finalized → Certificate retrieved
3. **Renewal Flow**: Certificate expiry check → Renewal trigger → New certificate issued → Old certificate rotated
4. **Ingress Integration**: Ingress created → Certificate request → TLS secret created → Ingress updated

### Design Principles

- **Kubernetes Native**: Uses CRDs and Kubernetes API patterns
- **Declarative**: Certificate resources defined by desired state
- **Extensible**: Custom issuer plugins and webhook support
- **Auto-Recovery**: Automatic certificate renewal
- **Multi-Issuer**: Support for multiple certificate authorities
- **Secure**: Private key management and encryption

---

## Integration Approaches

### Integration with Other CNCF Projects

- **Kubernetes**: Core platform for certificate management
- **Ingress-Nginx**: Automatic TLS for Ingress
- **Traefik**: Integration with Traefik Ingress controller
- **NGINX Ingress**: NGINX Ingress controller integration
- **Helm**: Chart deployment with cert-manager
- **Vault**: HashiCorp Vault as certificate issuer
- **OpenTelemetry**: Tracing for certificate operations
- **Prometheus**: Metrics collection

### API Patterns

- **Kubernetes API**: CRD operations for certificates
- **Webhook API**: Admission webhooks for validation
- **ACME API**: ACME protocol for Let's Encrypt
- **REST API**: Certificate management API

### Configuration Patterns

- **Issuer/ClusterIssuer YAML**: Issuer configuration
- **Certificate YAML**: Certificate request configuration
- **Ingress Annotations**: Automatic certificate annotation
- **Challenge Configuration**: ACME challenge settings

### Extension Mechanisms

- **Custom Issuers**: Implement custom certificate issuers
- **Webhooks**: Custom validation and mutation webhooks
- **Certificate Providers**: Add new CA providers

---

## Common Pitfalls and How to Avoid Them

### Configuration Issues

- **Issuer Configuration**: Incorrect issuer configuration
- **Certificate Annotations**: Missing or incorrect annotations
- **Challenge Solving**: DNS or HTTP challenge failures
- **ACME Account**: Lost or misconfigured ACME account
- **Secret Permissions**: Certificate Secret not accessible

### Performance Issues

- **Certificate Latency**: Slow certificate issuance
- **ACME Rate Limits**: Let's Encrypt rate limiting
- **Controller Load**: High reconciliation overhead
- **Database Size**: Certificate storage growth

### Operational Challenges

- **Certificate Expiry**: Missing expiry monitoring
- **Issuer Failures**: Issuer unavailability
- **ACME Rate Limits**: Plan for rate limits
- **Certificate Rotation**: Manual rotation when needed
- **Multi-Cluster**: Certificate synchronization

### Security Pitfalls

- **Private Key Exposure**: Secrets not encrypted at rest
- **Certificate Trust**: Untrusted certificate authorities
- **Access Control**: Overly permissive certificate access
- **ACME Account Security**: Compromised ACME account

---

## Coding Practices

### Idiomatic Configuration

- **Certificate CRDs**: Declarative certificate definitions
- **Issuer CRDs**: Declarative issuer definitions
- **Annotations**: Ingress and Service annotations
- **Webhooks**: Custom webhook configurations

### API Usage Patterns

- **kubectl apply**: Create and update certificates
- **Controller API**: Programmatic certificate management
- **ACME API**: ACME protocol interactions
- **Secret API**: Certificate storage

### Observability Best Practices

- **Metrics**: Certificate expiry, issuance success, ACME challenges
- **Logging**: Certificate operations logging
- **Tracing**: Certificate request tracing
- **Alerting**: Certificate expiry alerts

### Development Workflow

- **Local Testing**: minikube/kind for development
- **Debugging**: Certificate log inspection
- **Testing**: Certificate issuance testing
- **CI/CD**: Automated certificate testing
- **Tools**: kubectl, cert-manager, openssl

---

## Fundamentals

### Essential Concepts

- **Issuer**: Cluster-scoped certificate issuer
- **ClusterIssuer**: Cluster-wide issuer
- **Certificate**: Request for a specific certificate
- **CertificateRequest**: Certificate signing request
- **Challenge**: ACME challenge resource
- **Order**: ACME order resource
- **Account**: ACME account registration
- **Secret**: Kubernetes Secret storing certificate

### Terminology Glossary

- **Issuer**: Certificate issuer definition
- **ClusterIssuer**: Cluster-wide issuer
- **Certificate**: Certificate request
- **Challenge**: ACME challenge
- **Order**: ACME order
- **Account**: ACME account
- **CSR**: Certificate signing request

### Data Models and Types

- **Issuer**: Issuer configuration
- **ClusterIssuer**: Cluster issuer configuration
- **Certificate**: Certificate request configuration
- **CertificateRequest**: Certificate signing request
- **Challenge**: Challenge configuration
- **Order**: Order configuration
- **Account**: ACME account configuration

### Lifecycle Management

- **Certificate Lifecycle**: Request → Issued → Renewed → Expired
- **ACME Lifecycle**: Order → Challenges → Finalize → Certificate
- **Renewal Lifecycle**: Expiry check → Renewal trigger → New certificate
- **Issuer Lifecycle**: Configure → Validate → Issue → Renew

### State Management

- **Certificate State**: Current certificate status
- **Challenge State**: ACME challenge status
- **Order State**: ACME order status
- **Account State**: ACME account configuration
- **Secret State**: Certificate storage state

---

## Scaling and Deployment Patterns

### Horizontal Scaling

- **Controller Scaling**: Multiple controller replicas
- **Issue Scaling**: Multiple issuer instances
- **Certificate Processing**: Parallel certificate processing

### High Availability

- **Controller HA**: Multiple controller replicas
- **Storage HA**: etcd HA for certificate state
- **Issuer HA**: Issuer service HA
- **Service Discovery**: Kubernetes service discovery

### Production Deployments

- **Controller Deployment**: Production-ready controller deployment
- **Issuer Configuration**: Trusted CA configuration
- **Certificate Storage**: Secret encryption at rest
- **Monitoring**: Certificate expiry monitoring
- **Security**: RBAC and network policies

### Upgrade Strategies

- **CRD Migration**: Handle CRD schema changes
- **Controller Rolling Update**: Zero-downtime controller updates
- **Certificate Reconciliation**: Reconcile certificates after upgrade
- **Issuer Configuration**: Update issuer configurations

### Resource Management

- **CPU/Memory Limits**: Appropriate resource requests
- **Certificate Storage**: Secret storage management
- **ACME Rate Limits**: Plan for rate limits
- **Network**: Controller to issuer communication

---

## Additional Resources

- **Official Documentation:** [https://cert-manager.io/docs/](https://cert-manager.io/docs/)
- **GitHub Repository:** [github.com/cert-manager/cert-manager](https://github.com/cert-manager/cert-manager)
- **CNCF Project Page:** [cncf.io/projects/cert-manager/](https://www.cncf.io/projects/cert-manager/)
- **Community:** Check the GitHub repository for community channels
- **Versioning:** Refer to project's release notes for version-specific features

---

## Troubleshooting

### Common Issues

1. **Deployment Failures**
   - Check pod logs for errors
   - Verify configuration values
   - Ensure network connectivity

2. **Performance Issues**
   - Monitor resource usage
   - Adjust resource limits
   - Check for bottlenecks

3. **Configuration Errors**
   - Validate YAML syntax
   - Check required fields
   - Verify environment-specific settings

4. **Integration Problems**
   - Verify API compatibility
   - Check dependency versions
   - Review integration documentation

### Getting Help

- Check official documentation
- Search GitHub issues
- Join community channels
- Review logs and metrics
*Content generated automatically. Verify against official documentation before production use.*

## Examples

### Basic Configuration


```yaml
# Basic configuration example
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{project_name}}-config
  namespace: default
data:
  # Configuration goes here
  config.yaml: |
    # Base configuration
    # Add your settings here
```

### Kubernetes Deployment


```yaml
# Kubernetes deployment for {{project_name}}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{project_name}}
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: {{project_name}}
  template:
    metadata:
      labels:
        app: {{project_name}}
    spec:
      containers:
      - name: {{project_name}}
        image: {{project_name}}:latest
        ports:
        - containerPort: 8080
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"
```

### Kubernetes Service


```yaml
# Kubernetes service for {{project_name}}
apiVersion: v1
kind: Service
metadata:
  name: {{project_name}}
  namespace: default
spec:
  selector:
    app: {{project_name}}
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: ClusterIP
```

---

## When to Use

Use this skill when:

- **Integrating a CNCF project into Kubernetes infrastructure** — You need to configure, deploy, or troubleshoot a cloud-native tool within a cluster
- **Designing cloud-native architecture** — You are selecting and integrating CNCF tools to solve specific infrastructure challenges
- **Resolving operational issues** — A CNCF component is misbehaving, underperforming, or needs configuration changes
---

## Core Workflow

1. **Assess Requirements** — Understand the use case, scale, integration needs, and existing infrastructure. **Checkpoint:** Document requirements, constraints, and success criteria.

2. **Design Architecture** — Plan component interactions, data flow, and deployment strategy using cloud-native best practices. **Checkpoint:** Verify the architecture addresses all requirements and follows CNCF conventions.

3. **Implement & Configure** — Create manifests, configurations, and deployment scripts. Include resource limits, health checks, and observability hooks. **Checkpoint:** Validate all YAML against schema and test in a staging environment.

4. **Deploy & Monitor** — Apply manifests to the cluster, verify component health, and confirm observability is working. **Checkpoint:** Confirm all pods/services are running, probes passing, and metrics/alerts configured.

---

## Constraints

### MUST DO
- Include at least one complete working YAML manifest example
- Note when content is auto-generated vs. manually verified
- Reference relevant CNCF project documentation

### MUST NOT DO
- Deploy manifests without testing in a staging environment first
- Use deprecated API versions (e.g., apps/v1beta1)
- Omit resource limits and requests in Kubernetes manifests