SSL/TLS in Docker and Kubernetes: Complete Guide 2025

September 15, 2025 By SSL Checker Pro Team 8 min read

Containerized applications require proper SSL/TLS configuration for secure communications. This guide covers certificate management in Docker and Kubernetes environments.

Docker SSL Configuration

# Dockerfile with SSL
FROM nginx:alpine
COPY nginx.conf /etc/nginx/nginx.conf
COPY ssl/fullchain.pem /etc/nginx/ssl/
COPY ssl/privkey.pem /etc/nginx/ssl/
EXPOSE 443
CMD ["nginx", "-g", "daemon off;"]

# Docker Compose
version: '3.8'
services:
  web:
    image: nginx:alpine
    ports:
      - "443:443"
    volumes:
      - ./ssl:/etc/nginx/ssl:ro
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

Kubernetes cert-manager

# Install cert-manager
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml

# ClusterIssuer for Let's Encrypt
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

Ingress with TLS

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - example.com
    - www.example.com
    secretName: example-tls
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

Service Mesh mTLS

# Istio mTLS
apiVersion: security.istio.io/v1beta1
kind:PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

Secrets Management

# Create TLS secret
kubectl create secret tls example-tls \
  --cert=fullchain.pem \
  --key=privkey.pem \
  --namespace=production

# Use in Pod
apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: tls
      mountPath: /etc/nginx/ssl
      readOnly: true
  volumes:
  - name: tls
    secret:
      secretName: example-tls

Container Security Fundamentals

Containerized applications introduce unique security challenges and opportunities. Containers share the host kernel, making proper isolation and security critical. SSL/TLS provides essential encryption for container-to-container communications, ingress traffic, and connections to external services.

Modern container orchestration platforms like Kubernetes provide built-in support for SSL/TLS through Secrets, ConfigMaps, and automated certificate management. Understanding these mechanisms is essential for securing containerized applications in production environments.

Docker SSL Best Practices

Secrets Management

Docker Secrets provide secure storage for sensitive data including SSL certificates and private keys. Secrets are encrypted at rest and in transit, and only accessible to authorized containers. Never embed certificates directly in container images or environment variables.

# Create Docker secret
echo "cert-content" | docker secret create ssl-cert -
echo "key-content" | docker secret create ssl-key -

# Use in service
docker service create   --name web   --secret ssl-cert   --secret ssl-key   --publish 443:443   nginx:alpine

Multi-Stage Builds

Use multi-stage Docker builds to minimize attack surface. Build stages can include certificate generation or validation steps without including build tools in the final image. This reduces image size and eliminates unnecessary components that could contain vulnerabilities.

Kubernetes Certificate Management

cert-manager Architecture

cert-manager is the de facto standard for Kubernetes certificate management. It automates certificate issuance, renewal, and distribution using custom resource definitions (CRDs). cert-manager supports multiple certificate authorities including Let's Encrypt, Venafi, HashiCorp Vault, and self-signed certificates.

cert-manager monitors certificate expiration and automatically renews certificates before they expire. It integrates with Kubernetes Ingress controllers to automatically provision certificates for new services. This automation eliminates manual certificate management and prevents expiration-related outages.

Certificate Issuers

cert-manager uses Issuer and ClusterIssuer resources to define certificate authorities. Issuers are namespace-scoped, while ClusterIssuers are cluster-wide. Multiple issuers can coexist, allowing different certificate authorities for different applications or environments.

# DNS-01 Challenge for Wildcard Certificates
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-dns
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-dns
    solvers:
    - dns01:
        cloudflare:
          email: admin@example.com
          apiTokenSecretRef:
            name: cloudflare-api-token
            key: api-token

Service Mesh Security

Istio mTLS

Service meshes like Istio provide automatic mutual TLS (mTLS) for service-to-service communications. Istio injects sidecar proxies that handle TLS termination, certificate rotation, and traffic encryption without application code changes. This zero-trust approach ensures all internal communications are encrypted and authenticated.

Istio's certificate management uses SPIFFE (Secure Production Identity Framework For Everyone) for workload identity. Certificates are automatically issued and rotated, with short validity periods (default 24 hours) to limit the impact of compromised certificates.

# Istio Strict mTLS Policy
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

# Verify mTLS is working
istioctl authn tls-check pod-name.namespace

Linkerd mTLS

Linkerd provides automatic mTLS with minimal configuration overhead. Linkerd's control plane issues certificates to data plane proxies, which handle encryption transparently. Linkerd focuses on simplicity and performance, making it ideal for organizations new to service meshes.

Ingress TLS Configuration

Nginx Ingress Controller

The Nginx Ingress Controller is the most popular Kubernetes ingress solution. It supports automatic TLS certificate provisioning through cert-manager annotations. The controller handles TLS termination, HTTP to HTTPS redirection, and SSL configuration.

# Advanced Ingress Configuration
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-protocols: "TLSv1.2 TLSv1.3"
    nginx.ingress.kubernetes.io/ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - example.com
    - www.example.com
    - api.example.com
    secretName: example-tls
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

Traefik Ingress

Traefik provides dynamic configuration and automatic service discovery. It integrates with cert-manager for certificate management and supports multiple certificate resolvers. Traefik's dashboard provides visibility into routing and certificate status.

Certificate Rotation Strategies

Kubernetes environments require automated certificate rotation to maintain security without service disruption. cert-manager handles rotation automatically, but applications must be designed to reload certificates without downtime. Use rolling updates and health checks to ensure zero-downtime certificate rotation.

Graceful Certificate Reload

Applications should watch for certificate file changes and reload certificates without restarting. For applications that cannot reload certificates dynamically, use rolling updates with appropriate readiness and liveness probes to ensure smooth transitions.

Monitoring and Observability

Monitor certificate expiration, TLS handshake failures, and cipher suite usage. Prometheus exporters for cert-manager and ingress controllers provide metrics for alerting. Grafana dashboards visualize certificate status across the cluster.

# Prometheus Alert for Certificate Expiration
groups:
  - name: certificates
    rules:
      - alert: CertificateExpiringSoon
        expr: certmanager_certificate_expiration_timestamp_seconds - time() < 86400 * 14
        labels:
          severity: warning
        annotations:
          summary: "Certificate expiring soon"
          description: "Certificate {{ $labels.name }} expires in less than 14 days"

Multi-Cluster Certificate Management

Organizations running multiple Kubernetes clusters need centralized certificate management. Solutions include shared cert-manager installations with cluster-wide issuers, centralized certificate authorities with per-cluster agents, and service mesh federation for cross-cluster mTLS.

Compliance and Audit

Kubernetes certificate management must meet compliance requirements including certificate inventory, rotation policies, and access controls. Use Kubernetes RBAC to restrict certificate access, maintain audit logs of certificate operations, and implement policy enforcement with tools like OPA (Open Policy Agent).

Best Practices

Use cert-manager for automated certificate management
Store certificates in Kubernetes Secrets
Enable mTLS for service-to-service communication
Use Ingress for TLS termination
Implement network policies
Regular certificate rotation
Monitor certificate expiration

Secure Your Containers

Verify your SSL:

SSL Certificate Checker